11月3日，是新浪云计算3周年，于是有了这篇文章。但是因为懒，所以现在才写完。完全是个人的一点回顾，不代表官方立场。

   从09年回到新浪负责云计算的产品，转眼3年了；新浪云也已经从一个几个人的团队，成长为快50人的部门了。09年的时候，我们还不知道什么叫云计算，现在连专家都能数出来云计算的层次了：PaaS、IaaS和SaaS。

PaaS时期

   08年的时候，我创过一次业，主要在校内开放平台(就是现在的人人了)上做社交应用，但我都不好意思和别人讲我是做应用的，因为我一大半的时间都是在弄服务器。

   我本来是个PHP程序员，哪儿想过要自己买服务器、自己找IDC托管、自己抱着一台1U的Dell去机房配置网卡地址…… 但只要你想创业，这些都是不可避免的。那时候的我痛恨各种命令行，只会配置GUI界面的软件，前段时间我打开那台服务器倒数据，发现我安装的居然是桌面版的Ubuntu。

   一年下来，我发现自己的业务没什么长进，对Linux倒进步神速。虽然每一个PHP程序员上辈子都是折翼的前端、美工和系统管理员，但我依然梦想着有一天，有一个团队能帮我搞定服务器的一切，我只需要把代码放上去，然后只管睡大头觉。

   就在这个时候，童剑问我有没有兴趣回去做一个PHP版GAE的产品。本着我不下地狱谁下地狱何况我已经下过地狱的心态，我成为了新浪云的产品经理。

   当时选择App Engine的方向，主要有两个原因：首先，新浪需要有一个规范化的开发平台来大规模提升开发效率，在这个方向上，之前已经有动态应用平台，但粒度不够细，SAE一直被视为新一代的动态应用平台，它将在应用层次上规范和提升开发流程；其次，我们觉得开放平台在中国会崛起，这必然会引来大量的开发者，这些开发者肯定需要这么一个平台。

   从为开发者省钱的角度来讲，SAE做的真的很棒。像微盘这样的云存储项目，在SAE上每天的花销不到八百块钱(一年前的数据)，还包括了存储和带宽成本；微游戏这样的大平台，一天也就花一千多RMB(半年前的数据)。

   但是，要获得这样的能力，你必须遵守SAE的规则。比如，不要写本地目录。这条规则保证了SAE上应用对磁盘的IO性能，却也导致了绝大部分PHP应用需要移植以后才能放到SAE运行。

   这就是PaaS，典型的双刃剑。要想获得极高的性能，就必须严格按照平台规则优化；要想什么都由系统来做，就要符合系统规范。对于新开发的应用来说，这不算大问题，但对于很多运行得很好的已有应用来说，改造成本是一个几乎不可逾越的门槛。 同时对于企业来说，还有一个不得不考虑的点——将来应用如何迁移。

   不过技术上的问题，迟早都能解决，只是时间问题。后来我们做了一个支持本地写的方案，并把它应用到了云商店上，可以保证应用移植成本接近零。

   PaaS更大的问题，还是它面对的市场。虽然后续开放平台在国内野火燎原，微博平台超越人人发展得如日中天，SAE作为微博应用第一大承载平台，PV也一度超过GAE，但在整体收入上连收支平衡都没做到。原因挺搞笑，因为太省钱了。

   独立开发者市场走不通，我们只好转向中小企业。这时候SAE就很难满足需求了。有两个主要问题，一个是迁移成本太高，另一个是根本迁移不了。因为SAE当初是面向Web应用设计的，而很多企业的程序跑在Windows服务器上，还用着SqlServer。

IaaS平台和混合云

   直接售卖虚拟机可以解决几乎一切兼容性问题，于是我们开始做自己的IaaS平台，也就是SWS。

   在IaaS上，新浪起步稍晚，但选了个好策略——全面融入开源。对OpenStack项目的高度参与不但让SWS很快进入可用阶段，更提升了新浪云在国际上的影响力，我个人对SWS项目的未来也比较看好。

   但是目前SWS的规模还比较小，而IaaS其实是个通过规模化降低成本的苦逼生意。没有自己数据中心的SWS以后很难拿到比阿里云更低的成本，即使是做得很不错的Rackspace，利润率也只有7%。

   随着虚拟化技术和开源云方案的成熟，IaaS市场不会再是一个技术导向的市场。对于国内那些除了技术啥都不缺的IDC、电信运营商，他们会很轻易的进入这个市场。

   新浪云必须构筑起一个足够高的产品门槛。于是我们把PaaS和IaaS打通，做出了一个高性价比&高兼容性的混合云方案。

   逻辑梳理起来其实很简单：

   PaaS具有很好的性价比，但不是所有的场合都能用；IaaS有很好的兼容性，但因为采用虚拟机粒度的隔离，成本比较高。

   那么我们将企业的网站、web应用和新编写的程序放到SAE上，将企业原有的软件、做过深度开发和优化的系统放到SWS上，然后通过一个合理的安全策略，允许它们之间互相访问。

   这就是我们的混合云，最近的一个例子里边，采用这个方案后费用降低了60%。混合云方案不但有效的解决了客户的真实需求，也利用上了我们在PaaS上的先发优势，最近在企业客户方面增长很好。

另类SaaS-云商店

   其实我们本来没打算做SaaS，因为我们觉得这个形式对于国内来说，实在太超前了。国内成功的SaaS平台一个没有，先烈倒有一堆，里边好像还有salesforce。

   SaaS要落地，必须要解决好几个问题：

• 第一，企业数据安全问题，如何保证企业的数据不泄露和被盗用。

• 第二，依赖SaaS的业务的可控性问题，当SaaS服务商倒闭了，企业的业务怎么办？

• 第三，SaaS应用匮乏的问题，当应用不够时，平台就无法规模化。

   我一直觉得这些问题挺难解决，尤其是涉及到信任、数据安全的时候，往往需要时间来改变，而我们并没有那么多的时间去等待。

   话说SAE上有个功能特别受欢迎，叫做应用仓库。它本来是为了方便开发者，让他们可以通过一次点击，就瞬间安装好一个应用。

   但后来我们发现有非常大量的非技术用户使用这个功能，而他们往往对应用控制面板里边的各种技术化的菜单感到无力。

   最终我们决定把这部分功能抽离出来，做成完全面对非技术用户的产品——云商店。

   正是在设计云商店的时候，我们意识到，它的模式，恰好解决了传统SaaS的几大问题。

   严格的说，云商店本身只是一个帮助Web应用SaaS化的工具平台。我们帮开发者把他们的标准PHP应用和一个基于PaaS技术隔离的云空间打包在一起，进行一键安装，同时帮他们向客户收取代码授权费用。

   它采用了三方模式：

• 软件供货商只上架应用代码；

• 云商店只提供运行环境；

• 客户在云商店上使用软件，按月付费并可以通过FTP随时备份或删除自己的数据。

   这种类似三权分立的方式，有效的保证了数据的安全：理解数据格式的供货商接触不到数据；存储数据的云平台不理解数据的结构；客户则对数据拥有完全的控制权，可以随时删除数据。

   和之前的SAE环境不同，云商店采用了几乎完全兼容标准的PHP的环境，这有效地解决了第二和第三个问题：

• 当客户不想再用云商店的时候，只需要在自己的服务器上配置好标准PHP环境，将供货商提供的代码放过去，导入数据，就可以继续使用。

• 而正因为云商店兼容标准PHP，所以成千上万的开源应用都可以直接在云商店安装。

   解决了这些核心问题，云商店就能开始前进了。

   云商店才进入公众Beta版不久，从我们目前的数据来看，它显然走在了正确的道路上。在微盘点击云商店广告的人里边，有4~5%都购买了我们的云应用；而这些人里边，有15%以上的客户进行了第二次购买(不包含续费和升级)。

   当我们在推WordPress的时候，还有很多用户疑惑，有了新浪博客、WordPress.com，为什么我要买你的WordPress；而当我们上架易客CRM、微普订餐系统和D1客服Tickect系统后，用户终于开始发现云商店特有的价值——它真的让你的生活更简单：那些原本技术化的东西，变得立等可取，变得触手可及 。其实这只是开始。

三年

   回首这三年，我们一路走来，做了很多不错的东西，新浪云也成为了国内为数不多的能覆盖云计算三大层次的云平台。

   我们随着成长不可避免的被改变，好在我可以欣慰的说，我们还是一个有梦想的团队。

   当我在微博上看到一个个Hackthon的Demo放在Sinaapp上，当我看到大学的老师让同学通过SAE交作业，甚至五阿哥通过微盘下钙片的时候，我都深信我们还是改变了世界的，也许就那么一点点，但没有我们会不一样。

建议继续学习：

1. 马化腾李彦宏马云首次对话：一小时掌声不断    (阅读：4396)
2. 云计算的技术架构与实现分析    (阅读：3204)
3. 整合搜索，阿拉丁，云计算，以及框计算    (阅读：3062)
4. 云计算时代：运维人员会踩到哪些坑？    (阅读：2950)
5. Amazon AWS云计算服务简介    (阅读：2802)
6. 云计算中的结构化数据：Google GAE Datastore    (阅读：2469)
7. 理解云计算    (阅读：2415)
8. 云计算概览    (阅读：2285)
9. 云计算时代的工作方式探讨    (阅读：2229)
10. 客户端应该去计算什么？    (阅读：2068)