主题:【原创】云里雾里的云计算 [1] -- 邓侃
其实我说的就是放电影,不是嘛?只是这个电影的内容是你的应用,而且非常互动。
那么目前似乎HDTV标准的bit rate都是1M上下,也就是家里HDTV的清晰度(只是计算机显示器没那么大,所以视觉效果还会更好些)。那么对于游戏这类极端应用,我就斗胆放宽到10M,似乎也不是遥不可及的科幻。
光靠“MC”,肯定斗不过现在这么多部件组成的PC产业。不过一旦应用都走上了云端,哪个还会去买超级PC呢?到那时候,就不一定会是硬件领导软件了。
至于你说的那10%因为各种因素不能放在云端的应用,google也没有必要硬抢啊。MS现在也没有到100%市场份额嘛,google也该没有这个野心吧。
>>4.当每个人都经常要用到超级服务器的计算能力的时候,那么硬件设备厂商努力的把超级服务器的计算能力放入个人电脑,是很显而易见的方向。
sorry, but I can't see it. 每家都需要很多电力,也不见得每家建一个发电厂,或者买很多蓄电池。电能(计算能力)的生产,还是放在云端,效率比较高些。
1.
所以才会有三种定制方式:
1. 合适的话直接用SAP提供的大模块
2. 流程不合适,就用customized workflow结合SAP的小模块,构成企业自己的大模块
3. 连小模块都不合用,只好用户自己开发了。不过SAP是在用户端,SAP管不到。但在云端,用户自己定制的模块肯定要经过google certify的。
有这三个方法,SAP(或google)可以应付90%的客户,那何必在乎剩下的呢?
2. 对于这个我不太懂,自己揣摩了一下,是否可以借用SETI@home的思路:
用一组服务器把模块分解到线程,另一组服务器执行分解后的线程,而第三组服务器负责实时监控前两组服务器的负载,并动态调整下一组模块(线程)的运行服务器。
不知道这个思路是否有利于balance.
Google Chrome的目的就是为了在客户端有一个稳定的,能高效地运行各种从cloud里面传送过来的Application,摆脱或者尽量减小各种客户端OS对cloud computing的影响,使cloud端的Apps开发简化。
Google要出OS? 哪里的消息?
Google要出硬件是什么意思?
2002年就加入Google了,这谣言也有点太穿越了
1.
90%的模块都好办,Google可以代劳。就是这剩下来的10%的外来模块,最让Google头痛。
不知道你说的Google certifying,具体是什么想法。
其实,如果能有办法应付那10%的外来模块,那么外来模块的比例就不必限于10%。换句话说,Google没有必要代劳90%模块,他只需要专注于技术含量高的少量模块,至于那些劳动密集型的模块,留给其他企业好了。
2.
我想说的就是这个。只是SETI的软件,功能比较单一,拷贝分发即可,难在数量比较多的软件,如何分发,以及如何平衡资源使用等等。
思路和SETI@home差不多,但是实现细节会更麻烦,我感觉。
MUD可能是最初阶段的网络游戏了。服务端有台MUD服务器,客户端是个telent终端。通过telent终端,玩家可以指挥自己的人物在游戏场景里东奔西走,打打杀杀,或者谈情说爱。与现在的网络游戏相比,MUD是文字界面的,最多是有了彩色,或者用文字组成“图案”。
MUD游戏有很多种,而客户端只有一个——telnet。这个与云计算的目标有些类似:在云端运行的应用种类繁多而且要求不一而足,但客户端只有一个就可以满足所有的应用。所有的游戏场景(应用模块数据,云存储)都存储在服务端,玩家输入角色的参数(企业数据),输入指令(企业应用要求),而服务端则根据模块数据,用户数据以及用户指令,计算出结果(企业计算),并回馈给用户,修改屏幕上的游戏场景,和角色状态(report)。
perfect?
呵呵,先抢占手持设备,不知道google为什么这么做。
不会crash google的服务器,也不会对其他用户有安全隐患。类似于MS认证了某个软件可以安全运行于Vista一样。
2.
其实我说的不是分发软件,而是分发线程。所有软件都在cluster A上运行,但这个运行不是出结果,而是把软件分解成线程,然后由dispatcher(cluster C)把分解出来的线程分发到cluster B运行出结果,再通过cluster D返回用户。
当然,我这说的轻松,其中肯定有涉及到网络操作系统原理的N多困难。不过既然SETI可以都实现分发到用户端去执行,google未尝不可啊。
用云计算平台,来支撑网游,肯定是将来云计算的一个killer application。
网游不仅仅需要云存储,而且需要云计算,可以全面体现云计算的优势。
但是老问题依然存在。网游是内容导向的产品,搞不好会得罪人,而且怎么得罪的,预先甚至不知道,防不胜防。
从Google之类云计算提供商角度出发,最好是专注于技术支撑,而不去涉足网游的设计。
但是如果让第三方设计网游,1. 如何控制它对云计算资源的调度,2. 如何防范它的越轨行为。
这两个老问题,还是绕不过去。
1. 软件认证。
这个思路好,让第三方软件在一个sandbox里先跑跑,严密观测它对资源的使用情况。如果确认没问题,再放出来在云计算平台里运行。
类似于西西河的新兵营制度。
2. 分发线程
分发线程的做法当然比分发软件先进。但是SETI的软件只有一个,手工把软件分解成线程也未尝不可。
如果软件有千千万万,分解成线程的工作,必须自动完成。这个工作不容易。
我只是用MUD对比说明云计算的使用。
google除了企业计算,不必关心内容。至于网游之类的应用,可以由google提供云计算平台和存储能力,由下游ASP提供自主开发的应用(经google认证安全可靠高效),利用google的云端运行后分发给用户。这样的模式,google基本上可以躲开内容供应商的帽子了。
控制第三方对资源的调度,可以通过控制存储的quota,计算能力的MIPS或者优先级来实现。当然,这完全取决于google云端的设计。我们这儿只能说说自己的想法而已。
防止越轨比较简单。存储上的安全控制,线程上的防止内存溢出之类的都是技术手段。应该难不倒google。
防止越轨比较简单。存储上的安全控制,线程上的防止内存溢出之类的都是技术手段。应该难不倒google。
完全同意。
只是Google好像还没有做,至少还没有announce。
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 帖 引用 (帖内工具实现)
保密性的问题,我下一章就谈。
企业IT业务托管,不仅仅是技术层面的问题,而且涉及到Google的竞争战略。搞不好会树敌太多。
1.Chrome与其它的GOOGLE团队(主要是后台业务)依然处于隔绝状态。
2.Chrome目前的主要工作集中在整个程序框架的验证和稳定过程中,相应的“特色应用”方面的工作还没有展开。比如,Chrome还没有一个类似FIREFOX ADD-ON的API.
3.在clinet端,也许GOOGLE正在以新的方式来取代在别的浏览器上进行的开发工作,例如GOOGLE工具条。具体如何发展,大家拭目以待。