大衛(wèi)·羅素曾說過：“選擇是人生中最困難的事情——你要去知道跨哪座橋,拐哪個彎兒。(hardest thing in life to learn is which bridge to cross and which to burn——David Russell)”。
前一段時間，我將自己定義為一名CIO，從多個基于云服務商業(yè)解決方案交付的角度來考量混合架構。在過去的5個月中，我有幸能與來自不同大公司的數(shù)十名CIO和CTO進行交流，從而對問題的答案有了非常深刻的認識。在這期間，我閱讀了大量關于混合架構的文獻和博客，但是在混合云架構使用上，產(chǎn)業(yè)中很顯然還沒有形成一個共識。
企業(yè)選擇擁抱云技術可能會基于各種不同的原因——獲得更強的敏捷性、降低成本、全球可訪問等等。但是對于許多我交流過的CIO來說，這實際上可歸結于一件事——使用云技術將之前許多無法作為業(yè)務提供的寶貴資源變成業(yè)務。換句話也就是說，組織通過建立產(chǎn)品和服務，在其優(yōu)勢領域內(nèi)將基礎設施維護這個重擔變成業(yè)務。
即便如此，許多企業(yè)內(nèi)部已經(jīng)存在了大量基礎設施，機構不得不繼續(xù)對其進行管理和運維。同時，與許多期望將基礎設施遷移到云上的CIO進行交流后也了解到，雖然選擇云服務對這些機構來說很有意義，但是對他們來說，這并不是一朝一夕就可以完成的任務。在遷移到云的過程中，公司需要一個途徑來利用已有的基礎設施，也就是說從已有的投資中獲得回報。我曾今發(fā)表過“The Enterprise Cloud Journey”一文，講述機構如何利用 AWS Virtual Private Cloud(VPC)Direct Connect 讓內(nèi)部部署的基礎設施與AWS連接，從而打造一個混合架構。對我來說這個混合架構一直很有意義，同時它也讓許多公司可以最大化利用云技術的優(yōu)勢。
然而在這些之外，市場上對混合架構采用的理解上存在些誤區(qū)，其中有3個初聽起來甚是“靠譜”，但根本經(jīng)不起抽絲剝繭。這三個流言是：
流言1：混合架構才是未來。
對于混合架構來說，使用未來描述顯然有些牽強。無可否認，對于許多大企業(yè)來說，在未來很長的一段時間內(nèi)它們?nèi)匀恍枰捎靡粋€混合的架構，這個時間可能需要以年計算。每個企業(yè)的云旅程都不盡相同，其中每個企業(yè)都會選擇一個恰當?shù)臅r機做云遷移。但是即便如此，我仍然無法想象未來各個企業(yè)回到自建數(shù)據(jù)中心的理由。也許，在3年內(nèi)企業(yè)可能無法完全遷移到一個云環(huán)境，但是我相信這個遷移的時間不會超過15年。在這里，我最少看到了3個促成這種轉(zhuǎn)變的因素：
1. 隨著云采用的增長，云供應商將獲得更好的規(guī)模經(jīng)濟。無論如何，規(guī)模經(jīng)濟帶來的收益最終將返回用戶。
2. 云技術帶來的創(chuàng)新步伐是前所未有的。2014年，AWS發(fā)布了超過515個增強功能，更新頻率幾乎是過去3年的兩倍。
3. 公司業(yè)務(比如e-mail、productivity、HR、CRM等)依賴的技術被越來越多的云化。
4. 幫助公司遷移到云上的技術和業(yè)務得到快速發(fā)展。
流言2：混合架構可以讓你無縫地在本地基礎設施和云基礎設施之間進行切換。
從表面上看這點非常有吸引力，但是這里存在一個本質(zhì)上的先天缺陷。因為這么做的前提是，本地基礎設施和云基礎設施擁有同樣的能力。對于那些有能力管理自己基礎設施的公司我非常欣賞，然而許多公司之所以遷移到云基礎設施就是為了獲得其本地數(shù)據(jù)中心不具備的特性和能力：真正的彈性、安全性、按使用付費，以及不斷地創(chuàng)新。架構一個在本地數(shù)據(jù)中心和云數(shù)據(jù)中心無縫切換的應用程序無疑意味著你只能獲得這兩個基礎設施的最低功能。
流言3：混合架構可以讓你的應用程序橫跨多個云供應商。
這里存在的問題是這個論點被曲解了，我認為這個非常值得討論。時至今日，公司使用不同的云解決方案來迎合自己的業(yè)務需求。這通常包括了一些IaaS服務以及運行在非本地數(shù)據(jù)中心(通常是AWS)的封裝方案。這么做是非常有意義的，基于約束，高管們顯然應該選擇最適合業(yè)務的工具。
然而，這里讓我無法想象的是，在單個應用程序的架構上，很多公司陷入將其架構成可以運行在多個提供商上的誤區(qū)。我可以理解這么做的原因所在：讓多個云可以同時工作確實非常有吸引力。但不幸的是，這么做會耗盡公司最初遷移到云環(huán)境所獲得的生產(chǎn)力提高。因此，我一直認為這是一種退步的做法。取代管理本地的數(shù)據(jù)中心，這么做需要管理多個不同數(shù)據(jù)中心之間的差異。就像流言2一樣，它同樣會將你限制到通用的最低功能。
但是我也認可機構選擇這個途徑的理由——保持服務提供商的誠實，也避免被單個提供商鎖定。同時，我認為在這個問題的考慮上應該有一些折中的選擇，比如使用Container等技術讓環(huán)境可以更好地重現(xiàn)。這種最佳實踐允許其充分地利用云的彈性，同時也能做到應用程序與基礎設施的解耦。如果實現(xiàn)良好，不同提供商之間的轉(zhuǎn)移將異常方便，當然得有一個合適的轉(zhuǎn)移理由。
有時候，技術選型并不一定容易。同時，我們也并不一定必須去建立一個混合架構。
轉(zhuǎn)型的最終目的 -提質(zhì)降本增效
分享到微信 ×
打開微信，點擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。