想要获得云端动态而灵活的规模扩充性，并非只是把系统放到云上执行就能得到预期效益，应用程式执行的方式，可能也必须有所调整
在前文中我们谈到所谓的「规模可扩充性（scalability）」，一个系统有没有规模可扩充性，我们看的并不是单一计算节点上跑多快，而是当你增加计算资源（例如机器、频宽）时，能否通过增加计算资源，来换取更大规模的处理能力。
当在解决大型规模的计算问题时，人们关心能否通过增加伺服器、频宽、储存空间的方法，来服务更大规模的用量，更胜于在单一伺服器上可以执行多快。
要得到规模可扩充性，并不是一件容易的事情，但如果可以从平台本身获得支持，包括计算能力及资料存取等，对应用程式来说，会简单许多。而这也正是一些所谓「云端计算平台」的作用所在。
另一方面，我们谈到了「云端计算平台」，并不是建构在「云端计算平台」上的应用程式，就必然具备规模可扩充性。
例如，对于应用程式来说，它有可能是建构在IaaS（Infrastructure as a Service）的层次之上，或者，也可能是在PaaS（Platform as a Service）层次上所发展的。
通常，建立在IaaS上的应用程式，无法直接得到规模可扩充性，平台通常可以提供的部分，只是「依用量可随时动态弹性配置的资源」。就像在AWS的EC2上运行应用程式，并不能保证应用程式的规模可扩充性，充其量，只能在你需要伺服器、频宽、储存空间时，EC2能够尽可能地动态满足你的需要。
所以说，并不是把应用程式搬上了「云端」，就必然获得了规模可扩充性，当你只是在 IaaS 平台上开发时，是否具备规模可扩充性，仍旧取决于你的系统架构及特性。
不过，当你是在PaaS上开发时，情况又有所不同。PaaS平台本身，会处理掉许多和规模可扩充性相关的问题，就像是在Google的App Engine上面，它所提供的资料存取操作，就不同于传统的关联式资料库，而是以BigTable 为基础的操作模式，这使得它有能力处理海量资料的存取。而立足在App Engine之上的应用程式，自然而然，具备着更好的规模可扩充性。
因此，在一个专门为了更大规模而设计的平台上开发，对于想要得到规模可扩充性的应用程式开发者来说，可以省去不少的力气。其中像 Hadoop 便是一个为了大规模计算而设计出来的平台，其中，利用所谓MapReduce的计算方式，可以将计算量分散到各个能提供计算的机器之上，集合众多机器之力，因而在更短的时间内，解决想要解决的计算问题。而且，可以弹性投入所能配置的资源数量，投入的愈多，解决的愈快。例如，动用更多的伺服器，就能更快的解决计算问题。倘若预算不那么充分，也可以使用较少的机器，但耗费较多的时间，而这正是规模可扩充性的意义所在。
分散式计算的迷思
虽然说，分散式计算的目的之一，就是希望通过将计算量分散到多部、不同的机器上，来增加整体的计算能力，但是，并不是所有的应用程式都可以轻易拆散到多部机器之上去运行，而且更重要的是，并不是将应用程式拆分到多部机器之上，就必然带来整体计算量的提升。
举例来说，倘若你将你的应用程式拆成多份，并且同时传输至多部机器之上执行，而这几个程式之间需要沟通，也就是交换资料，它们之间甚至需要做同步（synchronization），以致于不同机器上的程式之间需要等待特定工作的完成，接着才能继续执行，那么，这样的应用程式就不见得具有规模可扩充性，因为，等待的环节，会造成规模无法随着计算资源投入而跟着成长的因素。
这说明了，即使试着将计算拆分成为多份，并且置于多部机器上执行，也不见得可以获得多倍的效能改进，很可能因为计算模式的特性所限，而仅能获得少数的效能成长，而且随着规模愈大，成长的比例愈低。因此，如何拆分计算工作，使得它们被散布到多部不同的机器后，可以得到对应的计算规模提升，就成了这件事情的核心议题。
通过分而治之的方式，将大问题拆开许多个小问题，个个击破，降低解决问题的难度
像Hadoop的MapReduce，就是一种拆分计算工作的方式。想要通过拆分工作来解决计算问题，传统的「分而治之（Divide and Conquer）」其实，就是一种可行的方式。所谓的「分而治之」，就是将一个大问题，拆解成多个小问题，而分别解决这些小问题的答案之后，再将这些答案通过某种方式合并起来，就可以得到大问题的答案。这种方式常常可以递回为之，也就是拆成比较小的问题之后，还可以接着再继续拆解，直到拆解至适合解决问题的规模为止。
如果，我们可以运用「分而治之」的方式来解决问题，就很容易得到规模可扩充性，因为，我们可以将原始的问题拆解成若干个较小规模的问题，然后把这些问题分别置放在不同的机器上解决，因为解决这些小问题的计算是互相独立的、它们之间也不需要沟通，所以，当可运用的机器数量变多时，就可以将问题的规模拆解的更小，使得在单一机器上解决它们的速度更快，更使得整体解决它们的时间可以缩短。而 MapReduce 正是此种「分而治之」的解题计算模式，当你运用MapReduce时，便得以此种方式来思考解决问题的方法。
函数式程式设计开始流行
在另一方面来看，你可能也会发现到，所谓「函数式（functional）」的程式设计方式，在这种「分而治之」的分散式计算模式里，开始受欢迎了起来。函数式的程式语言已经有几十年的历史，早期像 Lisp 的程式语言，主要是应用在人工智慧的领域。但是，为什么在这个应用领域里，反而流行起来了？
函数式的程式语言有一些特性，包括程式中是没有状态（stateless），而且每次函式之值被评估（或说被执行）时，是没有副作用的（side effect ）。
所谓的副作用，代表的是函式被执行时，除了它主要应该达成的作用之外，还有一些其他附属的效果，此即其副作用。主要的作用，就像是函式的回传值，而副作用，则像是除了回传函式之值以外，还同时改变全域变数的值。你可以想像，函式的回传值，除了被其输入参数所影响之外，还同时被其他的状态，像是全域变数所影响时，会产生许多意想不到的结果。
但是如果我们从数学上的函数的角度来看，f（x） 之值，完全取决于 x ，没任何 f（） 内部的状态或是外部的状态足以在 x 相同时，造成 f（x） 之值不同。而所谓的函数式程式设计方式，便是在特性上有着此种取向，因此，它没有状态、也没有副作用。
这种特性之所以能对分散式计算带来好处，我想是因为在有这样的特性之后，计算工作会更容易分配到不同的机器上去计算。正如数学的函数一样，只要给定相同的输入值，就一定会算出相同的输出值。计算工作之间的相依性降低了，不论在那部机器上算、在什么时间点算，都不会影响到计算的结果。因此，当以「分而治之」的原则来拆解计算工作，以进行分散式的计算时，更容易拆解工作、更容易合成计算结果，以成为最后的结果。
通过一个更高阶的云端计算平台，以及计算模式，其实，可以让程式设计者更容易的取得规模可扩充性。而从现在的趋势来看，函数式的设计方式，应该还会再流行好一阵子。
