Archive for the ‘SaaS’ Category

(转)B2B2C,从营销的角度,来理解SaaS

2010-08-24

原文:http://www.xingbotao.com/?p=254,邢波涛发表于《程序员》2010.08期。

 

今年比较流行B2B2C(Business to Business to Consumer),所谓B2B2C是 “business to business to Consumer”的简称。

第一个B指广义的卖方(即成品、半成品、材料提供商等),第二个B指交易平台,即提供卖方与买方的联系平台,同时提供优质的附加服务,C即指买方。B2B2C当然是相对B2B、B2C、与C2C来说的。大家可能对B2B、B2C、与C2C比较熟悉了,例如,B2B的代表性企业是阿里巴巴、B2C代表性企业是京东商城、当当网等。而C2C的代表企业则是淘宝莫属了。B2B2C定义结合了现存的B2C和C2C 平台的商业模式,它将企业、个人用户不同需求完全整合在一起,缩短了销售链。从营销学角度上来说,销售链条中环节越少越好。它的创新性在于:它为所有的消费者提供了新的电子交易规则。该平台颠覆了传统的电子商务模式,将企业与单个客户的不同需求完全地整合在一个平台上。B2B2C既省去了当当卓越式B2C的库存和物流,又拥有淘宝易趣式C2C欠缺的盈利能力。正是看到了这些好处,阿里巴巴在今年展开代号“伏特加”收购计划,2010年6月25日,阿里巴巴收购美国电子商务SaaS提供商Vendio。而Vendio事实上,就是一个B2B2C的公司。

 

那么B2B2C跟SaaS是什么关系呢?

B2B2C技术架构上,后台不就是SaaS架构嘛?换了一个名词而已,不过内涵发生了极其重大的变化。狭义的SaaS是从管理软件的角度来看的,而B2B2C是从电子商务的角度来看的。B2B2C有自己的客户,就是商城买家,解决了供销一条龙,而SaaS只解决了中小企业并不是强需求的管理功能。而B2B2C正是从营销的角度来理解SaaS。我在Vendio上注册了自己的账户,体验了一下,其实并不太好用,跟国内的SaaS管理软件比教起来,功能还更简单,不过,Vendio上的数据,可以实现经由Vendio同一平台将产品直接上载到eBay、Amazon及Vendio支持的其他网上商店销售,这是帮别人赚钱啊,帮客户在eBay、Amazon上实现营销,所以它的前途是远大的。

 

我曾在自己的Blog里,多次呼吁要从营销的角度,来看到SaaS管理软件。我以前只看到过安居客的例子,安居客买断了Google和百度的租房信息,然后通过SaaS后台租房信息发布程序,卖给房地产中介使用,也是帮客户搞营销的思路。Vendio再次给我们讲了一个如何利用SaaS管理软件盈利的商业模式。而国内的管理软件,只会抱怨客户的管理不规范,有的SaaS管理软件公司逼着自己去做项目了,而有的,包括SAP这样的巨无霸,还躺在过去的经验里,强调标准化是SaaS软件的第一要素。只有实现了SaaS应用的标准化,提供商才能打造一个更透明、更开放的产业发展环境,这对SaaS产业的发展非常关键。如果管理方式都标准化了,使用SaaS管理软件的客户也就全部倒闭了。没有差异,也就没有中小企业生存的空间。

不过,以B2B2C做平台来推广SaaS,这个门槛也是非常高的,就跟亚马逊做书店,最后卖云计算一样,不要以为有了某种商业模式,就可以赚到客户的钱。

———————

Yew评:从营销的角度,而不是从管理的角度来看SaaS,这指明了SaaS在中国的发展之路。

图示SaaS:走向平台化,会产生什么变化?

2010-01-04

1、‘自产自销’通常都会出现‘酒香巷子深’的问题

image

2、平台化后,产生的变化

image

平台化,会导致收入结构的变化;

走向市场化的结果,即使会让单价降低,也会使自有产品的收入增加;

而总收益的增加将更明显。

===== by 鬼谷子@魔教 ======

http://Yewsoft.BlogBus.com

[SD2.0大会]开放平台沙龙:平台化的原因

2009-10-26

晚上的沙龙大家提了一个问题:为何要做平台?

与会的人都有个一致的认识:没有好处是不会去做的。那么做平台,究竟利益在何处呢?

我认为有5个具体的利益点:

      • 扩大User数
      • 汇聚资源:利用User汇聚更多的资源
      • 扩充功能来增值:由外部提供App, Service
      • 生态圈:形成专业分工 
      • 通过复用来节流:Share已有有基础设施、功能、服务。让有创意缺技术的合作伙伴产生好的创意。创造需求、做大、做好市场,平台和伙伴才能有更多的利益,共享利益。–from DaiGu

传统上,平台都是对内服务的(温昱第3天的一个Session就是谈此的),这实际上只能得到上述第5条好处。

事实上,前4条都需要对外。

通过对外服务,平台商可以获得2大利益:

  • 健身:丰富自己的用户、内容/产品,增强自身的服务能力
  • 扩大销售:可以从平台的长尾产品/服务上获益

我的观点是:不仅要做平台,更要做(对外)开放平台!

===== by 鬼谷子@魔教,更多内容在 http://DavyYew.BlogBus.com ======

http://Yewsoft.BlogBus.com

[CTO札记]SaaS/Cloud新实例:Google 计划明年开始销售数字图书

2009-10-21

一、Google Editions计划

Google 战略合作主管 Amanda Edmonds 星期三在法兰克福书展上宣布,Google 将在明年6月前推出数字图书(digital book)的制作和销售计划。一旦购买,读者可以通过网络随时随地下载、并可以使用多种工具阅读。
据英国出版行业刊物 The Book Seller报道,这个被称为 Google Editions 的计划,将会在明年上半年内,先在美国、英国和欧洲国家推出。

二、模式原理:云图书馆(cloud library)

所有的数字图书,都会贮存在一个“云图书馆”(cloud library)中,读者在购买图书之后,可以使用任何可以联网的阅读工具,包括电脑、智能手机(Smart Phone)和电子阅读器(eReader)等,在任何国家随时下载阅读。Amanda Edmonds说:“所有图书都放在同一个网络图书馆中,你在哪里买书、在哪里读书都随你。”

三、3种销售模式

image

四、其它

1)渠道参与

目前已经有一些网络书店参与了Google 的“数字图书预览”计划,这些书店很可能称为首批Google Editions的合作网络书店。

2)电子阅读器

Amanda Edmonds 还表示,

》Google 肯定会和电子阅读器生产商进行合作,但是拒绝提供合作生产商的名字;

》但是她对亚马逊书店的电子阅读器 Kindle 是否会成为合作者之一表示“存疑”。

3)产生的影响

Google 的举动,特别是Google 版权数字图书对阅读器的开放标准(注:Kindle的专有格式,并不对外开放),以及随时随地下载的保证,将会对电子阅读器的生产标准发生影响,还可能挑战目前图书版权按地域划分的模式。

===== by 鬼谷子@魔教,更多内容在 http://DavyYew.BlogBus.com ======

http://Yewsoft.BlogBus.com

《互联网时代的软件革命–SaaS架构设计》即将第3次印刷

2009-08-05

没想到这本书居然卖得这么快,8个月不到就要第3次印刷了:-)

互联网时代的软件革命SaaS架构设计-第1版 第一版封面

互联网时代的软件革命SaaS架构设计-第2版第二版封面

在线购书:

1)淘宝店:http://shop36954457.taobao.com/ (作者签名书)

2)China-Pub: http://www.china-pub.com/129900

 

===== by 鬼谷子@魔教,更多内容在 http://DavyYew.BlogBus.com ======

http://Yewsoft.BlogBus.com

雾里看花–我见SNS

2009-03-31

一、什么样的网站或社区才算是SNS?
首先,要知道SNS抛去商业色彩后,给人们带来的是什么,SNS其本质应该是以个人建立的与朋友相互交流、分享为目的的圈子,而又因为每个人都会有自己的朋友,通过SNS邀请其他用户组成自己的独立网络社会,从而最终成立一个庞大的关系网络。而我们常说的Web2.0,不也是一个以分享、交互为核心特点的时代么,网站也好、社区也罢,也是统统挂着这个头衔,但是它们为什么不能说是SNS呢,或是web2.0与SNS的区别是什么,弄清楚这个,其实标题的问题也就清楚了。SNS源于2.0,带着Web2.0的最纯正的血统,可以说,SNS关系网是2.0的一种升华。SNS建立的基础是圈子中的人,维系这个圈子的纽带是关系,是建立在相识、熟悉的基础上的,具有牢固情感或精神的联系的人的集合,而Web2.0中所提倡的还在是单向的分享,缺少互动的平台。所以,我觉得,当一个圈子演化成为一个团体或是一个社会,并且这里的人们间建立起了交流,那么SNS雏形就已经出现,这可能是通过Blog、社区、IM、论坛、视频或相册等媒体分享甚至是一个网站而存在。

二、SNS靠什么活着?
这个问题其实包含了两个层面,一个是SNS网络人们生存指数,是否能足够的人建立起圈子;二是SNS运营、SNS团队靠什么生存,其商业模式、商业价值、如何盈利。记得去年,在周围曾经非常的流行上开心网,基本上大家见面打招呼都是“今天你被我买去挖煤”,“我的车停你车库里,别贴条”之类的话。然而,逐渐的,大家也淡出了这个网站,至少没有当时那么狂热,为什么?再看校内、土豆和MySpace,前两者都有很明确,清晰的目标客户群体,在市场细分中,找到了自己的定位,黏住了特定的一群人:学生,应该是大学生,有较高的操作能力,如果有感兴趣的事情,可以有大量时间停留上面,本班、本院、本校然后再延伸到高中、初中、甚至小学,普遍有共同的话题;土豆:分享视频、观看视频的人群,在此过程中,对网站有较高的粘稠度,团体小、且分散,但是由于媒体信息的不断更新这一特性而不断有新鲜感,从而达到运营预期目的;Myspace:最初主要是从MSN转型出来,由于MSN累积的大量人脉关系而存在,但是由于这种建立在职业、工作上面的关系实际上稳定性并不高,还是停留在2.0时代,多次调整,网站在国内也几易其手,成效不太明显,多做为负面教案了。第二个问题我道行太浅,不敢妄加评论。

三、怎样的SNS网站才算成功的网站?
在国内似乎也没有特别的案例,感觉大家都是在摸着石头过河。记得看过robbin大牛的一篇关于《Facebook成功秘诀》的blog中,对于国内SNS的情况有一句描述,也是改了古人的一句话,叫“忽如一夜VC来,千万SNS缤纷开”。国内大多SNS都是模仿Facebook,模仿Myspace,但是死的多、活的少,都是靠着VC的大把钞票扛着,希望有一天能像Facebook那样,被微软看上,几亿美金收购点股份。而国内走在SNS领头方阵的校内,依靠它准确的定位和成功的本土化,在金融危机摧残过的IT行业中,通过VC融到了不菲的资金,成为很多SNS的榜样,但是对于整个SNS来说,通过08年的清洗,将会和云、和SAAS一样,刚刚拉开序幕。

华山论剑之web测试

2009-03-31

Web 测试的经验

1. 功能测试
1.1.
链接测试

   链接是 Web 应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证 Web 应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的 URL 地址才能访问。

   链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个 Web 应用系统的所有页面开发完成之后进行链接测试。

1.2.
表单测试

   当用户给 Web 应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。

1.3.Cookies
测试

Cookies
通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用 Cookies 访问了某一个应用系统时, Web 服务器将发送关于用户的信息,把该信息以 Cookies 的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。

   如果 Web 应用系统使用了 Cookies ,就必须检查 Cookies 是否能正常工作。测试的内容可包括 Cookies 是否起作用,是否按预定的时间进行保存,刷新对 Cookies 有什么影响等。

1.4.
设计语言测试

Web
设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的 HTML 等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了 HTML 的版本问题外,不同的脚本语言,例如 Java JavaScript ActiveX VBScript Perl 等也要进行验证。

1.5.
数据库测试

   在 Web 应用技术中,数据库起着重要的作用,数据库为 Web 应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在 Web 应用中,最常用的数据库类型是关系型数据库,可以使用 SQL 对信息进行处理。

在使用了数据库的 Web 应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。
2.
性能测试

2.1.
连接速度测试

   用户连接到 Web 应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果 Web 系统响应时间太长(例如超过 5 秒钟),用户就会因没有耐心等待而离开。

   另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

2.2.
负载测试

   负载测试是为了测量 Web 系统在某一负载级别上的性能,以保证 Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数量,也可以是在线数据处理的数量。例如: Web 应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象? Web 应用系统能否处理大量用户对同一个页面的请求?

2.3.
压力测试

  负载测试应该安排在 Web 系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个 Web 系统能同时处理的请求数量将远远超出这个限度,所以,只有放在 Internet 上,接受负载测试,其结果才是正确可信的。

   进行压力测试是指实际破坏一个 Web 应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试 Web 应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到 Web 应用系统崩溃,接着当系统重新启动时获得存取权。

   压力测试的区域包括表单、登陆和其他信息传输页面等。

3.
可用性测试

3.1.
导航测试

   导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个 Web 应用系统是否易于导航:导航是否直观? Web 系统的主要部分是否可通过主页存取? Web 系统是否需要站点地图、搜索引擎或其他的导航帮助?

   在一个页面上放太多的信息往往起到与预期相反的效果。 Web 应用系统的用户趋向于目的驱动,很快地扫描一个 Web 应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉 Web 应用系统的结构,因此, Web 应用系统导航帮助要尽可能地准确。

   导航的另一个重要方面是 Web 应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道 Web 应用系统里面是否还有内容,内容在什么地方。

Web
应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

3.2.
图形测试

   在 Web 应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个 Web 应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:

   ( 1 )要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。 Web 应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。

   ( 2 )验证所有页面字体的风格是否一致。

   ( 3 )背景颜色应该与字体颜色和前景颜色相搭配。

   ( 4 )图片的大小和质量也是一个很重要的因素,一般采用 JPG GIF 压缩。

3.3.
内容测试

   内容测试用来检验 Web 应用系统提供信息的正确性、准确性和相关性。

   信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用 Microsoft Word 拼音与语法检查功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般 Web 站点中的所谓相关文章列表

3.4.
整体界面测试

   整体界面是指整个 Web 应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览 Web 应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个 Web 应用系统的设计风格是否一致?

对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般 Web 应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。

   对所有的可用性测试来说,都需要有外部人员(与 Web 应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。

4.
客户端兼容性测试

4.1.
平台测试

   市场上有很多不同的操作系统类型,最常见的有 Windows Unix Macintosh Linux 等。 Web 应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。

   因此,在 Web 系统发布之前,需要在各种操作系统下对 Web 系统进行兼容性测试。

4.2.
浏览器测试

   浏览器是 Web 客户端最核心的构件,来自不同厂商的浏览器对 Java ,、 JavaScript ActiveX plug-ins 或不同的 HTML 规格有不同的支持。例如, ActiveX Microsoft 的产品,是为 Internet Explorer 而设计的, JavaScript Netscape 的产品, Java Sun 的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和 Java 的设置也不一样。

   测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

5.
安全性测试

Web
应用系统的安全性测试区域主要有:

   ( 1 )现在的 Web 应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。

   ( 2 Web 应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如 15 分钟)没有点击任何页面,是否需要重新登陆才能正常使用。

   ( 3 )为了保证 Web 应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

   ( 4 )当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。

   ( 5 )服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。

6.
总结

   本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于 Web 的系统测试方法。

基于 Web 的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于 Web 的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。

软件开发过程改进

2009-03-31

 

1.代码编写规范
2.代码高度抽象
3.避免使用”魔术值”
4.单元测试分享
5.善于使用framework里提供的方法
6.善于使用commons 里的方法
7.使用模型驱动编程,提高Action里的对象化。
8.Manager多用对象的多态性,提供外界调用
9.注意VM页面的编写规范

1.代码编写规范
1.规划实体类DTO
2.规划模型类MODEL
3.接口加注释
4.方法加注释
5.日志级别的判断与打印
6.异常的捕获与处理

2.代码高度抽象
1.对于常用模块与方法进行抽象
2.提取合适方法名作为类或抽象类的成员方法
3.使用多的方法多态性,供外界调用.

3.避免使用”魔术值”
1.在Manager里面不要使用魔术值。
2.在Action里面不用使用魔术值,类似webwork里的跳转语句.
 如 return “tradeList”
 private static final String  TRADE_LIST_PAGE=
“tradeList” 跳转到”交易列表页面”

4.单元测试分享
1.框架搭建TestBase;
2.注意BSF里面声明”服务”与注意服务的不同。

5.善于使用framework里提供的方法
1.可是使用ServletRequestAware, ServletResponseAware接口提供的方法获得
Request,Response对复杂业务对象进行处理
比如同名参数
6.善于使用commons 里的方法
1.优先使用com.alisoft.aep.commons.util的工具类,来辅助Action的验证逻辑
2.DateUtil,StringUtil,StringUtilExt,NumberUtil
3.在使用apache  commons  lang里面的工具类
7.使用模型驱动编程,提高Action里的对象化
1.自己编写的Action 一定要extend BaseAction 并且 implements ModelDriver.
2.对Action 得到的数据进行有效验证与完整性验证。
9.注意VM页面的编写规范
1.加入sitemech页面框架
2.加入title用户页面导航
3.加入全局样式
4.加入局部样式
5.加入全局JS包
6.加入局部JS模块
7.加入VM后台出错信息模块
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“>
<html xmlns=”http://www.w3.org/1999/xhtml“>
<head>
<!–页面框架–>
<meta name=”menu.id” content=”isp.workbench.api.register”>
<title>API 基本信息</title>
<!–页面样式–>
<link href=”$env.staticServer/css/header_isp.css” rel=”stylesheet” type=”text/css” />
<link href=”$env.staticServer/css/global.css” rel=”stylesheet” type=”text/css” />
<link href=”$env.staticServer/css/layout_isp.css” rel=”stylesheet” type=”text/css” />
<link href=”$env.staticServer/css/layout.css” rel=”stylesheet” type=”text/css” />
<link href=”$env.staticServer/css/css02.css” rel=”stylesheet” type=”text/css” />
<link href=”$env.staticServer/css/check.css” rel=”stylesheet” type=”text/css” />
<style type=”text/css”>
.STYLE2 {
color: #008DF6
}
.STYLE5 {
color: #FF3300
}
</style>
<!–页面脚本–>
远景目标
1.代码更易维护与扩展
2.有信心对代码重构
3.前人栽树,后人乘凉
4.使用单元测试,了解业务流程

快速上手appEngine

2009-02-20

最近大家都在谈云平台,放眼互联网业界,感觉真正很power很易用应算google的appEngine了,从了解,上手,学习python到部署,我大概只花了一天时间就让我原来写的一个portal聚合的网站在appEngine跑了起来,第一次感觉到云的强大,上手步骤如下:

1)大概了解

http://code.google.com/intl/zh-CN/appengine/

2)注册帐号(如何已有google帐号,此步可省略)

3)学习python(如何已会python,此步可省略)

4)开发应用(我是通过python重写原有应用)

5)下载sdk

6)通过sdk和相关命令,把应用上传到appEngine

7)通过管理平台管理系统,功能包括流量监控,系统硬件监控,版本控制,log监控等等,基本包含网站管理的基本设施。

通过以上基本做下来,我就能看到自己的应用了(http://cutesource.appspot.com/),初步感觉这样搞网站非常省时省力,我们阿里以后要搞商业云,虽然业务模式不一样,但多多少少还是可以借鉴一下appEngine的设计理念,让使用者真正感受到云的威力。

阿里的’云’是怎样的?

2009-01-06

回答一下网友LonelyBug的问题:

云计算概念很广,但是如果专著在一点上,便可以在可以接受的时间内得到收益,不知道阿里现在做的云计算服务属于那种?

 

也许是‘计算’这个词缩小了‘云计算’的含义,让人误以为等同于‘分布式计算’或者‘网格计算’。

 

业界大部分人认为,‘云计算’包含:
>SaaS
>PaaS
>HaaS or IaaS (包括:存贮、计算)

Cloud and SaaS

阿里的云强调PaaS与SaaS,我们的概念是‘商务云’,http://tech.sina.com.cn/i/2008-12-30/16132705752.shtml

细分一下商务云,它主要包含二个内容:
》面向终端用户:Application Cloud –>SaaS平台AEP
》面向软件开发商:Service/API Cloud –> PaaS平台SIP

Multi Clouds