連載傳送門：
- 什麼是雲原生？
- 雲原生設計理念
- .NET 微服務
- 談到雲原生，繞不開“容器化”
Backing services
雲原生系統依賴於許多不同的輔助資源，例如資料儲存、訊息佇列、監視和身份服務。這些服務統稱為支撐性服務。
下圖顯示了雲原生系統使用的許多常見支撐性服務
支撐性服務幫助實現了“十二要素應用”中的Statelessness原則
要素6提到：“每個微服務應在獨立隔離的程式中執行，將所需狀態資訊作為外部支撐性服務，例如分散式快取或資料儲存”
最佳實踐是將支撐性服務視為附加資源，並使用外部掛載的方式將配置(URL和憑據)動態繫結到微服務。
要素4指出： “支撐性服務“應通過可定址的URL公開，這樣做解耦了將資源與應用”
要素3指出： “將配置資訊從微服務中移出並外掛”
Stateless和支撐性服務，這樣鬆散的設計使你可以將一項支撐性服務換成另一項支撐性服務，或將您的程式碼移至其他公有云，而無需更改主線服務程式碼。
支撐性服務將在第5章“雲原生資料模式”和第4章“雲原生通訊模式”中詳細討論。
自動化
如你所見，雲原生依賴(微服務、容器和現代設計理念)來實現速度和敏捷性。
但是，那只是故事的一部分，你如何配置執行這些系統的雲環境？你如何快速部署應用程式功能和更新？
被廣泛認可的作法是基礎設施即程式碼(IaC)
藉助IaC，你可以自動化平臺配置和應用程式部署,你將諸如測試和版本控制之類的軟體工程實踐應用於您的DevOps實踐。你的基礎架構和部署是自動化，一致且可重複的。
Automating infrastructure
在底層，IaC是冪等的，這意味著你可以一遍又一遍地執行相同的指令碼，而不會產生副作用。
如果團隊需要進行更改，可以編輯並重新執行指令碼，(僅)需要更新的資源受到影響。
在《基礎架構即程式碼》一書中，作者Sam Guckenheimer指出：“實施IaC的團隊可以大規模、快速、穩定地交付。團隊不用手動配置環境，通過程式碼表示的所需環境狀態，來增強交付預期。使用IaC進行基礎架構部署是可重複的，可防止由於配置差異或缺少依賴關係而導致執行時問題”。
Automating deployments
"十二要素應用"指出了從程式碼開發到交付落地的原則
要素5指出：“嚴格區分構建、發行和執行階段。每個發行階段都應標有唯一的ID，並支援回滾功能。”
現代CI/CD實現了這一原則。它們提供的獨立部署步驟，確保將一致的、高質量的程式碼交付給使用者。
下圖演示了獨立的部署過程：
在上圖中，要特別注意任務分離。
開發人員在其開發環境中建立feature分支，反覆迭代“inner loop”(執行和除錯)。
完成後，該程式碼將被推送到程式碼儲存庫中，例如GitHub，Azure DevOps或BitBucket。
推送觸發自動構建，構建階段將程式碼轉換為二進位制產物。這項工作是通過持續整合（CI）管道實現的，它會自動生成，測試和打包應用程式。
釋出階段拾取前面的二進位制產物，加上外部應用程式和環境配置資訊，產生不可變更的發行版。該版本將會部署到指定的環境。這項工作是通過持續交付（CD）管道實現的。每個版本都應該是可識別、可追溯的。你可以說：“這次部署的是應用程式的Release 2.1.1版本”。
最後，釋出的版本放在目標執行環境中執行。版本不可變，這意味著任何更改都必須建立一個新版本。
應用這些實踐，從根本上發展了軟體釋出方式。許多人已經從季度釋出轉為按需更新。通過整合過程的一致性，團隊可以更頻繁地提交程式碼更改，從而改善協作和軟體質量。