68大熱的與前途未卜甲骨文

1、大熱的與前途未卜的甲骨文ONES Piece 2016-10-25 行業(yè)云計算似乎是一個大佬之間火拼的戰(zhàn)場。誰將贏得未來？作為用戶，我們是該選擇“單點”還是“套餐”？編者按：（Infrastructure as a Service），即“基礎設施即服務”已經成為一個令人矚目的方向，甚至出現(xiàn)了云計算就是“互聯(lián)網稅”這樣的說法。無論是國內還是國外，這似乎都是一個大佬之間火拼的戰(zhàn)場。誰將贏得未來？作為用戶，我們是該選擇“單點”還是“套餐”？每個人都知道 IBM 把大好河山讓給微軟（和英特爾）的故事：那時，低耗電個人電腦的消費者需求已經把 IBM 圍得水泄不通，為了對這些沒什么賺頭的需求有所響應，這家

2、垂直聚焦于大型主機領域的公司在佛羅里達州 Boca Raton 市設立了一個研發(fā)隊伍，離他們在紐約 Armonk 的總部所在地很遠。由于把著重點放在速度與成本上，這支隊伍決定基本上把所有東西都外包出去，包括操作系統(tǒng)和處理器。對于 IBM 的目標，這個方法是行之有效的：當大型主機通常需要十年來研究并發(fā)布時，Boca Raton 團隊在 12之內就完成了從概念到發(fā)貨的流程。但是著重于外包標準件的做法則意味著個人電腦領域最肥的肉（比大型主機生意賺錢多了）落入了兩個獨家供應商手中：微軟和英特爾。很少有人知道，個人電腦不只是 IBM 的“內部政策驅動”之下放走的唯一一塊肥肉。大型主機上最重要的軟件應用曾

3、經是 IBM 的信息管理系統(tǒng)（Information Management System，IMS），一個層次型數據庫。讓我在這里暫停一下：對于不懂數據庫的讀者，我會試著盡量將接下來的闡述簡化。對于那些懂的人，很抱歉讓這篇文章變得有點淺。數據庫的類型一個層次型數據庫，好吧，就是一層層的數據：譯者注：圖中三層，自上而下分別是根數據項、父數據項和子數據項。在層次型數據庫中，任何一項數據都可以通過兩種方式被找到：要么已知父數據項去找子數據項，要么已知子數據項去找父數據項。這是理解起來最容易的一種數據庫，而且至少對于早期的計算機來說，實現(xiàn)起來最簡單的：定義結構，錄入數據，然后通過遍歷層級來搜索子數據項或

4、者父數據項來達到搜索數據的目的?；蛘?，更實際地來說，運用你對層級的了解，直接去到某個特定的點。但是，層級型數據庫有兩個的限制：首先，這里面的數據關系是被事先定義的，哪些是父項、哪些是子項是在任何數據被實際輸入前就決定好了的。這使得數據庫一旦被使用了，再要做改動就非常。第二，要做不同父項的子項是不切實際的：在忽視數據庫的大部分，取得你想要分析的數據組之前，你需要遍歷層級來獲取所有潛在的項的相關信息。在 1969 年，一位名為 Edgar F. Codd 的 IBM 計算機科學家寫了一篇名為大型共享數據庫的關系數據模型（A Relational Mof Data for Large Shared

5、DataBanks）的淺顯易懂：，提出了一種新方法。哪怕外行人來讀，這篇的引言也非常未來，大型數據庫的用戶必然不用再為研究數據在計算機內部是如何被組織的（即“內部表象”）而煩惱。但及時供應這等信息的服務并非是一個令人滿意的解決方案。當數據的內部表象甚至外部表象的某些方面發(fā)生變化時，終端用戶的活動以及大多數的應用程序應該要都不受影響。計算機的各種類型數據在、更告流量和自然增長上的變化都會導致數據表象的變化。這篇是后來為人所知的“關系數據庫”的基石：與其以層級方式（即前文所述由數據定義自身在數據庫中的位置）儲存數據，關系數據庫使用表格來做這件事。每項數據是由它的表名、列名和鍵值來定義的，而不是由數

6、據自身（數據被在別處）。這意味著你可以通過一項數據與其他所有數據庫中數據的來理解它。表名也可以作列名，就像鍵值也可以作表名。這個方法有幾個巨大的好處：第一，你可以新增數據庫里的數據種類而影響到之前錄入的數據，也不用重新把層級都寫一遍，只要加新的表就行。第二，數據庫可以為任意數量和類型的數據進行擴容，因為數據并沒有真的在數據庫里為了支持整數和文本字符串，你看到的是數據的邏輯抽象。第三，使用“結構化語言（SQL）”，你可以輕松地調出數據關系之間的報告（比如“40 歲以上的消費者買的最多的 10 本書”），而且由于只是在檢測整數和字符串直接的關系，你幾乎可以無所。畢竟現(xiàn)在只要搞清楚數據庫里兩個數據位

7、置之間的數學關系而不用掃描整個樹狀結構了要是你不知道你要找什么，原來的辦法天生就慢，而且大多數情況下比較盲目。長出一口氣上面這幾段話讀起來應該跟我寫起來一樣痛苦。但我們還是有收獲的，總結一下：由于受到預先定義的拘束，層級型數據庫在性能和容量上都受限。而通過抽象數據產生計算機可以很容易處理的鍵值的關系數據庫要有用得多，并且擴容空間大得多。甲骨文的崛起Codd 博士石破天驚的想法幾乎被 IBM 完全忽視了好幾年，一部分是由于之前提到的 IMS。Codd 基本上就是在說，對于很多潛在的數據庫應用程序而言，IBM 最大的賺錢已經過時了這是一條 IBM 管理層不太愿意聽到的消息。事實上，哪怕在 1977

8、 年 IBM 最終打造出世界上第一個關系數據庫（那時候它被叫做System R，包括一種叫做 SQL 的新語言），他們并沒有做商業(yè)。要到1982 年，IBM 的第一個關系數據庫軟件 SQL/DS 才上市。自然，它只在 IBM 的主機上運行IMS 是大家伙的專屬。與此同時，一位叫拉里·艾利森的年輕程序員組建了一家名為“軟件開發(fā)（Software Development Laboratories）”的公司，起初做些外包的活兒，但是后來迅速發(fā)現(xiàn)賣通用軟件要賺錢得多：寫一次程序，然后賣它個很多次，是個發(fā)財致富的絕佳路子。他們只需要一個，而 IBM 基本上就是白送了他們一個。由于System

9、R 團隊被當作一個研究項目而非商業(yè)計劃對待，團隊很開心地寫了不少論文來解釋 System R 的工作原理，也公開了 SQL 的技術參數。軟件開發(fā)實現(xiàn)了這個軟件，管它叫“甲骨文”，在 1979 年把它賣給了 CIA（對方的條件是軟件要能在 IBM 主機上運行）。換句話說，IBM 不但為通用軟件界有史以來最大的公司（微軟）的萌發(fā)創(chuàng)造了條件，還白白把致富說明書送給了第二大公司（甲骨文）。通用軟件的生意通用軟件產業(yè)是一個介于過去的傳統(tǒng)行業(yè)與互聯(lián)網純數字行業(yè)的混合體（畢竟那會兒還沒有互聯(lián)網）。一方面，艾利森很快，軟件的邊際成本為零：只要你寫了一個特定的程序，就可以制作出無數的副本；另一方面，分發(fā)成了最大

10、的。在甲骨文的關系數據庫這個例子里，Relational Software Inc.（就是之前的Software Development Laboratories，這家公司在 1982 年改名為甲骨文系統(tǒng)公司，1995 年才改為今日的甲骨磁帶把軟件寄出去。團）不得不建立起一支銷售隊伍去賣，然后再用最實惠的做法，是做一個大多數客戶都想要的的半成品，然后和不同的客戶一起把最終完善起來。這里面一部分的工作在前端甲骨文可以快速用 C語言重寫新程序，而 C 語言在大部分平臺都有編譯器，支持甲骨文移植代碼但的工作是在售后：客戶需要安骨文，讓它工作起來，錄入他們的數據，只有這樣，在原始協(xié)議的幾甚至幾年以后，

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

12、下簡稱 AWS）背后的主張卻不盡相同。公司不需要預付款，也不需要綁定多年的整合項目服務，而是登錄帳號，使用完畢即可。公平地講，對于亞馬遜的那些有議價能力、簽訂長期合同的大客戶來說，這顯得過于簡單化了。但這只是最近發(fā)生的事。AWS 的用戶從開始一直都是初創(chuàng)企業(yè)。他。而且 AWS們利用這些耗費幾百萬美金的服務器基礎設施來建立最小可行性的花費是可變的：你用 AWS 越多（因為你的用戶數在增加），費用越高；要是幾乎不怎么用（因為你還沒有找到合適的市場），你就只需要花費比什么都不做多一點的機會成本。可選的價值觀使得 AWS 如此有價值：想要更大容量嗎？只需一鍵。需要一個新功能？AWS 包含有一套預構建服

13、務供你整合進。是的，它可能很貴一個普遍的說法是 AWS 贏在了價格上，而實際上 AWS 卻是眾多昂貴選擇之一但是，在你最需要的時候能提供你最需要的，這樣的服務到底值呢？與此同時，艾利森在本周的“開放的世界”大會上登臺領域“亞馬，宣布在遜的領先地位將會被終結”，只因為甲骨文最高端的服務器比亞馬遜更快更便宜。雖然如此，但是，層次數據庫也比關系鏈數據庫更快；速度不代表一切，價格也不?？蛇x擇性和可擴展性一直都很重要，在這方面，甲骨文的基礎服務遠遠不如亞馬遜有競爭力。當你關注一下云服務領域的關鍵數據，性，你甚至會發(fā)現(xiàn)艾利森的表述更加荒謬。在過去的 12里，甲骨文的性全部加起來是 10.4 億；亞馬遜在上

14、個季度花費了 33.6 億，過去 12是 109 億。并非接單定制的服務；事實是，那些基礎設施以及所有構建在基礎設施之上的附加服務早已讓 AWS 變得十分。甲骨文不僅沒有追趕上，甚至還被落得很遠。聚焦 SaaS在中，艾利森反駁了甲骨文的云服務基礎設施的花費是不必要的這種觀點，事實上，他指出，公司花了十年時間將它最具價值的應用移到云端。確實，公司上個季度花費了總收入的 17%用于研發(fā)，艾利森吹噓甲骨文現(xiàn)在已經擁有 30多個 SaaS 應用，而且這個數字很重要：甲骨文的戰(zhàn)略是什么？我們認為客戶想要什么？我們在 SaaS 領域該做什么？其實這是同一件事：如果我們能找出客戶想要的并交付出去，那客戶就會

15、使用并我們的。我們認為他們需要的是完成并整合在一起的，并非?？蛻舨⒉幌霃?50 個不同的供應商那里整合 50 個不同的。那太了。不僅困難，還存在相關的安全風險、勞動力成本和可靠性問題等等。所以我們最大的焦點不是賣出去 1 個、2 個、3 個、4 個應用，而是為 ERP，為人力管理，為客戶關系管理（有時也叫用戶體驗，簡稱 C的策略：完整的整合套件。付完整的軟件套裝。這是我們對 SaaS艾利森爭論的問題在部署型軟件方面是正確的；我曾在 2015 年就這個動態(tài)寫了一篇關于微軟的文章。想像一下云計算之前公司里的首席信息官（CIO）：微軟的各種解決方案（像 Exchange）。因此，為了支因為各種她不得

16、不持 Exchange 的服務，CIO 還需要Windows Server（微軟的一款服務器系統(tǒng)），Windows Server 又包括了活動目錄（Active Directory），于是還需要他的主題認證服務。但是，現(xiàn)在 CIO 已經有了一部分微軟的解決方案，她會更傾向于其他微軟的服務，不論是關系型數據庫管理系統(tǒng)（SQL Server）、客戶關系管理系統(tǒng)（Dynamics CRM）還是門戶和企業(yè)內網（SharePoint）等。確實，微軟的可能不總是最好的，但 CIO 都要考慮到現(xiàn)實情況：后續(xù)維護和服務費是一個巨大的隱憂，而且較少的供應商往往能帶來好處。事實上，微軟近 15 年來的壯大可以追溯

17、到巴爾莫聰明地利用新、新定價和協(xié)議，迫使用戶的公司。如上文所提到的，這和甲骨文的策略如出一轍。然而，企業(yè)的 IT 決策也在發(fā)生著的變化：首先，在不需要巨大的前期投資后，轉向另一家供應商的風險變得低多了，尤其是當只有團隊或部門層級試用過相關的時候。其次，沒有了持續(xù)的和后續(xù)的維護成本，也就減少了和供應商關于可變成本的爭論。當然，艾利森警告的將 50 個不同的供應商合并在一起使用的潛在麻煩也許會出現(xiàn)，但這也同時意味著軟件的實際質量和用戶體驗在決策中扮演著更主要的，且團隊決策這一點使之變得更為重要，因為服務的者就是實際使用者。過渡階段的甲骨文簡而言之，艾利森在兜售的新甲骨文看起來跟舊甲骨文很像：一大堆的，大部分客戶想要什么幾乎就做什么，至少理論上是這樣，但是既沒有 AWS 的靈活性和可擴展性，以及聚焦和承諾用戶體驗的SaaS 服務。在數據庫方面，像一個層次數據庫，甲骨文都是根據顧客的要求提前定制開發(fā)的，不需要任何靈活性。與此同時，AWS 和專門的 SaaS 服務提供商都是