對于任何一個力，都存在著一個與其大小相等方向相反的反作用力。這個物理學上的牛頓第三定律也同樣適用于IaC：雖然這一服務是有優勢的，但它也帶來了一些問題。

　　本文是針對混合云和多個云管理使用基礎設施即代碼系列中的一部分。

[[170723]]

　　基礎設施即代碼是一個強大的工具，它可以幫助簡化混合云和多個云的管理工作，因為它能夠實現服務器、容器以及虛擬機的部署與配置操作的自動化。但是，它也可能會導致出現低效過程、部署錯誤以及常見混亂等問題。那么，用戶應當如何解決實施能夠確定成功與否的基礎設施即代碼所帶來的挑戰呢?

　　在實施基礎設施即代碼過程中，大多數企業所遇到的第一個挑戰就是在開發人員和運營團隊之間創建一個和諧融洽的平穩關系。在過去，開發人員在為應用程序設置托管平臺時幾乎很難有所作為。這就會帶來問題，尤其是在從應用程序測試到實際生產的過渡過程中更是如此。在大型企業中最常用的開發運營工具能夠有助于推動開發團隊和運營團隊之間的協作。但是，對于那些缺乏開發運營理念與工具以及相關企業文化的公司來說，實施一個混合云或多個云可能是第一次需要這樣一種合作。

　　如果企業用戶在開發初期就將應用與特定平臺相互關聯，然后讓這些平臺需求推動基礎設施策略貫穿整個應用程序生命周期管理直至最后生產，那么實施一次基礎設施即代碼還較為容易完成的。此外，當虛擬平臺數量是可管理時，這一目標也是較為容易實現的。這些虛擬平臺是應用開發的目標，它們可用于在所有云中或者數據中心資源(應用就是在數據中心資源上運行的)上部署應用。仔細定義這些虛擬平臺并讓開發團隊和運營團隊使用它們作為各自工作的重點。

　　不要模糊不同角色之間的界限

　　第二個挑戰就是確保基礎設施即代碼和開發運營團隊在混合云和多個云管理策略中各司其職，正常發揮合適的作用。開發運營主要關注應用程序部署，而基礎設施即代碼則主要負責資源配置管理。亞馬遜網絡服務(AWS)提供了開發運營工具Chef作為其云服務的部署管理工具，這一事實表明兩者之間的界限有可能會發生模糊。事實上，最常見的基礎設施即代碼工具是開發運營的一部分。這一狀況可能會造成開發團隊和運營團隊之間的持續混亂。

　　除非用戶純粹出于服務器整合的目的來使用云服務，希望還需要開發運營來實現部署自定義和應用程序生命周期管理的簡化。對于企業用戶來說，如果沒有正確好用的工具集，那么部署多層次、多組件應用程序并保持一致地正確協調應用程序響應云計算或數據中心故障將是一項非常困難的任務。即便用戶并不立即需要所有的開發運營能力 ，那么也可以選擇一個開發運營工具，例如Chef、Puppet、Ansible或Salt等，然后采用其基礎設施即代碼方法。

　　不要千篇一律地對待所有的云服務供應商

　　當使用基礎設施即代碼來簡化混合云和多個云管理時，第三個挑戰就是解決不同云托管環境之間的差異性問題。大多數用戶最終將使用一個混合云計算模式或多個云模式，而其中很多人已經這樣做了。每一家公共云供應商都有一個不同的管理框架，他們報告問題的方式也不一樣，如果發生錯誤所需要采取的補救措施也不相同。管理這些問題將讓開發運營所部屬的和基礎設施即代碼所控制配置的應用程序之間的界限變得模糊起來。

　　按照用戶開發運營工具供應商的建議來區分定義，何種情況由基礎設施即代碼層來處理，何種情況在開發運營層作為“事件”上報。確定用戶所計劃做出的任何變更是否會影響如何部署虛擬平臺，或者如何部署應用程序本身。在第一種情況下，可考慮重新部署資源，例如虛擬機或容器;而在第二種情況下，可考慮重新部署應用組件。例如，如果用戶必須擴展應用程序中一個組件，那么相關變更必須發生在開發運營層，但如果用戶必須更換故障組件，那么有可能應在基礎設施即代碼層實施這一操作。

　　云供應商有不同的網絡服務，這一事實就帶來了下一個挑戰。基礎設施即服務和基本容器服務在應用鏡像外提供了最小的中間件。但是一些供應商(例如AWS和微軟Azure)提供的網絡服務從本質上說就是云托管的中間件。云供應商提供這些網絡服務的形式各有不同，或者在某些情況下，他們甚至都完全不提供這些網絡服務。

　　由于不同的托管環境無法提供相同的功能，所以應用無法具備跨不同托管環境的可移植性。如果不可能在多家云計算供應商之間實現網絡服務的一致性，那么應當明確命名虛擬平臺以表明它們是不可移植的。如果用戶所使用的所有平臺上必要的網絡服務可用，但需要不同的部署配置，那么用戶可以使用基礎設施即代碼腳本程序來為用戶虛擬平臺定義多個托管選項。

　　不要碎片化實施基礎設施即代碼

　　實施基礎設施即代碼的最后一個挑戰就是配置外部的小修小補。讓基礎設施即代碼在斷開連接的碎片環境中正常運行是非常困難的，同樣讓企業在缺乏基礎設施即代碼工具或腳本程序的情況下做出某些配置變更也是非常不容易的。例如，運營團隊經常會在不更改基礎設施即代碼腳本程序或模式的情況下做出一些配置變更以適應新的軟件版本。這就意味著這些腳本程序將不再部署托管配置的正確版本。

　　解決這個問題需要執行嚴格的運行紀律。如果沒有通過正式的變更管理系統將這個變更記錄在冊，那么運營團隊就絕不應當對系統或云配置做出這樣一個變更操作。當他們確實需要做出變更時，他們應當修改基礎設施即代碼腳本程序并按要求重新配置，然后將相關變更登記在冊。無論何時運營團隊修改了基礎設施即代碼的腳本程序，他們都必須將這個變更反饋給開發團隊以便針對應用程序需要驗證該變更。

　　基礎設施即代碼是基于配置管理和開發運營的一種發展，但他也是一個新興的范例。為基礎設施即代碼的未來做好規劃是非常重要的，否則用戶將面臨無法發揮混合云和多個云管理部署全部潛力的風險。