本文來自 方糖氣球，作者 Easy 現(xiàn)任新浪云計算產品經理。

從09年回到新浪負責云計算的產品，轉眼3年了；新浪云也已經從一個幾個人的團隊，成長為快50人的部門了。09年的時候，我們還不知道什么叫云計算，現(xiàn)在連專家都能數(shù)出來云計算的層次了：PaaS、IaaS和SaaS。

PAAS時期

08年的時候，我創(chuàng)過一次業(yè)，主要在校內開放平臺（就是現(xiàn)在的人人了）上做社交應用，但我都不好意思和別人講我是做應用的，因為我一大半的時間都是在弄服務器。

我本來是個PHP程序員，哪兒想過要自己買服務器、自己找IDC托管、自己抱著一臺1U的Dell去機房配置網卡地址…… 但只要你想創(chuàng)業(yè)，這些都是不可避免的。那時候的我痛恨各種命令行，只會配置GUI界面的軟件，前段時間我打開那臺服務器倒數(shù)據(jù)，發(fā)現(xiàn)我安裝的居然是桌面版的Ubuntu。

一年下來，我發(fā)現(xiàn)自己的業(yè)務沒什么長進，對Linux倒進步神速。雖然每一個PHP程序員上輩子都是折翼的前端、美工和系統(tǒng)管理員，但我依然夢想著有一天，有一個團隊能幫我搞定服務器的一切，我只需要把代碼放上去，然后只管睡大頭覺。

就在這個時候，童劍問我有沒有興趣回去做一個PHP版GAE的產品。本著我不下地獄誰下地獄何況我已經下過地獄的心態(tài)，我成為了新浪云的產品經理。

當時選擇App Engine的方向，主要有兩個原因：首先，新浪需要有一個規(guī)范化的開發(fā)平臺來大規(guī)模提升開發(fā)效率，在這個方向上，之前已經有動態(tài)應用平臺，但粒度不夠細，SAE一直被視為新一代的動態(tài)應用平臺，它將在應用層次上規(guī)范和提升開發(fā)流程；其次，我們覺得開放平臺在中國會崛起，這必然會引來大量的開發(fā)者，這些開發(fā)者肯定需要這么一個平臺。

從為開發(fā)者省錢的角度來講，SAE做的真的很棒。像微盤這樣的云存儲項目，在SAE上每天的花銷不到八百塊錢（一年前的數(shù)據(jù)），還包括了存儲和帶寬成本；微游戲這樣的大平臺，一天也就花一千多RMB（半年前的數(shù)據(jù)）。

但是，要獲得這樣的能力，你必須遵守SAE的規(guī)則。比如，不要寫本地目錄。這條規(guī)則保證了SAE上應用對磁盤的IO性能，卻也導致了絕大部分PHP應用需要移植以后才能放到SAE運行。

這就是PaaS，典型的雙刃劍。要想獲得極高的性能，就必須嚴格按照平臺規(guī)則優(yōu)化；要想什么都由系統(tǒng)來做，就要符合系統(tǒng)規(guī)范。對于新開發(fā)的應用來說，這不算大問題，但對于很多運行得很好的已有應用來說，改造成本是一個幾乎不可逾越的門檻。 同時對于企業(yè)來說，還有一個不得不考慮的點——將來應用如何遷移。

不過技術上的問題，遲早都能解決，只是時間問題。后來我們做了一個支持本地寫的方案，并把它應用到了云商店上，可以保證應用移植成本接近零。

PaaS更大的問題，還是它面對的市場。雖然后續(xù)開放平臺在國內野火燎原，微博平臺超越人人發(fā)展得如日中天，SAE作為微博應用第一大承載平臺，PV也一度超過GAE，但在整體收入上連收支平衡都沒做到。原因挺搞笑，因為太省錢了。

獨立開發(fā)者市場走不通，我們只好轉向中小企業(yè)。這時候SAE就很難滿足需求了。有兩個主要問題，一個是遷移成本太高，另一個是根本遷移不了。因為SAE當初是面向Web應用設計的，而很多企業(yè)的程序跑在Windows服務器上，還用著SqlServer。

IAAS平臺和混合云

直接售賣虛擬機可以解決幾乎一切兼容性問題，于是我們開始做自己的IaaS平臺，也就是SWS。

在IaaS上，新浪起步稍晚，但選了個好策略——全面融入開源。對OpenStack項目的高度參與不但讓SWS很快進入可用階段，更提升了新浪云在國際上的影響力，我個人對SWS項目的未來也比較看好。

但是目前SWS的規(guī)模還比較小，而IaaS其實是個通過規(guī)?；档统杀镜目啾粕?。沒有自己數(shù)據(jù)中心的SWS以后很難拿到比阿里云更低的成本，即使是做得很不錯的Rackspace，利潤率也只有7%。

隨著虛擬化技術和開源云方案的成熟，IaaS市場不會再是一個技術導向的市場。對于國內那些除了技術啥都不缺的IDC、電信運營商，他們會很輕易的進入這個市場。

新浪云必須構筑起一個足夠高的產品門檻。于是我們把PaaS和IaaS打通，做出了一個高性價比&高兼容性的混合云方案。

邏輯梳理起來其實很簡單：

PaaS具有很好的性價比，但不是所有的場合都能用；IaaS有很好的兼容性，但因為采用虛擬機粒度的隔離，成本比較高。

那么我們將企業(yè)的網站、web應用和新編寫的程序放到SAE上，將企業(yè)原有的軟件、做過深度開發(fā)和優(yōu)化的系統(tǒng)放到SWS上，然后通過一個合理的安全策略，允許它們之間互相訪問。

這就是我們的混合云，最近的一個例子里邊，采用這個方案后費用降低了60%?；旌显品桨覆坏行У慕鉀Q了客戶的真實需求，也利用上了我們在PaaS上的先發(fā)優(yōu)勢，最近在企業(yè)客戶方面增長很好。

另類SAAS-云商店

其實我們本來沒打算做SaaS，因為我們覺得這個形式對于國內來說，實在太超前了。國內成功的SaaS平臺一個沒有，先烈倒有一堆，里邊好像還有salesforce。

SaaS要落地，必須要解決好幾個問題：

• 第一，企業(yè)數(shù)據(jù)安全問題，如何保證企業(yè)的數(shù)據(jù)不泄露和被盜用。
• 第二，依賴SaaS的業(yè)務的可控性問題，當SaaS服務商倒閉了，企業(yè)的業(yè)務怎么辦？
• 第三，SaaS應用匱乏的問題，當應用不夠時，平臺就無法規(guī)?；?。

我一直覺得這些問題挺難解決，尤其是涉及到信任、數(shù)據(jù)安全的時候，往往需要時間來改變，而我們并沒有那么多的時間去等待。

話說SAE上有個功能特別受歡迎，叫做應用倉庫。它本來是為了方便開發(fā)者，讓他們可以通過一次點擊，就瞬間安裝好一個應用。

但后來我們發(fā)現(xiàn)有非常大量的非技術用戶使用這個功能，而他們往往對應用控制面板里邊的各種技術化的菜單感到無力。

最終我們決定把這部分功能抽離出來，做成完全面對非技術用戶的產品——云商店。

正是在設計云商店的時候，我們意識到，它的模式，恰好解決了傳統(tǒng)SaaS的幾大問題。

嚴格的說，云商店本身只是一個幫助Web應用SaaS化的工具平臺。我們幫開發(fā)者把他們的標準PHP應用和一個基于PaaS技術隔離的云空間打包在一起，進行一鍵安裝，同時幫他們向客戶收取代碼授權費用。

它采用了三方模式：

• 軟件供貨商只上架應用代碼；
• 云商店只提供運行環(huán)境；
• 客戶在云商店上使用軟件，按月付費并可以通過FTP隨時備份或刪除自己的數(shù)據(jù)。

這種類似三權分立的方式，有效的保證了數(shù)據(jù)的安全：理解數(shù)據(jù)格式的供貨商接觸不到數(shù)據(jù)；存儲數(shù)據(jù)的云平臺不理解數(shù)據(jù)的結構；客戶則對數(shù)據(jù)擁有完全的控制權，可以隨時刪除數(shù)據(jù)。

和之前的SAE環(huán)境不同，云商店采用了幾乎完全兼容標準的PHP的環(huán)境，這有效地解決了第二和第三個問題：

• 當客戶不想再用云商店的時候，只需要在自己的服務器上配置好標準PHP環(huán)境，將供貨商提供的代碼放過去，導入數(shù)據(jù)，就可以繼續(xù)使用。
• 而正因為云商店兼容標準PHP，所以成千上萬的開源應用都可以直接在云商店安裝。

解決了這些核心問題，云商店就能開始前進了。

云商店才進入公眾Beta版不久，從我們目前的數(shù)據(jù)來看，它顯然走在了正確的道路上。在微盤點擊云商店廣告的人里邊，有4~5%都購買了我們的云應用；而這些人里邊，有15%以上的客戶進行了第二次購買（不包含續(xù)費和升級）。

當我們在推WordPress的時候，還有很多用戶疑惑，有了新浪博客、WordPress.com，為什么我要買你的WordPress；而當我們上架易客CRM、微普訂餐系統(tǒng)和D1客服Tickect系統(tǒng)后，用戶終于開始發(fā)現(xiàn)云商店特有的價值——它真的讓你的生活更簡單：那些原本技術化的東西，變得立等可取，變得觸手可及 。其實這只是開始。

三年

回首這三年，我們一路走來，做了很多不錯的東西，新浪云也成為了國內為數(shù)不多的能覆蓋云計算三大層次的云平臺。

我們隨著成長不可避免的被改變，好在我可以欣慰的說，我們還是一個有夢想的團隊。

當我在微博上看到一個個Hackthon的Demo放在Sinaapp上，當我看到大學的老師讓同學通過SAE交作業(yè)，甚至五阿哥通過微盤下鈣片的時候，我都深信我們還是改變了世界的，也許就那么一點點，但沒有我們會不一樣。