主题：【原创】云里雾里的云计算 [1] -- 邓侃
家园 SAAS的思路 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上。这倒通用，但是代价是不是太高？
- 复 SAAS的思路
家园 SAP同样面临各个企业不同应用的问题 1.
所以才会有三种定制方式：
1. 合适的话直接用SAP提供的大模块
2. 流程不合适，就用customized workflow结合SAP的小模块，构成企业自己的大模块
3. 连小模块都不合用，只好用户自己开发了。不过SAP是在用户端，SAP管不到。但在云端，用户自己定制的模块肯定要经过google certify的。
有这三个方法，SAP（或google）可以应付90%的客户，那何必在乎剩下的呢？
2. 对于这个我不太懂，自己揣摩了一下，是否可以借用SETI@home的思路：
用一组服务器把模块分解到线程，另一组服务器执行分解后的线程，而第三组服务器负责实时监控前两组服务器的负载，并动态调整下一组模块（线程）的运行服务器。
不知道这个思路是否有利于balance.
家园 问题就出在这里 1.
3. 连小模块都不合用，只好用户自己开发了。不过SAP是在用户端，SAP管不到。但在云端，用户自己定制的模块肯定要经过google certify的。90%的模块都好办，Google可以代劳。就是这剩下来的10%的外来模块，最让Google头痛。
不知道你说的Google certifying，具体是什么想法。
其实，如果能有办法应付那10%的外来模块，那么外来模块的比例就不必限于10%。换句话说，Google没有必要代劳90%模块，他只需要专注于技术含量高的少量模块，至于那些劳动密集型的模块，留给其他企业好了。
2.
2. 对于这个我不太懂，自己揣摩了一下，是否可以借用SETI@home的思路我想说的就是这个。只是SETI的软件，功能比较单一，拷贝分发即可，难在数量比较多的软件，如何分发，以及如何平衡资源使用等等。
思路和SETI@home差不多，但是实现细节会更麻烦，我感觉。
- 复 问题就出在这里
家园 我说google certifing是为了用户开发的模块 不会crash google的服务器，也不会对其他用户有安全隐患。类似于MS认证了某个软件可以安全运行于Vista一样。
2.
其实我说的不是分发软件，而是分发线程。所有软件都在cluster A上运行，但这个运行不是出结果，而是把软件分解成线程，然后由dispatcher（cluster C）把分解出来的线程分发到cluster B运行出结果，再通过cluster D返回用户。
当然，我这说的轻松，其中肯定有涉及到网络操作系统原理的N多困难。不过既然SETI可以都实现分发到用户端去执行，google未尝不可啊。
家园 软件认证，分发线程 1. 软件认证。
这个思路好，让第三方软件在一个sandbox里先跑跑，严密观测它对资源的使用情况。如果确认没问题，再放出来在云计算平台里运行。
类似于西西河的新兵营制度。
2. 分发线程
分发线程的做法当然比分发软件先进。但是SETI的软件只有一个，手工把软件分解成线程也未尝不可。
如果软件有千千万万，分解成线程的工作，必须自动完成。这个工作不容易。
家园 分发线程 2. 分发线程分发线程的做法当然比分发软件先进。但是SETI的软件只有一个，手工把软件分解成线程也未尝不可。
如果软件有千千万万，分解成线程的工作，必须自动完成。这个工作不容易。
我没有学过操作系统原理和相关知识，自己胡猜的，不对的地方拍砖下手轻些。
对于google自己写的模块，google肯定很容易就可以将其按线程归类，分别分配给不同的cluster运行。关键在于第三方的线程。
我有这么两个思路：
1. 第三方模块如果使用不频繁且占用CPU和IO少，就不用分拆了，直接运行得了。
2. 如果确实使用频繁，
a。就用google的线程管理API替代系统的，以便于google云端分析分发指令。
b。由google提供的编译器将其编译成伪指令码，在运行时有专用的服务器分析这些伪指令，并分配
- 复 分发线程
家园 Insightful ideas 1. 第三方模块如果使用不频繁且占用CPU和IO少，就不用分拆了，直接运行得了。同意，相信大家都会同意。
2. 如果确实使用频繁，a。就用google的线程管理API替代系统的，以便于google云端分析分发指令。
这是在模块内部分拆，做并行处理。MapReduce就是干这个的。APIs已经有，但是目前Google没有公开。
2. 如果确实使用频繁，b。由google提供的编译器将其编译成伪指令码，在运行时有专用的服务器分析这些伪指令，并分配。
把源程序编译成Assembly, 在Assembly层面分析代码逻辑，然后见机自动使用MapReduce。
这个思路值得研究，非常有启发。
只是不好做，太多有待研究的课题。好做的办法是分发软件，和分发线程。
家园 分发软件可以，分发线程？ 估计悬。线程之间是共享内存地址空间的，分到不同地址空间都不行，分发到各个机器上面就更不行了吧?
如果是java的话，分发jar和虚拟机还可以。但是对资源的使用限制，特别是CPU的时间限制，就牵扯到图灵停机问题了。
家园 说云计算不提Amazon不合适吧 说起来难以置信，这个回帖两天之内接连两次打了几千的字，最后发之前或是browser死了或是加个图片链接文字全消失了。看来上天有意不让我在这个题目上多说，是不是我露了什么天机呢？ 呵呵。
建议老铁把Gmail的javascript打开了看看，加个分时存（Draft）的功能什么的就好了。
家园 Amazon的云 先用其它工具，譬如wordpad写好草稿，然后再腾到西西河发帖工具中去。
Amazon S3之类，我会放在后续章节中谈。比较Google的云，与其它公司的云有什么不同。
但是不打算展开详细谈，否则这个话题就收不住了。那厢催我谈WebOS催得紧呢。
- 复 Amazon的云
家园 Amazon至少已经商业化了 Google的还在探索。 GAE正如你上面说的，存在许多不实用的问题。 云计算面临的许多问题是软件怎样搬到云里去的问题，这个不是简单改写就可以了，虽然微软的Azure试图让大家相信是这样的，但没多少人这样想，GAE则连想都不用想。另一个大问题是大企业，数据安全问题，在这一代CIO退休之前，把数据托管到云里去的观念还有很长的一段路走。当然，中小企业，个人销费者的应用，云计算还是大有可为，而Amazon是这个方向上的领头羊，Google除了给自己用的GFS等外还谈不上大规模面向客户的云计算。
云计算的一个没有明说的最佳方案是大家都把应用软件向互联网网站转移，如果从用户角度讲，能够随时随地使用自己的数据则网站类应用是绝对优势。但互联网日趋个人化的一个结果就是入Allen下面说过的我的XXX之类的个人化应用，事实上Google搜索在面对Facebook，myspace等数据的无效性已经成为Google的一个死结，这样的云是不是Google希望的云还是很大问题，弄不好这就是Google走下坡路的开始。
说道个人化离不开微软的个人电脑。我丢掉的几千字主要是在说微软的云，虽然微软也在每年花几千万建data center，但其最有野心的与云有关动作是在Mesh上。谈Mesh就不能不谈Ozzie，就不能不谈Groove，实际上Mesh可以说就是个互联网上的Groove。Mesh前几天刚得了个Crunchie的最具创意奖。下图中间那个白头发的就是Ozzie。
外链图片需谨慎，可能会被源头改微软心中的痛就是那个著名的wintel在互联网将个人电脑终端化的过程中，看不到未来。即以网站模式为主要应用的互联网，数据与计算都是集中在几个点上，这些点就是网站，而访问这些点成为用户使用互联网软件的主要方式。 因此微软不论做什么，总会隐含着把数据计算引回个人电脑的企图，这关乎其安身立命之地。Mesh即是微软的“云”也是微软与以浏览器为主的HTML+Javascript+CSS为代表的一代互联网应用的对抗。如果说浏览器的普及让用户可以随时随地的使用软件，那么Mesh的最终目的也是同样，即让用户感觉不到电脑的界限，因为用户的数据是跨电脑的存储，软件计算是在Mesh上面虽然同时也在电脑上。如果微软这一步走成，很可能带来的是推翻浏览器一统互联网应用江湖的革命性变化，比较浏览器其最大的优势就是个人化应用的进一步丰富，互动性的进一步超越Ajax，Flash/Flex，Sliverlight等的回归桌面应用的高级应用。
但Ozzie的这一招能成么？是否野心太大了。Ozzie加入微软是从开发Groove被微软收购开始的。Groove就是一个P2P式的办公软件应用，这是8年前的事。在这之前Ozzie是著名的Lotus Notes的发明者，后来被IBM收购去后自己继续创业。Groove最终被Office 2007收编了，但推广上并不是很成功。从Ozzie的历史看，他是一直有着把互联网向P2P方向推进的想法的，因此，微软心中的云与Amazon，Google的云有着很大的区别。
本帖一共被 1 帖 引用 (帖内工具实现)
家园 S3 目前是 Google Apps 最大的竞争对手 确实不该漏掉。Amazon 作为 B2C 横插一杠子是非常天启的妙手。
马云那个中国云恐怕有点照猫画虎。
P.S. My Condolence
家园 【原创】云里雾里的云计算 外一篇 关于云计算概念如何粉墨登场，我们再详尽地八卦一下。
Google对外推出云计算这个概念有偶然因素，一个叫做Christophe Bisciglia 的 Google 工程师在自己的母校（University of Washington，坐落于微软的大本营附近）开了两门课讲GFS 和 MapReduce，告诉学生们微软落后啦，未来都是服务器端的应用，Google已经为此开发出服务器端的存储（GFS）和计算方法（MapReduce），所以同学们今后可以考虑用这些技术来对整个互联网进行计算操作，学生们很兴奋，Christophe也看到自己的机会。
他的技术水准也到不了哪里去，但是能忽悠，回到公司一报告，使得Google的CEO等人觉得：对啊，如果大学生们都只会学单机上的OS和编程，以后他们即使有好的互联网方面的想法，也只会是Google的敌人，何不趁此机会，推广一下自己的infrastructure，让孩子们有了想法都直接在 Google平台上实现，岂不化敌为友，还将微软一军？
然后，高管们就开始运作铺天盖地的“云计算”概念。
在Christophe的课程中，一位大二女孩子的小项目吸引了一位idea满天飞的朋友。女孩子的项目简单到有点可笑，她就是把世界上主要报纸的内容爬下来放在GFS里，然后根据新闻的发生地用MapReduce聚类，把同一地区的新闻标注在 Google Maps相应的位置上。
这也太简单了吧，杀鸡何用牛刀，几个scripts和一个硬盘就搞定的事何必用云计算呢？非也。我和那位拥有无数狂野ideas的朋友聊到这个小事——这发生在“云计算”进入公众视野之初，绝大多数人还云里雾里的时候。朋友想想说：不错，这样一来，互联网对我来说就透明了，原来掌握在少数公司手里的资源现在我这等人也可以拿到了，只要有想法，钱还不花花的。
都是八卦，大家一笑了之吧。不过朋友的一堆主意都很有意思，虽说如Allen兄预测的那样，都和数据挖掘相关，但是考虑到commerce可以做成街边小店，也可以做成沃尔玛，数据挖掘也有挖得出金子的。
个人认为，云计算的计算部分更是精华，存储量大就好像一个人有肌肉——怎么着，我就是比你壮。但是如果加上计算，就好像肌肉男还有聪明的大脑。其实邓侃已经认识到这个问题：Google开放了GFS，MapReduce, BigTable，但是没有介绍大型集群里的RAM管理——不是Google没做，而是它没讲。所以，我们绝对不要轻视计算，那才是Google的精华所在。
关键词(Tags): #邓太，