AWS還是Azure? 請選擇合適的云服務提供商
譯文【51CTO.com快譯】不管你的企業是做什么的，幾乎可以肯定的一些功能會因為云服務的使用，而變得更快、更便宜、或是更有效。但是如何正確地分揀出哪些是該被剝離的，且將其發送到何處，則是一個充滿了潛在陷阱的問題。
另外，該問題的另一部分是：當涉及到云服務時，每個人都會有著自己的經驗與見解。其中許多是源自他們非常有限的參與，或是來自那些從廣義上說，是商業化云服務的所謂“與消費者服務”等效的營銷式想法。例如：在某種意義上說，Gmail之類的云端生態服務是肯定無法代表你所尋找的業務模式的。你無法因為是自己繁忙的一周，而要求谷歌單獨給你提供更快的服務;你無法無縫地轉移到另一個服務提供商;你無法將其服務副本的備份在本地運行;你也不知道什么樣的司法控制能訪問到你的信息。
云服務能做什么?
在此，我們坦率地說，就是一個合適的商業級的云服務應該能夠為你做到你所要求的一切。試想一個最不合理的架構，例如：有一些基于云服務管理的本地服務器，而且有一個提供商愿意為你管理它。那么如果你愿意的話，你可以要求通過以逐個字節進行拷貝的方式，將所有機器轉移到遠方的虛擬機上，從而把你現有的基礎設施變成一個云服務。但是，所有這些都存在著一個潛在的問題：這樣做是否會對你的業務發展有好處呢?然而這是一個只有你自己才能回答的問題。
不過，請不要太沮喪，如今有著大量適合云業務的產品，例如：微軟的Azure就在運行SQL Server方面表現出色;而亞馬遜的Web服務(AWS)，則從根本上徹底定義了Linux和Web應用程序的市場，以至于你很難找到理由不去從使用它們作為云業務的開始(其中一個很好的原因莫過于亞馬遜的那套DIY的理論了，即：讓你去實現如何處理一個類似業務連續性這樣的小目標)。
供應商間的大小區別
在主流品牌之間做出選擇是極具挑戰性的。雖然我們在此只看大的方面，但那些核心技術人員卻有著許多細節之處的思考，例如：亞馬遜和Azure在Linux虛擬機可用性方面的差異。此外，請不要將你的搜索局限于那些家喻戶曉的品牌。諸如Rackspace、Equinix、Zen或Memset這樣的公司雖然可能沒有什么典型的客戶列表在其彩頁上，但它們很可能會更適合于你的業務。
那么你該如何做出正確的選擇呢?在收集各種報價或填寫訂閱表格時，你又應該注意哪些關鍵問題呢?
首先，在轉移至云服務時，要面對的一個更為棘手的方面是：要弄清楚每個提供商所建議的解決方案背后的真正意圖。例如，亞馬遜和微軟都會告訴你：可擴展性乃是王道。所以你只會為你需要使用的部分買單，而這些錢來自于可消耗和運營方面的預算，而不是資本或是銀行資金方面的預算。然而他們卻不會試圖去搞清楚你的業務是否真正需要一個可擴展的架構。而這正是那些劣于營銷的提供商所能一展優勢之處：他們能提供更多的定制服務，并能盡更大的努力去了解你的真正需求。
不過，最終經費的問題還是會牽制到你的。因為你必須捫心自問，提供商所能提供的是否真正適合你的商業模式?還是你會被迫打造你的運營模式，以適應你的提供商?
雖然厘清自己的需求固然至關重要，但這還離整個過程的結束遠著呢。在你準備好做出一個明智的決定之前，你還需要試著將一系列令人眼花繚亂的因素，例如：投資、合同、采購、訂閱和架構等變得合乎情理。最近的一個可能會影響到你的云計算方面發展的情況是：薩提亞·納德拉(Satya Nadella，微軟CEO)的有關Azure的英國數據中心承諾已實現。這可能是歐盟公投以來的第一個大發展，而且會影響到許多公司對于托管主機選址的決定。
不要盲目求多
至此，你可能會希望我們在本文的某處展示一張對比的表格，也在疑惑所有這些問題在哪里會被考慮和闡述到。老實說，如果我們能發布一個大得足夠將一輛賓利歐陸車作為禮物進行打包的插頁紙的話，它將能夠陳述和涉及到諸如產品、選擇、警告、折扣和所提供的附加條件等廣泛的領域。但實際上，我們只能給你指出一般性正確的方向：如果采用的是規模較小提供商的話，其每個提供的細節會有所不同。而更重要的是，各種云平臺都會不斷推出新功能，因此，很可能在我們剛對這種或那種能力的缺失進行標記的時候，其補救功能就已經被添加出來了。
所以我們不應試圖去制定一張明確且詳盡的提供商之間對比的表格，而是應該正確地去思考你選擇的方法，列出一些更短但確實對你非常重要的方面，并專注地研究它們。
比方說：很多具有良好聲譽且反應敏捷的網站，是被相對較小甚至完全不為人所知的托管中心所運營的。因此很有可能在這些中心到達其運能極限后，將無法再提供動態可擴展性。也就是說：它們在你的網站變得炙手可熱、訪問量飆升的時候，只能單純地給你擴展出更多的服務器以供使用。但是當你真正以深究的方式開始觀察這是如何被觸發的時候，你會意識到：在這些更多的資源請求中，實際上包括著很多冗余且無效的流量負載。因此嚴格的程序代碼審查和控制相對較小的請求才是對服務提供商最為重要的。
而在業務的另一個極端，一些公司甚至在沒有巨大的擴展能力時，就無法正常運作起來。比如說某公司的業務人員，其工作負載是定位于高負載情況的話，那么他就需要能夠一次性產生成千上萬筆交易。而面對一張具有各種云服務提供商的詳細產品列表，他也只會對少數幾列產生興趣。
簡化你的登錄
許多企業轉向云服務提供商的一個原因是：管理方面的簡化，和對它們已經使用的托管服務的支持力度。確實，如果你的技術人員要建立和維護自己的虛擬服務器的話，那么亞馬遜和Azure會讓你處于其最為基礎的層面之上。無疑這對你的業務和提供商來說都是一種保證和平衡。但這種所謂的“平衡”如今正在從具體細節的方式轉移到宏觀地面向網絡的服務之上。畢竟，多年來，你可能一直與這種多個應用的模式打了長期的交道。然而，很多SaaS商家最初采取的卻是無障礙的免費模式。試想，一直以來，“分別購買各種軟件，并為新的版本支付費用”的模式已根植于我們的概念之中，并成為了業界規則。而今，你卻突然碰到了一個能夠連接那些所有實用的小程序到一個單一的企業身份管理的系統，而且最好是能納入到一個商業伙伴的單一服務合同之內。
可見，在這種特定的場景中，Azure已經遙遙領先了。雖然AWS有一些智能化的登錄管理，但它們并非建立在活動目錄之上。通過亞馬遜，你無法將你的業務領域安全模式擴展到云之外;相反地，云模式卻延伸到了你的業務之中。
一種模式并非萬能
也許你已滿足于自己本身的本地系統模式。畢竟，在許多情況下，云服務的吸引力只在于為了減少服務器的數量，你的空間和維護成本。因此，請不要陷入一種思維陷阱，即：認為你可以來一個“將所有舊的服務器連夜關閉，而在早上從其安裝到了云端‘克隆’里啟動”的反轉式遷移。微軟總是趨向于鼓勵將虛擬機在線遷移到Azure上。這樣做的確很“酷”，但這并不意味著它是一個適當的自動化方式。如果有人試圖說服你相信這個的話，那么他可能是出于促成你簽訂合同的目的，而不是幫助你得到正確的業務產出。
事實上，存在著一種混合模式——“將場外離站系統與場內協同使用，而非取代本地系統”的基礎設施架構。這將不僅是一個完全可行的選擇，而且通常還會是一個更好的選擇。從表面上看，相對于一個承諾能包辦一切的標準化組件而言，它可能看起來像一種折中且有些復雜的安排。然而，你所選擇的一種似乎能給系統的帶來最小壓力的模式，卻往往會衍生出一大堆未預料到的困難。因此，千萬不要低估那些為了使得你的服務器能100%符合Azure標準所涉及到的工作量。如果你使用的是一種并非一直處于主動開發狀態的產品(如Azure)的話，那么避免Azure模式的“持續更新”政策是很有必要的。你完全可以找一臺主機來對那些更新提前進行審查，從而降低風險。
這里還有另一個例子，是關于為什么決策矩陣能使得你的業務獨具特色的。正如在同行業的發展道路上，不同人在問自己同樣的問題時，很容易得出完全不同的結論那樣，云服務的范圍程度，及其提供商的大小不同，都會直接導致你的業務的各種服務能否與眾不同，且不會產生同質化的情況。因此道聽途說式的建議模式可能會對你選擇體面的筆記本電腦非常有用，但在指導人們去衡量云服務及其提供商方面則不那么會奏效了。
你的云清單
在簽署將各種關鍵業務服務轉移給云服務提供商之前，你至少要確認并完成如下描述：
1) 我理解我所需要的內部和外部資源之間的邊界位置，而且我的理由是……
2) 我所需要打交道的公司或其服務的數量為(X)，這是因為……
3) 當外部服務不法正常提供時，我對其的恢復計劃是……
4) 我能按照規范轉移出我的服務器，并且我正在開始一個全新的產品或是平臺。
5) 我相信我所使用的云服務的商業目標，它是和我公司的目標相一致且兼容的。
6) 對于各種最好或最壞的情況，我已經對每月需要移動和儲存多少數據做了一些粗略的估計。如果我的估計有些偏離的話，我的行動計劃是……
【原標題】AWS or Azure? Choosing the right cloud provider (作者: Steve Cassidy )
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
