[[171272]]

IT經理、架構師和開發者都嘗試妥協于微服務和容器對企業IT方式的改變。在某一個層面來說這是一件好事，但是事實上，一些更深層次的東西在驅動著技術和IT。

要理解微服務和容器，可以從抓住它的價值定義開始，然后將IT和數據中心的性能與這個變革的驅動者進行匹配。***，為了敏捷性來構建架構，而不是為了追隨下一個大熱點來構建架構。

IT策劃者和經理們一定要了解到應用程序和工作者之間基本關系的變化——特別是事件驅動型、移動的工作者——他們是使用容器和微服務的驅動者。IT方向的轉變會讓昂貴、長期存在的基礎架構向動態的市場進行靠齊。這意味著不僅僅是更多高效的云服務或者更低的操作復雜性，還能更好地對他們IT的需求進行響應。

現代的工作者

應用軟件從記錄業務活動進化到促進業務活動。應用程序創建了一條企業可以跟隨的創建運營計劃的最小阻力路徑。企業架構師已經通過數十年的努力想把應用程序與業務的目標達成契合，但是他們通常會被現在用來經營業務所使用的可用的IT工具所阻礙。

智能手機設備的出現加速了這個現象。手機app的工作者需要得到對他們工作的支持，而不是遵循一些已經預定義好的工作流。手機工作者是事件驅動型的，這意味著應用程序也需要這樣。微服務不是為了IT發展所尋求得商業計劃，而是一種響應戰略性需求的構造應用的方法。

比傳統的虛擬化更少的日常開銷

在應用程序的層面，微服務促使架構師和開發者不僅僅把產品特點和流程當成是服務，而是重新思考整個流程和應用組成的概念。伴隨著面向服務的架構體系( SOA))和其他基于服務的方法論，流程將組件捆綁變成組合的應用程序。微服務的目標是讓工作者的工作和組合的營養程序綁定到一起。每一步和特性都是按需求而定的。

可能微服務和敏捷IT帶來的***的影響就是每一個組件都變得很關鍵。在一個應用模型中，每一個組件的組成都是顯而易見的，所以你可以有根據地將關鍵和非關鍵的app分開。但是在微服務模型里，一個組件可能是關鍵app的一部分，也可能不是，這取決于工作環境。規則、安全和可用性必須在所有地方都達到要求，而不僅僅是需要的地方達到要求就可以。

微服務臨時的特性是驅動著容器技術的關鍵。而虛擬化，不管是在數據中心還是在云端，不管是如何組合的都會有比較高的應用程序開銷。如果服務是小型的、策略性的，那么虛擬化的費用是很難平衡的。如果微服務有廣泛的接受程度，那么容器會更加普遍，微服務會成為事件驅動型IT模型的基礎。

微服務一定要基于正確的組件架構上，這會讓IT能動態地部署和規劃組件。非狀態化組件和更功能性的編程方法會主動阻止開發者創建狀態化的組件。開發經理和架構師現在已經有一些功能性的工具，比如廠家微軟和Oracle通過Lambda表達式創建的的功能性編程。但是他們還是需要圍繞著微服務的開發環境來做一些功能性的領域，因為編程的必要模型還是存在的。

增強后端

采取容器技術并不意味著保證數據中心會進化成***去支持微服務和事件驅動型IT。當程序變得越來越敏捷也意味著對它們的開發會變得越來越沒有效率。通過幾步來阻止這一切的發生吧，與業務負責人和開發者進行協商，讓應用在設計的時候就避免過多的、沒有保證的部件化。失控地使用微服務會帶來IT的低效率，且不會提高最終用戶的敏捷性。除了這些，IT運營團隊還必須修正數據中心運營的方式和數據中心本身。

微服務和事件驅動型組件在網絡延遲最小的情況下是最有效率的，這包括通過整個數據中心的延遲，以及多個數據中心或者公有云服務之間的延遲。使用快速的局域網作為數據中心的核心，在服務器和網絡適配器上提供優化過得網絡路徑，避免虛擬交換機的過載。連接多個數據中心來減少延遲和丟包，這會嚴重惡化微服務的性能。

不能變快的應該被阻止。按需要規范新的應用程序部署和DevOps工具，讓微服務變得合適。托管微服務到接近需要連接的地方，同樣也要離固定的資源比較近，例如數據庫，來避免過多的傳遞延遲。在將微服務放到IT資源的時候，要尋找編排的工具來考量以上這些點。對IT運營人員進行培訓，讓他們在安裝參數和策略的時候提供正確的連接信息。

微服務和容器，被業務敏捷性所驅動著，它可能會產生一個巨大的力量來強迫數據中心接受私有云，支持混合云部署。當在虛擬化環境下建立微服務和容器模型成為可能的時候，對敏捷應用的需求會影響特性和功能的遷移。對云友好的內部實踐和客戶創新的公有云采納方案會讓彈性組件縮放自如。