支撐性服務 & 自動化
連載傳送門：
- 什麼是雲原生？
- 雲原生設計理念
- .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版本」。
最後，發布的版本放在目標執行環境中運行。版本不可變，這意味著任何更改都必須創建一個新版本。
應用這些實踐，從根本上發展了軟體發布方式。許多人已經從季度發布轉為按需更新。通過集成過程的一致性，團隊可以更頻繁地提交程式碼更改，從而改善協作和軟體品質。
