本文来自 方糖气球，作者 Easy 现任新浪云计算产品经理。
从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交作业，甚至五阿哥通过微盘下钙片的时候，我都深信我们还是改变了世界的，也许就那么一点点，但没有我们会不一样。
