做云这三年
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应用匮乏的问题,当应用不够时,平台就无法规模化。
软件供货商只上架应用代码;
云商店只提供运行环境;
客户在云商店上使用软件,按月付费并可以通过FTP随时备份或删除自己的数据。
当客户不想再用云商店的时候,只需要在自己的服务器上配置好标准PHP环境,将供货商提供的代码放过去,导入数据,就可以继续使用。
而正因为云商店兼容标准PHP,所以成千上万的开源应用都可以直接在云商店安装。
我一直觉得这些问题挺难解决,尤其是涉及到信任、数据安全的时候,往往需要时间来改变,而我们并没有那么多的时间去等待。
话说SAE上有个功能特别受欢迎,叫做应用仓库。它本来是为了方便开发者,让他们可以通过一次点击,就瞬间安装好一个应用。
但后来我们发现有非常大量的非技术用户使用这个功能,而他们往往对应用控制面板里边的各种技术化的菜单感到无力。
最终我们决定把这部分功能抽离出来,做成完全面对非技术用户的产品——云商店。
正是在设计云商店的时候,我们意识到,它的模式,恰好解决了传统SaaS的几大问题。
严格的说,云商店本身只是一个帮助Web应用SaaS化的工具平台。我们帮开发者把他们的标准PHP应用和一个基于PaaS技术隔离的云空间打包在一起,进行一键安装,同时帮他们向客户收取代码授权费用。
它采用了三方模式:
这种类似三权分立的方式,有效的保证了数据的安全:理解数据格式的供货商接触不到数据;存储数据的云平台不理解数据的结构;客户则对数据拥有完全的控制权,可以随时删除数据。
和之前的SAE环境不同,云商店采用了几乎完全兼容标准的PHP的环境,这有效地解决了第二和第三个问题:
解决了这些核心问题,云商店就能开始前进了。
云商店才进入公众Beta版不久,从我们目前的数据来看,它显然走在了正确的道路上。在微盘点击云商店广告的人里边,有4~5%都购买了我们的云应用;而这些人里边,有15%以上的客户进行了第二次购买(不包含续费和升级)。
当我们在推WordPress的时候,还有很多用户疑惑,有了新浪博客、WordPress.com,为什么我要买你的WordPress;而当我们上架易客CRM、微普订餐系统和D1客服Tickect系统后,用户终于开始发现云商店特有的价值——它真的让你的生活更简单:那些原本技术化的东西,变得立等可取,变得触手可及 。其实这只是开始。
三年
回首这三年,我们一路走来,做了很多不错的东西,新浪云也成为了国内为数不多的能覆盖云计算三大层次的云平台。
我们随着成长不可避免的被改变,好在我可以欣慰的说,我们还是一个有梦想的团队。
当我在微博上看到一个个Hackthon的Demo放在Sinaapp上,当我看到大学的老师让同学通过SAE交作业,甚至五阿哥通过微盘下钙片的时候,我都深信我们还是改变了世界的,也许就那么一点点,但没有我们会不一样。
建议继续学习:
- 马化腾李彦宏马云首次对话:一小时掌声不断 (阅读:4440)
- 云计算的技术架构与实现分析 (阅读:3261)
- 整合搜索,阿拉丁,云计算,以及框计算 (阅读:3306)
- 云计算时代:运维人员会踩到哪些坑? (阅读:3047)
- Amazon AWS云计算服务简介 (阅读:2853)
- 云计算中的结构化数据:Google GAE Datastore (阅读:2576)
- 理解云计算 (阅读:2454)
- 云计算概览 (阅读:2326)
- 云计算时代的工作方式探讨 (阅读:2281)
- 客户端应该去计算什么? (阅读:2111)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:easy 来源: 方糖气球
- 标签: IaaS PaaS SaaS 云计算
- 发布时间:2012-12-05 13:32:13
- [66] Go Reflect 性能
- [65] Oracle MTS模式下 进程地址与会话信
- [64] 如何拿下简短的域名
- [59] android 开发入门
- [59] IOS安全–浅谈关于IOS加固的几种方法
- [58] 图书馆的世界纪录
- [58] 【社会化设计】自我(self)部分――欢迎区
- [53] 视觉调整-设计师 vs. 逻辑
- [47] 界面设计速成
- [46] 读书笔记-壹百度:百度十年千倍的29条法则