主题：【原创】云里雾里的云计算 [1] -- 邓侃
确实不该漏掉。Amazon 作为 B2C 横插一杠子是非常天启的妙手。
马云那个中国云恐怕有点照猫画虎。
P.S. My Condolence
希望到时候美国反垄断机构会有所说法，毕竟美国商业也不是google一家能说了算的。
就好了。具体OS如何管理地址分配，进程优先，倒确实是“一般用户”不用考虑的事情。
1. 人们对于计算能力的要求远远没有达到尽头，大量的工作和娱乐都需要强劲的芯，不管是 CPU 还是 GPU, 更快更高更强仍然是长期的主要诉求
我所知道的所有“工作和娱乐”中的应用要求的都是超级计算能力，而不是输入输出能力。以游戏为例，如果云端可以包揽所有AI以及3D渲染，接受键盘鼠标的输入，然后把处理好的画面送给显示器。而此时，NC所需要做的只是接受键盘鼠标的输入，以及把云端送来的画面以每秒xx帧的速度显示出来而已。这样的处理完全不需要多好的CPU或者GPU。一个能够流畅播放电影的瘦客户端足以胜任。
2.Google 运算能力强大的计算机集群是建立在超大规模的 PC 产业基础上的
如果云计算成为主流，那么除了微软外，Intel和NVIDIA也可能是受害者。但可能网络（终端和局端）厂商，显示器（或者projetor）厂商，内存厂商等等会成为受益者，他们将组成未来的PC产业基础。没了张屠夫，就吃带毛猪？没了Intel，PC产业也不会彻底垮。就算PC产业垮了，另一个新产业（NC？呵呵）也会崛起。
3. 在不远的将来，手持平台也会不再必须依靠云端。
同上。如果云计算能够主导市场，手持设备作为IT产业很小的一个分支，必然会跟随IT潮流而不是主导IT产业。到时候，手持设备的发展也许会与现在重点不同了。
我个人倒是很看好云计算。这样的处理可以最大化集中资源于最有优势的人。从社会角度来看，效率是显著的。要不每个人都买一个超级服务器，不是浪费嘛。唯一存在的问题就是垄断。不过我相信未来也会把数据垄断作为垄断的一种加以限制。
google不是靠诸如chrome的软件赚钱的，就像MS不靠IE赚钱一样。按照邓侃的思路，云计算是google未来赚钱的方向，那么gadgets就是云计算与用户之间的桥梁。那么gadgets如何显示呢？当然用chrome（的核心）显示，万一IE使坏googel不就傻眼了；在什么OS上呢？当然不能在windows上，所以google要推出OS。至于google如果要出硬件，也是为了云计算服务的。
你什么都做了，上游下游全做完了，让别人喝西北风去啊
何况做社区是内容敏感的东西。万一哪个社区做的得罪了什么人，到时候死都不知道怎么死的。google不会不考虑到这点。
。google当然不可能在发展云计算的初期就部署一堆超级计算机，但把内容放在客户端那边。那它就不是google了。先把内容拿过来，有了内容，凭google的技术，再整合10万台超级计算机做计算平台，还不是很easy的事情？到时候，从meta data到经过BI的report都有，试问IT世界，谁与争锋？
先用其它工具，譬如wordpad写好草稿，然后再腾到西西河发帖工具中去。
Amazon S3之类，我会放在后续章节中谈。比较Google的云，与其它公司的云有什么不同。
但是不打算展开详细谈，否则这个话题就收不住了。那厢催我谈WebOS催得紧呢。
【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目前都没有实现，所以云计算平台，对于第三方开发人员来说，暂时不是计算平台，而是存储平台。
好在google自己技术上也不怕MS，而且好的WP产品很多，需要的时候google收购来几个就OK了。而且，目前google doc是基于OOo的，基本功能足够一般用户使用了。
还有激光剑一样，属于科幻小说的范畴，跟现在狂推的云计算实在无法有现实的联系。自来水式的计算能力的愿景，是最好的描述。
矛盾的是依照此种逻辑，那么现在火爆的各色 RIA 以及大票的本地 Framework Runtime LLVM 的优化又有什么意义呢？我们不是跑步进入社会主义了吗？只要输入输出，网络接口，浏览器的最简化的终端，我生造个词叫做 MC (Minimalism Computer) 如何？
——————————————————————————
2. 你的意思是说云计算服务商的硬件需求所支持的处理器等硬件产业，可以在规模效益上打败现在的PC产业？Case in Point： 通讯设备产业，手机对基站设备。
——————————————————————————
3.确实未来的方向两者皆有可能，但"90%使用云计算"的说法不是我的，是 Eric Schmidt 的。任何平台，一个躲不过的问题——剩下的10%怎么办？NC做不到的等于我不需要？当我为了这10%已经付出了代价得到了一台计算能力强劲的PC终端，云端怎么说服我去使用它的计算能力？Free? Nothing is Free, Period.
——————————————————————————
4.当每个人都经常要用到超级服务器的计算能力的时候，那么硬件设备厂商努力的把超级服务器的计算能力放入个人电脑，是很显而易见的方向。云计算只在我们需要偶尔的使用某些超乎寻常的计算能力的时候，才有意义。
把汉字“一”原来为1234的GBK码换成了9876的“加密码”。这样的加密太简单太容易破解了。
12345678（假如二是5678的话），而一二三加密后肯定不是1234567890ab。同理，关键词加密后的密文，肯定与关键词在上下文中加密后的密文不相关。
而且google用的加密算法肯定要得到大家的认可，最省事的做法就是用通用的加密算法base64, des之类。这类算法大多采用了与明文无关的随机变换，没法做密文的关键词匹配的。
首先google可以提供很多模块，有大模块，如Interview模块，然后再提供小模块，如Interview模块中包含的appointment, phone interview, in-person interview, evaluation等等，并提供workflow工具。这样用户即可以用现成的大模块实施业务，也可以利用这些小模块和workflow构造出自己的interview模块。甚至，google还可以接受用户自定义的certified的模块以实现特殊的应用。有了这三种方法，我相信google可以应付99%的企业计算了。
而对于每个模块的执行，gogle可以在设计时对workflow实施优化，也可以实时监控并根据服务器负荷做real time balance。这个在稍稍大型的软件中都不是新技术了。
1. 第三方模块是否需要？
把各个企业都需要的ERP，CRM之类，搞成标准模块，然后由客户组织Workflow。对于这些popular的模块自然是可以这么搞，但是小众的模块怎么办？
让Google工程师去开发？代价高，但是收入少，Google肯定不干。当然，如果Google认为，只需要掌握大众模块，抓住80%的用户即可，不必理会小众模块，那倒也省了麻烦。
不过，即便是大众模块的Workflow，中间难免会穿插一些针对每个企业定制的模块。
所以，我的结论是，完全让Google代办所有模块的开发，是行不通的。Google绕不开让第三方开发自己的模块这个问题。
2. How to balance?
Real time balance的问题，其实我在想software migration。一个模块，本来只是安装在机器A上，现在要把这个模块，自动复制到机器B和C上，怎么办？
Xen的思路是，不需要复制软件，只需要把机器A的kernel，复制到机器B和C上。这倒通用，但是代价是不是太高？