云越發展,鎖定問題就會越嚴重?
就像HBO的史詩奇幻劇《權力的游戲》(Game of Thrones)有好幾季一樣,消費者云計算(consumer cloud)的發展也經歷了不同的階段。
總結一下,這場由蘋果,谷歌,微軟和亞馬遜等巨頭發起的“服務的游戲”***季圍繞于移動操作系統平臺,贏家是蘋果和谷歌。
而第二季是關于服務本身,這些公司在云存儲,應用程序,消息,音樂/視頻/書籍內容方面提供了大量服務,以及不斷推進這些服務的發展。
第三季是關于公有消費者云服務的API訪問之爭。從很大程度上來說,如今谷歌和Facebook仍是最重要的消費者云,而對它們中的各類API進行訪問也是一個不斷變化的目標。
第四季的內容呢?答案是企業/商業云的發展。我們在這里討論的是公有云的超級擴張者: AWS、微軟Azure、谷歌云,以及IBM云。
到目前為止,企業云工作負載可以分為IaaS、PaaS、SaaS或三者的混合。這類天生時就被設計成在云中運行的工作負載通常被稱為“生于云”工作負載,而那些自本地數據中心的傳統客戶機/服務器遷移到云中的負載,則被稱作遷移工作負載。
如果我們把這些東西結合起來,并在云和本地之間進行分割,就得到了混合云架構。
在大多數情況下,企業/商業云托管服務可以被視為一種商品并進行互換。計算/虛擬機、存儲和網絡是基本的IaaS服務,這些服務在巨頭中是一樣的,它們也都應用了一種逐底競爭的方式。
在Docker等開源應用程序打包標準上運行的容器,以及使用Kubernetes等編排系統的容器,是下一代的計算,而這也正在被商品化。它比虛擬機更便宜,也更容易擴展。如果在一個公有云上運行一個基于Docker的應用程序,那么將其移植到具有類似容器托管服務的另一個公有云上是相當簡單的。
超大規模用戶(hyperscalers)可以嘗試在性能和其他一些方面對這些服務進行區分,但在基本層面上,IaaS還是IaaS,而容器還是是容器,無論它們是在AWS、Azure還是谷歌云上運行。
實際上,廠商商業云的區別在于SaaS和PaaS。對于像微軟這樣的公司來說,它的SaaS,比如Office 365、PowerBI、Dynamics、SharePoint、 Teams和Skype For Business,是它區別于行業其他公司的地方。這些應用程序平臺曾在本地擁有相當大的市場份額,因此將客戶轉移到基于云的托管版本(SaaS)是IT從傳統安裝過渡到現代化訪問的一項自然過程。
但這些工作負載非常棘手,因為它們被綁定到微軟的Active Directory身份驗證機制中,該機制是基于微軟的環境的基礎技術。由于這些客戶已經被鎖定,他們并不打算離開這些應用程序平臺,因為沒有更好的替代方案。
另一方面,通過PaaS,用戶可以托管數據庫來托管機器學習和大數據計算等系統,而這些都是基于事務計費的。當這些系統與基于容器的PaaS結合時,企業客戶可以被允許構建高度可擴展的系統,否則在IaaS中實現這些系統的成本將非常高,并且可以按需供應。
到目前為止,很多這樣的系統都是在開源平臺上構建的,如Hadoop或MongoDB。但是現在我們開始看到超大規模云供應商也構建他們自己的后端高度可擴展服務,這些服務與開源服務兼容,但并不相同。
一個這樣的例子是AWS最近發布的DocumentDB,這是一個托管的數據庫服務,它可兼容MongoDB的API,但不使用任何實際的MongoDB代碼。
目前,用戶可以在AWS中構建應用程序,使用IaaS和基于容器的系統,并將后端應用程序構建到DocumentDB中,稍后也可以將它們移回本地,甚至是另一個與之競爭的超大規模云服務中,如微軟Azure或谷歌云平臺,但這可能不是完全不受限的。
今天,許多托管服務都使用與開源服務兼容的API。因此,代碼是可移植的;它并不局限于云供應商。
這與從一個基于SQL的數據庫移植到另一個數據庫的經典問題并沒有完全不同,只要它們被編碼為ANSI SQL規范。在這種兼容性級別上,數據庫是否從Oracle啟動并不重要,然后可以將其移動到IBM DB2甚至微軟SQL Server上。
但是,隨著這些服務變得商品化,就像IaaS在計算和存儲方面所做的那樣,云供應商將增加他們自己的特性增強,這將使它們與開源對手們有所不同。軟件開發人員會喜歡這些新特性,特別是它們能夠提高性能與可擴展性,并且能夠在事務或計算成本上節省成本。
這也是他們轉向PaaS、容器和云中微服務的首要原因之一——打造真正的“云原生”應用。此外,他們可以專注于運行應用程序平臺和代碼,而不必擔心底層基礎設施。IaaS實際上只是將復雜轉移到了云中間層,所以用戶仍需擔心系統堆棧的維護與操作。
不過,如果為了利用性能優化而將業務邏輯強行放入某個特定數據庫平臺上進行存儲與運行,那么用戶最終可能會遇到嚴重的兼容性問題。
這樣想,從Oracle轉移到IBM DB2就不是一件簡單的事了。將業務邏輯移出數據庫可能會花費用戶大量的軟件開發時間(和金錢),因此它們可以選擇將其從一個平臺移植到另一個平臺。
曾有一個IBM的銀行業客戶在Oracle中放置了800個存儲過程和觸發器,如果要刪除所有這些并將邏輯轉移到J2EE上的中間件中,則需要花費數百萬美元。盡管DB2在許可方面比Oracle便宜,但是軟件開發成本要高得多。最終客戶還是選擇了使用Oracle,但還是將其遷移到不同的操作系統和硬件平臺(IBM的AIX和POWER)以獲得所需的性能。不過,該客戶還是被鎖定在了Oracle的數據庫中。
這樣的情況也發生在更大規模的云中。當然,DocumentDB現在與MongoDB兼容了。但誰能說,五年后,這些API將是相通的呢?DocumentDB只是一個云服務,一個高度可擴展的、在云中誕生的應用程序可能被設計成僅特定于某云供應商的十幾種的云服務產品。
比如,微軟Azure的組合中有多少服務?不可勝數。當然,其中很多都使用開源標準,但是又有多少不是呢?而且,那些與開源兼容的服務將完全保持這種狀態多久? 隨著AWS、微軟、谷歌云和IBM彼此之間的競爭越來越激烈,它們很可能會放棄目前的想法。
企業用戶越失去對基礎設施的控制,并將注意力轉移到嚴格運行應用程序代碼和必須依賴于托管平臺上,該平臺變得棘手的可能性就會越大,而這正是AWS和微軟等超大規模供應商所希望的。他們想讓客戶留下。他們希望他們不斷進行購買和交易。他們不希望客戶離開他們的云。像Office 365、Workday和Salesforce這樣的SaaS系統顯然是***粘性的。
其實這與擁有本地軟件平臺沒有什么不同,這些平臺是專有的,使用的代碼不容易移植到另一個平臺。不同之處在于,用戶并沒有授權這些平臺,而是租用了這些平臺上的空間,這是組織中精打細算的人所喜歡的,因為這是一項運營費用(OPEX),而不是資本費用(CAPEX)。
因此,用戶當然可以設計出基于云的系統,這些系統是相當獨立且是可移植的。 但長期這樣做可能在經濟上不可行。 對比之下,完全的云服務將比用戶在IaaS中使用虛擬機中或甚至在容器中托管的服務便宜。 而使用PaaS,權衡關鍵最終將取決于性能,功能以及成本與可移植性。
那么隨著我們越來越依賴完成的云服務,云鎖定是不可避免的嗎?