【5】是云计算，还是云存储？
Gadgets的目标是方便大家建网站。但是单靠gadgets，建网站的工作还是不够方便。
通常网站有三个组成部分，1. 网页，2. 业务逻辑， 3. 数据存储。如果说网页相当于商店，那么业务逻辑相当于车间，而数据存储相当于仓库。商店，车间和仓库三者中，技术含量最高的，当属车间。
Manufacture in old time Courtesy http://www.atlantic-cable.com/Cables/1857-58Atlantic/Cable-Manufacture.jpg
车间管理可以大致概括为两件事，1. 工艺流程，2. 资源调度。工艺流程关心的是，先做什么，后做什么，才能生产一个完整的产品。资源调度的问题是，哪个工人，用哪台机器，在哪个时间，做什么。
网站的业务逻辑处理，大致来说也分业务流程和资源调度两部分。
流程的设计，每个网站不尽相同。譬如有两个网站，一个招聘人才，另一个销售图书，它们的业务流程非常不一样。但是销售图书的网站，与销售电器的网站，它们两者的业务流程相对比较接近。
流程设计千变万化，而资源调度却有章可循。所谓计算机资源，无非是这五种东西，1. CPU，2. RAM，3. Disk，4. RAM-Disk IO，5. Network。资源调度，无非是优化使用这五种资源，使之在最短的时间内，完成分配来的工作。
优化使用这五种资源，目标挺明确，实施起来却相当不容易。一日偶遇一仙人，谈到计算资源调度优化的问题，仙人说，他有一套五行八卦的优化办法，用中国古代智慧，解决当今科技难题。我把仙人的办法概括为以下几个要点，
1. 五行相生相克，系统优化不能偏执单一资源的优化。
2. 系统的总体效率需要一个测度，这个测度被称为“阴阳度”。
3. 阴阳度不是五种资源的简单加权和。阴阳度与五行的关系是非线性的，这种非线性关系可以参照河图洛书来确定，譬如规定五行中土的阴阳度为0，河图数零点的阴阳度为-5，洛书数零点的阴阳度为-10。
4. 时刻监控系统总体的阴阳度，阴阳度变化的正常模式可以分为太极，太虚以及太一三种。
5. 当阴阳度的变化偏离了正常的模式，就需要对系统进行调整。调整的办法参见“说卦”中的六种范式，即洛书逆式，先天八卦，后天八卦，神也者，洛书顺式，和乾坤六子。
仙人的办法听上去很有美感，但是操作起来却有难度。正在困惑之时，听到Google宣布，“我有办法解决资源调度问题，你们只须专注于业务流程”，确实为之感召。
Google的解决办法，是AppEngine。 Google AppEngine logo Courtesy http://img.genbeta.com/2008/04/google-app-engine.png
问题是，Google AppEngine真得能够优化任何业务流程的资源调度吗？
譬如有人想建一个人才招聘网站，招聘的业务流程如下图所示。Google打算劝说这个人把网站建在Google云计算平台上，做为技术支持，AppEngine应该提供哪些功能？
Recruiting process business logic Courtesy http://www.infoq.com/resource/articles/seven-fallacies-of-bpm/en/resources/job_application_process.jpg
猛一看，觉得很容易，流程清楚，算法简单。只需要把流程中诸多环节，归并成几个模块，即大功告成。
再看看，事情没那么简单。整个流程不是从头到尾一次走完，譬如interview会有好几次，然后过几天才会发offer。所以，应当把整个流程的每个模块独立出来，封装成服务，每个服务能够独立运行。召之即来，来之能战。平时不用，不占资源。
SOA（Service Oriented Architecture）还有一个好处，是便于重组业务流程。譬如系统上线以后，发现在面试（interview）以前，还需要添加一个电话约谈（phone screen）的环节。如果流程中每个服务都能独立运行，添加新的服务就很容易，不至于造成牵一发动全身的局面。
SOA的结构设计，有很多优点，但是仍然有遗留问题。如果同时有很多人使用这个招聘网，系统的吞吐量需要随之加大，怎么办？增加系统吞吐量的办法，有两条思路。
第一种办法是购置多台机器，每台机器上安装所有服务。当很多人同时使用招聘网的时候，把他们的需求均匀转发到各个机器上去，这样每台机器的负载都不大，但是整个系统的吞吐量增加。
第二种办法的效率更高，它可以用数量较少的机器，达到和第一种办法相同的吞吐量。或者，用相同数量的机器，在更短的时间内完成所有任务。这种办法首先分析每个服务耗费的资源，譬如CPU时间和RAM空间等等。然后给资源耗费量大的服务多分配几台机器，以免它们成为整个业务流程的瓶颈。
第二种办法虽然有很多好处，但是实现起来有些难处。首先是如何监控和分析每个服务的资源消耗，其次是如何自动把服务从一台机器转移到另一台机器去运行。
或许有人会问，为什么不提多线程的办法呢？所谓多线程是把多个任务交给多个线程去完成，这些线程交叉使用CPU，IO，Disk等等资源，减少使用这些资源前的排队时间。多线程的办法，关注的是每个服务的实现细节。而我们刚才讨论的，是服务与服务之间怎么整合的问题，所以，是不同层面的问题。
又有人问，为什么不提MapReduce之类并行处理的办法？与多线程一样，MapReduce关注的是每个服务的实现细节，是不同层面的问题。
回到前面的问题，如果Google打算劝说大家把网站建在Google云计算平台上，做为技术支持，AppEngine应该提供哪些功能？
1. 开放更底层的APIs，而不仅仅是Python的APIs。便于第三方开发人员，实现逻辑复杂，以及资源使用方式复杂的模块。
2. 提供IDE，方便第三方开发人员，把模块封装成符合Google云计算平台规范的服务。
3. 开发调度工具，用于监督各个服务资源消耗，分配合适的机器去负责各个服务运行等等。
4. 开发预警和修复工具。开放自己的平台，去运行第三方人员（外人）开发的服务。对于Google来讲，有理由提高戒备，预防云计算平台崩溃，万一崩溃了，能够迅速修复。
这四个功能，AppEngine目前都没有实现，所以云计算平台，对于第三方开发人员来说，暂时不是计算平台，而是存储平台。