使用基礎設施即代碼(IaC)，捏可以編寫有關基礎設施計算，存儲和網絡要求的聲明性說明，然后執行該聲明。這與平臺即代碼(PaC)有什么不同?

任何應用程序的技術堆棧都分為三層，即包含裸機實例，虛擬機，網絡，防火墻，安全性等的基礎層;具有操作系統，運行時環境，開發工具等的平臺層;當然還有包含應用程序代碼和數據的應用程序層。典型的技術運維團隊除了可以部署代碼外，還負責基礎層和平臺層的部署，監控和管理任務。

云計算的興起，首先讓基礎層得以抽象化。借助基礎架構即服務(IaaS)模型，IT/運維團隊只需通過云即可立即配置云基礎架構。AWS、微軟Azure、谷歌GCE，阿里云等都提供廣泛的IaaS服務，如AWS EC2。在其上的是平臺即服務(PaaS)模型。基礎設施提供商在云上提供平臺層，包括云操作系統，開發工具，數據庫管理等。比如你熟悉的AWS Beanstalk，Azure CDN，Google App Engine之類的PaaS服務也廣受歡迎。

實際上，運維團隊還自己構建PaaS平臺，將選定的功能子集整合到與其現有的基礎架構兼容，或具有自定義工作流程的功能。如果你使用容器化或微服務范式，這可能會讓你變得乏味且笨拙。

在構建基于微服務的應用程序中對規模，一致性，可重復性，可共享性和可審計性的需求，迫使運維團隊考慮采用新方法來處理基礎層和平臺層。正是針對這些擔憂，出現了基礎架構即代碼(IaC)和平臺即代碼(PaC)的概念。

基礎架構即代碼

基礎架構即代碼通過軟件而不是物理硬件配置或其他工具來管理和配置基礎架構。使用IaC，你可以編寫有關基礎設施的計算，存儲和網絡要求的聲明性說明并執行。然后，自動化引擎(如AWS Cloud Formation和Terraform之類的工具)將通過抽象的IaaS API捕獲聲明/代碼來為你配置它。

結果，無論是交付管道的自然組成部分，還是為了響應特定事件而自動擴展，供應基礎設施的速度都將顯著提高。如果你使用dev，QA，staging，prod等多種環境，則使用同一代碼庫啟動基礎結構可確保一致性，并通過減少錯誤配置，停機等風險等來節省大量時間和可能的麻煩。變更管理也變得非常重要，而且更簡單。你可以編寫代碼來更新基礎結構，并具有完整的版本控制。

這對云上的容器化應用程序特別有影響：

容器化和微服務啟動了數百個小型應用程序，而不是像以前的開發范例中那樣使用少數大型實例。在這樣的規模下，開發過程將存在時間滯后，從而嚴重影響敏捷性。

在多云部署中，數百/數千個應用程序的可重復性對于交付一致的客戶體驗至關重要。

云計算的付費機制，使其謹慎地根據需要動態擴展和縮減基礎架構，在這種規模上幾乎無法手動進行管理。

使用基礎架構即代碼，云本機應用程序可以大規模地具有一致，可靠且受版本控制的基礎架構。但是，僅IaC并不能提供最佳的應用程序生命周期管理經驗。該平臺仍需要由運維團隊進行配置和管理。IaC是通過將抽象作為基礎層API的包裝程序來實現的，因此，開發人員將需要為每個抽象提供新的CLI。

為了獲得流暢的開發人員體驗，僅IaC還遠遠不夠。我們需要平臺即代碼。

平臺即代碼

平臺即代碼(PaC)是平臺層的抽象。PaC允許將有關平臺層的聲明性說明，包括應用程序的開發和操作所需的操作系統和其他工具寫入代碼并執行。

本質上，PaC允許開發人員定義自己的平臺。也就是說，為應用程序提供定制的執行環境。對于每個應用程序來說，這可能是不同的環境，它們有多少個。如果Kubernetes是你選擇平臺，則可以像編寫應用程序代碼一樣為平臺元素編寫YAML聲明。

與IaC不同，PaC通過抽象實現為Kubernetes API擴展，而不是通過k8s API編寫包裝器。因此，PaC抽象成為一流的實體，允許開發人員使用kubectl和YAML提供聲明性指令。

自動化所節省的時間和精力不言而喻。但是，在Kubernetes上PaC的真正價值在于，即使開發人員正在為其K8s集群創建自定義平臺堆棧，它也將具有可重復性和可控制性。這將確保應用程序的開發/生產的奇偶性。所有平臺元素，例如YAML文件，管理員清單等都是可共享的。使用Kubernetes Operators還可以在多云環境中一致地部署。

平臺即代碼范例，已實現了大規模，高效，一致，可重復的企業應用交付。通過通用語言進行協作，使開發(Dev)和運維(Ops)更加緊密。最重要的是，它為下一代開發生命周期工具鋪平了道路。它提供了迭代開發，優化的工作流，輕量級的客戶端工具，可用于生產的CI/CD管道和以應用程序為中心的部署自動化。