編者按：IaaS(Infrastructure as a Service)，即“基礎設施即服務”已經成為一個令人矚目的方向，甚至出現了云計算就是“互聯網稅”這樣的說法。無論是國內還是國外，這似乎都是一個大佬之間火拼的戰場。誰將贏得未來?作為用戶，我們是該選擇“單點”還是“套餐”?

每個人都知道 IBM 把大好河山讓給微軟(和英特爾)的故事：那時，低耗電個人電腦的消費者需求已經把 IBM 圍得水泄不通，為了對這些沒什么賺頭的需求有所響應，這家垂直聚焦于大型主機領域的公司在佛羅里達州 Boca Raton 市設立了一個研發隊伍，離他們在紐約 Armonk 的總部所在地很遠。由于把著重點放在速度與成本上，這支隊伍決定基本上把所有東西都外包出去，包括操作系統和處理器。對于 IBM 的目標，這個方法是行之有效的：當大型主機通常需要十年來研究并發布時，Boca Raton 團隊在12個月之內就完成了從概念到發貨的流程。但是著重于外包標準件的做法則意味著個人電腦領域最肥的肉(比大型主機生意賺錢多了)落入了兩個獨家供應商手中：微軟和英特爾。

很少有人知道，個人電腦不只是 IBM 的“內部政策驅動”之下放走的唯一一塊肥肉。大型主機上最重要的軟件應用曾經是 IBM 的信息管理系統(Information Management System，IMS)，一個層次型數據庫。讓我在這里暫停一下：對于不懂數據庫的讀者，我會試著盡量將接下來的闡述簡化。對于那些懂的人，很抱歉讓這篇文章變得有點淺。

數據庫的類型

一個層次型數據庫，好吧，就是一層層的數據：

譯者注：圖中三層，自上而下分別是根數據項、父數據項和子數據項。

在層次型數據庫中，任何一項數據都可以通過兩種方式被找到：要么已知父數據項去找子數據項，要么已知子數據項去找父數據項。這是理解起來最容易的一種數據庫，而且至少對于早期的計算機來說，實現起來最簡單的：定義結構，錄入數據，然后通過遍歷層級來搜索子數據項或者父數據項來達到搜索數據的目的。或者，更實際地來說，運用你對層級的了解，直接去到某個特定的點。

但是，層級型數據庫有兩個重大的限制：首先，這里面的數據關系是被事先定義的，哪些是父項、哪些是子項是在任何數據被實際輸入前就決定好了的。這使得數據庫一旦被使用了，再要做改動就非常困難。第二，要做不同父項的子項查詢是不切實際的：在忽視數據庫的大部分，取得你想要分析的數據組之前，你需要遍歷層級來獲取所有潛在的項的相關信息。

在1969年，一位名為 Edgar F. Codd的 IBM 計算機科學家寫了一篇名為《大型共享數據庫的關系數據模型(A Relational Model of Data for Large Shared Data Banks)》的論文，提出了一種新方法。哪怕外行人來讀，這篇論文的引言也非常淺顯易懂：

未來，大型數據庫的用戶必然不用再為研究數據在計算機內部是如何被組織的(即“內部表象”)而煩惱。但及時供應這等信息的服務并非是一個令人滿意的解決方案。當數據的內部表象甚至外部表象的某些方面發生變化時，終端用戶的活動以及大多數的應用程序應該要都不受影響。計算機存儲的各種類型數據在查詢、更新、報告流量和自然增長上的變化都會導致數據表象的變化。

這篇論文是后來為人所知的“關系數據庫”的基石：與其以層級方式(即前文所述由數據定義自身在數據庫中的位置)儲存數據，關系數據庫使用表格來做這件事。每項數據是由它的表名、列名和鍵值來定義的，而不是由數據自身(數據被存儲在別處)。這意味著你可以通過一項數據與其他所有數據庫中數據的聯系來理解它。表名也可以作列名，就像鍵值也可以作表名。

這個方法有幾個巨大的好處：第一，你可以新增數據庫里的數據種類而不會影響到之前錄入的數據，也不用重新把層級都寫一遍，只要加新的表就行。第二，數據庫可以為任意數量和類型的數據進行擴容，因為數據并沒有真的在數據庫里——為了支持整數和文本字符串，你看到的是數據的邏輯抽象。第三，使用“結構化查詢語言(SQL)”，你可以輕松地調出數據關系之間的報告(比如“40歲以上的消費者買的最多的10本書”)，而且由于查詢只是在檢測整數和字符串直接的關系，你幾乎可以無所不問。畢竟現在只要搞清楚數據庫里兩個數據位置之間的數學關系而不用掃描整個樹狀結構了——要是你不知道你要找什么，原來的辦法天生就慢，而且大多數情況下比較盲目。

長出一口氣……上面這幾段話你們讀起來應該跟我寫起來一樣痛苦。但我們還是有收獲的，總結一下：由于受到預先定義的拘束，層級型數據庫在性能和容量上都受限。而通過抽象數據產生計算機可以很容易處理的鍵值的關系數據庫要有用得多，并且擴容空間大得多。

甲骨文的崛起

Codd 博士石破天驚的想法幾乎被 IBM 完全忽視了好幾年，一部分是由于之前提到的 IMS。Codd 基本上就是在說，對于很多潛在的數據庫應用程序而言，IBM 最大的賺錢機器已經過時了——這是一條 IBM 管理層不太愿意聽到的消息。事實上，哪怕在1977年 IBM 最終打造出世界上第一個關系數據庫(那時候它被叫做 System R，包括一種叫做 SQL 的新查詢語言)，他們并沒有做商業發行。要到1982年，IBM 的第一個關系數據庫軟件 SQL/DS 才上市。自然，它只在 IBM 的主機上運行——IMS 是大家伙的專屬。

與此同時，一位叫拉里·艾利森的年輕程序員組建了一家名為“軟件開發實驗室(Software Development Laboratories)”的公司，起初做些外包的活兒，但是后來迅速發現賣通用軟件要賺錢得多：寫一次程序，然后賣它個很多次，是個發財致富的絕佳路子。他們只需要一個產品，而 IBM 基本上就是白送了他們一個。由于 System R 團隊被當作一個研究項目而非商業計劃對待，團隊很開心地寫了不少論文來解釋 System R 的工作原理，也公開了 SQL 的技術參數。軟件開發實驗室實現了這個軟件，管它叫“甲骨文”，在1979年把它賣給了 CIA(對方的條件是軟件要能在 IBM 主機上運行)。

換句話說，IBM 不但為通用軟件界有史以來最大的公司(微軟)的萌發創造了條件，還白白把致富說明書送給了第二大公司(甲骨文)。

通用軟件的生意

通用軟件產業是一個介于過去的傳統行業與互聯網時代純數字行業的混合體(畢竟那會兒還沒有互聯網)。一方面，艾利森很快意識到，軟件的邊際成本為零：只要你寫了一個特定的程序，就可以制作出無數的副本;另一方面，渠道分發成了最大的挑戰。在甲骨文的關系數據庫這個例子里，Relational Software Inc.(就是之前的Software Development Laboratories，這家公司在1982年改名為甲骨文系統公司，1995年才改為今日的甲骨文集團)不得不建立起一支銷售隊伍去賣產品，然后再用磁帶把軟件寄出去。

最經濟實惠的做法，是做一個大多數客戶都想要的產品的半成品，然后和不同的客戶一起把產品最終完善起來。這里面一部分的工作在前端——甲骨文可以快速用C語言重寫新程序，而C語言在大部分平臺都有編譯器，支持甲骨文移植代碼——但更多的工作是在售后：客戶需要安裝甲骨文，讓它工作起來，錄入他們的數據，只有這樣，在原始協議的幾個月甚至幾年以后，他們才開始看到回報。

最終這成了甲骨文的商業模式：甲骨文的客戶不僅僅是購買軟件，他們和公司綁定了多年期的完整服務，包括軟件許可，售后支持，以及審核計劃，來確保甲骨文履行了他們的義務。而且哪怕有些怨言，客戶也不太會去另找別家：那些關系數據庫和存放在上面的數據都是公司的重要資產，他們早已把這些數據投入使用并開始構建和運行，誰還愿意把那套流程跟其他公司重來一遍?的確，當已經運行了甲骨文的數據并有了這層關系后，向甲骨文購買在那些數據庫上運行的應用程序會是更方便的選擇。因此，接下來超過三十年間，客戶 IT 開銷不斷增長，而甲骨文把這個先發優勢利用到了極致。這也算“肥水不流外人田”吧!

亞馬遜帶來的選擇

亞馬遜網絡服務系統(以下簡稱 AWS)背后的主張卻不盡相同。公司不需要預付款，也不需要綁定多年的整合項目服務，而是登錄帳號，使用完畢退出即可。公平地講，對于亞馬遜的那些有議價能力、簽訂長期合同的大客戶來說，這顯得過于簡單化了。但這只是最近發生的事。AWS 的核心用戶從開始一直都是初創企業。他們利用這些耗費幾百萬美金的服務器基礎設施來建立最小可行性產品。而且 AWS 的花費是可變的：你用 AWS 越多(因為你的用戶數在增加)，費用越高;要是幾乎不怎么用(因為你還沒有找到合適的市場)，你就只需要花費比什么都不做多一點的機會成本。

可選的價值觀使得 AWS 如此有價值：想要更大容量嗎?只需一鍵。需要一個新功能?AWS 包含有一套預構建服務供你整合進產品。是的，它可能很貴——一個普遍的說法是 AWS 贏在了價格上，而實際上 AWS 卻是眾多昂貴選擇之一——但是，在你最需要的時候能提供你最需要的產品，這樣的服務到底值多少錢呢?

與此同時，艾利森在本周的“開放的世界”大會上登臺演講，宣布在 IaaS 領域“亞馬遜的領先地位將會被終結”，只因為甲骨文最高端的服務器比亞馬遜更快更便宜。雖然如此，但是，層次數據庫也比關系鏈數據庫更快;速度不代表一切，價格也不。可選擇性和可擴展性一直都很重要，在這方面，甲骨文的基礎服務遠遠不如亞馬遜有競爭力。

當你關注一下云服務領域的關鍵數據，資本性支出，你甚至會發現艾利森的表述更加荒謬。在過去的12個月里，甲骨文的資本性支出全部加起來是10.4億;亞馬遜在上個季度花費了33.6億，過去12個月是109億。

IaaS 并非接單定制的服務;事實是，那些基礎設施以及所有構建在基礎設施之上的附加服務早已讓 AWS 變得十分誘人。甲骨文不僅沒有追趕上，甚至還被落得很遠。

聚焦 SaaS

在他的主題演講中，艾利森反駁了甲骨文的云服務基礎設施的花費是不必要的這種觀點，事實上，他指出，公司花了十年時間將它最具價值的應用移到云端。確實，公司上個季度花費了總收入的17%用于研發，艾利森吹噓甲骨文現在已經擁有30多個 SaaS 應用，而且這個數字很重要：

甲骨文的戰略是什么?我們認為客戶想要什么?我們在 SaaS 領域該做什么?其實這是同一件事：如果我們能找出客戶想要的并交付出去，那客戶就會使用并購買我們的產品。我們認為他們需要的是完成并整合在一起的產品，并非一次性產品。客戶并不想從50個不同的供應商那里整合50個不同的產品。那太困難了。不僅困難，還存在相關的安全風險、勞動力成本和可靠性問題等等。所以我們最大的焦點不是賣出去1個、2個、3個、4個應用，而是為 ERP，為人力資本管理，為客戶關系管理(有時也叫用戶體驗，簡稱 CX)交付完整的軟件套裝。這是我們對 SaaS 的策略：完整的整合套件。

艾利森爭論的問題在部署型軟件方面是正確的;我曾在2015年就這個動態寫了一篇關于微軟的文章。想像一下云計算時代之前公司里的首席信息官(CIO)：

因為各種原因她不得不購買微軟的各種解決方案(像 Exchange)。因此，為了支持 Exchange 的服務，CIO 還需要購買 Windows Server(微軟的一款服務器系統)，Windows Server 又包括了活動目錄(Active Directory)，于是還需要身份認證服務。但是，現在 CIO 已經有了一部分微軟的解決方案，她會更傾向于購買其他微軟的服務，不論是關系型數據庫管理系統(SQL Server)、客戶關系管理系統(Dynamics CRM)還是門戶網站和企業內網(SharePoint)等。確實，微軟的產品可能不總是最好的，但 CIO 都要考慮到現實情況：后續維護和服務費是一個巨大的隱憂，而且較少的供應商往往能帶來更多好處。事實上，微軟近15年來的壯大可以追溯到巴爾莫聰明地利用新產品、新定價和許可協議，迫使用戶購買更多的公司產品。

如上文所提到的，這和甲骨文的策略如出一轍。然而，企業的 IT 決策也在發生著重大的變化：首先，在不需要巨大的前期投資后，轉向另一家供應商的風險變得低多了，尤其是當只有團隊或部門層級試用過相關產品的時候。其次，沒有了持續的客服和后續的維護成本，也就減少了和供應商關于可變成本的爭論。當然，艾利森警告的——將50個不同的供應商合并在一起使用的潛在麻煩——也許會出現，但這也同時意味著軟件的實際質量和用戶體驗在購買決策中扮演著更主要的角色，且團隊決策這一點使之變得更為重要，因為服務的購買者就是實際使用者。

過渡階段的甲骨文

簡而言之，艾利森在兜售的新甲骨文看起來跟舊甲骨文很像：一大堆的產品，大部分客戶想要什么幾乎就做什么，至少理論上是這樣，但是既沒有 AWS 的靈活性和可擴展性，以及聚焦和承諾用戶體驗的專用 SaaS 服務。在數據庫方面，像一個層次數據庫，甲骨文都是根據顧客的要求提前定制開發的，不需要任何靈活性。與此同時，AWS和專門的 SaaS 服務提供商都是關系數據庫，為企業提供可選擇性和可擴展的服務，幫助企業在必要的時候搭建適合自己業務的服務;當然，現在可能還看不到效果，但長期來看這樣的趨勢再明顯不過了。

值得注意的是，大部分這些分析主要都是針對首次搭建 IT 系統的新公司;甲骨文依然牢牢鎖定著它的現有客戶，包括世界上絕大多數的大公司和政府。從這點來看，它基本上把本地業務復制到云端(甚至直接移到它的自有云硬件上)的總戰略是合理的。這也同樣是微軟寄予厚望的混合策略。給那些和他們一樣老派的客戶一些減少資本性支出方面的好處(增加他們的資本回報率)并且希望為自己爭取時間，好適應這個用戶被真正重視的新世界——聚焦且靈活的云服務是服務用戶的最佳方式。