公婆都有理 云計算時代企業如何下注及應對？
什么是使用云計算的正確方法一直是業界關注的熱點話題。
公有云提供商希望數據中心能使用通過網絡交付的按需支付服務。而許多硬件廠商宣稱企業用戶通向云計算之路應該通過運作私有云來實現。還有其他圍繞云計算的爭議糾纏在一起需要用戶自己進行判斷。
公婆都有理 你如何抉擇
你會采納那種建議？在未來3年、5年甚至10年內你應該如何來對配置和運作IT資源進行規劃？你會把你的雞蛋放在誰的籃子里呢？
從某種程度上來說，你的答案可能要取決于你是誰，你的IT交付或者使用中的角色是什么，還有諸如數據丟失的敏感性問題，法律法規的需求和IT企業架構的完備這些眾所周知的因素。
不過引起爭議的是如果你有這方面的IT投入或者你有超出目前云計算技術或者業務模式的需求，你就不應該做這種選擇。
許多爭議是源于云計算存在太多的變數，沒有人可以預測向云計算過渡會如何發生(我堅定的相信云計算是IT領域緩慢但不可避免的發展趨勢，IT領域將最終被公有云服務所控制)。
如果公有云提供商的觀點是正確的，IT在某種程度上是一種公共效用，那么預測未來十年或者這種過渡幾乎是不可能的。
如果硬件廠商的觀點是正確的，你必須在了解如何將關鍵任務系統遷移到公有云之前在你現有的設備上實現云，那么什么時候這么做，怎么做本身就比較復雜了，可能與每種業務需求都有所區別。
如果"云是一時的狂熱"這種觀點是正確的，那么嘗試任何云的體驗都將是浪費金錢。
每種結論對于多數人而言都存在差異是毫無疑問的，如果并非所有的企業都是傳統數據中心，私有云和公有云環境的雜合體的話。想象一下這種"混合IT的三角之勢"吧。
#p#
IT企業靈活適應不確定的基本規則
因此到底該如何做呢？現代IT企業如何改變方式來靈活的適應其運作模式未來的不確定性呢？
這么做最簡單的方法是制定幾條基本規則，有些規則多年來已經為大家所熟知，有些規則需要在云計算模式下加以清晰：
1.將注意力放在應用軟件而非服務器上。在我早期的DevOps系列中我質疑的是虛擬化和云為什么在強迫軟件研發人員和運營團隊將他們的"配置單位"從服務器裸機轉向應用軟件本身。這是一個重要的理念，因為你在這種三足鼎立中可以在所有三個點上來管理應用軟件。
這看起來像什么呢？虛擬化能讓實現這一點更加容易一些，因為你可以為單個應用軟件，單個應用軟件分區或者服務構建虛擬機映像。在這點上指的不是被操作的虛擬機，更多的是是文件系統甚至是在虛擬機上運行的應用軟件代碼本身。
如果你想將應用軟件從內部的VMware環境遷移到XEN云提供商，你所面臨的挑戰就是得到同樣的文件系統或者僅僅是在***基礎架構上運行的應用軟件本身。這對于如今的多數IT企業正常嗎？不正常，但是這種方法的誕生在混合IT環境中有著很大的優勢。
2.從基礎架構運營上減輕有效載荷運轉。DevOps系列的另一個主要爭議點是云在強迫操作角色從傳統的"服務器，網絡和存儲"改變為更加接近基層的"應用軟件"和"基礎架構"。
基礎架構的操作者掌控著由數據中心，校園網絡等等組成的"全景藍圖"(服務器，存儲設備，交換機等等)。他們也管理著實施資源消耗自動化和監控任務的軟件系統，比如軟件平臺和IT管理系統。
應用軟件的操作者關注更多的是應用程序代碼，數據和將軟件功能交付給最終用戶或者其他應用軟件系統所需的連通性。他們都是需要選擇在那里配置應用軟件和如何操作這些軟件的關鍵人物。由于公有云系統不允許他們訪問裸機，他們必須設計出不依靠這種訪問的流程。
3.選擇可以幫助你在所有三種方式中游刃有余的管理工具。目前市場上有如此眾多的管理和監管工具可供選擇，他們能幫助用戶在虛擬數據中心，私有云和公有云里進行應用軟件配置，管理，監控和使用。
對云最關注的重點之一就是所謂的"鎖定"。在云環境中，鎖定有著特別陰險的一面;如果一家云廠商關門歇業了，你的基礎架構可能也隨之消失了。規避這種風險的一種方式就是選擇以應用軟件為中心的(或者至少以虛擬機為中心)管理工具或者能幫助你將數據和應用軟件快速遷移到任何地方的服務。
就像云和云之間及虛擬平臺之間的靈活性一樣，依賴管理環境來實現靈活性是個更好的過渡性戰略。如果這些工具或者服務能對備份，數據加密和災難規避等起到幫助那就更好了。
如今市場上工具和服務的完善程度還不足以幫助這些戰略輕松實現，但是筆者認為做出文化和程序上的改變將讓你未來在混合IT環境中的生活變得更加容易應對。從另一方面來說，一種成果的成績斐然很大程度上意味著錯失了其他方面的有用性。
【編輯推薦】
