構建、運行和營運推動創新的現代應用程式。專注於程式碼而不用擔心基礎設施和安全性。
據Forrester 的一份報告，今年全球雲端運算市場預計將超過1200 億美元。推動這種持續增長和採用的是基礎設施、軟體、網絡和應用技術方面的各種範式轉變。其中最主要的是雲端原生計算。
「雲端原生」是指架構和技術的最佳組合，能夠充分利用雲端運算模型，在雲中設計、開發和運行工作負載。
事實上，有一個完整的開源軟體機構——雲端原生計算基金會（CNCF）——致力於使雲端原生具有普遍性和可持續性。它目前監督近 150,000 名 IT 專業人員對 100 多個項目和平台的貢獻。以下是CNCF對雲端原生應用程式的評價：
「雲端原生技術使組織能夠在現代、動態環境（例如公共雲、私有雲和混合雲）中構建和運行可擴展的應用程式。容器、服務網格、微服務、不可變基礎設施和聲明性 API 就是這種方法的例證。這些技術支持鬆散的系統。」
這個定義反映了 IT 不斷變化的面貌。從傳統的對流程和自動化的關注，IT 現在是業務產品的代表。雲應用程式已將 IT 從一項功能轉變為業務本身。
難怪全球有超過 650 萬雲開發人員為每一種可以想像的業務工作負載構建雲端原生應用程式。這些在擴展時將與技術無關，基於DevOps 等最佳實踐，使用方法交付，可部署到多個雲平台，同時不易受供應商鎖定的影響，即使速度更快，也不易出現「快速修復」的副作用發布週期。
但是，在組織完全接受雲端原生應用程式開發之前，需要牢記許多組件和架構注意事項。
由於雲本身對不同的人意味著不同的事物，因此組織需要定義並堅持某些編碼基礎、最佳實踐和流程，以實現其應用程式開發和交付目標。
Moore Insights & Strategy 的Steve McDowell 說：「當人們說他們想要雲時，他們真正想要的是能夠靈活部署資源並根據需要重新配置它們，雲端原生是關於打包、管理和運行對其環境敏感的工作負載。」
正確掌握雲端原生應用程式開發的所有核心要素（基礎設施、平台、軟體和服務）對於提供流暢、現代的用戶體驗至關重要。讓我們一一檢查它們，看看它們如何結合起來將雲端原生應用程式投入生產並啟用各種業務計劃。
微服務
微服務架構（由 Netflix 首創）用多個單獨構建的功能模塊取代了傳統應用程式的單一、單體可執行文件。這是部署模型的根本變化，並大大減少了用於集成、測試和發布的時間和精力。
微服務的基本屬性是：
- 獨立構建和部署
- 在工作負載中啟用特定功能
- 封裝自成，擁有自己的編程平台、依賴、流程和數據儲存框架
- 使用 API 與其他微服務溝通
由於每個微服務都是獨立運行的，它不會影響應用程式的其他移動部分——除了正在更改的微服務的代碼之外，不需要更新任何其他代碼。這可以更快地推出，並使持續集成/持續交付 (CI/CD)成為現實（與傳統的定時發布和版本控制流程相反）。
基於微服務的架構還簡化了故障排除和隔離調試、修改和更新。例如，工作負載（如視頻流）的一個特性或功能存在錯誤或面臨使用高峰，開發人員可以改進或擴展該功能，而無需重做整個可執行文件，並且資源配置有限且精確。
同樣，如果一個功能或特性變得更大、更笨重，它可以被分割或分割成更細粒度的微服務。這會降低複雜性並簡化應用程式監控和管理。
應用程式介面 (API)
組成雲端原生應用程式的微服務需要一種內在機制來相互通信——發送和接收數據、元資料(Meta data)和服務請求。此外，面向客戶端的微服務需要接受和回應來自不同設備、瀏覽器和其他 Web/移動客戶端以及 UI 的用戶請求。
RESTful API 是管理雲端原生應用程式中微服務之間通信的首選接口。它們被其他服務「調用」（可能駐留在同一台服務器上或跨互聯網）使用標準協議，如 HTTPS、WebSockets、gRPC、AMQP 等。
開發人員需要實現以下技術：
- 當他們向微服務添加需要或接受其他參數的新函數時，版本控制以更新 API 格式
- 監控、數據緩存、節流和斷路器，以確保服務不會因使用高峰或 DDoS 攻擊而被過多的 API 調用淹沒。
容器
容器是支持雲端原生應用程式開發的架構的基本部分。它們為虛擬機提供了一種更快、更輕（資源密集度低得多）的替代方案，作為部署單個微服務的計算平台。
在混合和多雲環境時代，容器保證了一致性並增加了跨不同雲系統的應用程式可移植性。Karbon – Nutanix 的企業 Kubernetes 管理解決方案 – 是一種多雲 PaaS，可加速本地、公共雲和邊緣雲端原生應用程式的開發和部署。
支持服務 (Backing Services)
沒有軟體是孤立地開發的，尤其是雲端原生應用程式。需要大量支持系統和資源，例如身份和監控服務、跟踪和分析服務、數據儲存、消息和隊列系統、緩存服務等，才能使應用程式架構雲就緒。
開發人員可以選擇託管自己的支持服務或從雲提供商處獲取託管服務，這些服務具有內置的可用性、冗餘和監控功能。
支持服務可以通過配置信息（URI 和憑據）動態綁定到微服務。這樣，後備服務充當附加資源，但同時與應用程式解耦，使其可互換。
通過使用配置管理工具將配置信息外部化，支持服務可以附加到微服務或從微服務分離，而無需更改代碼。
現代設計
微服務、API 和容器的組合當然不是應對雲中應用程式開發挑戰的靈丹妙藥。IT 團隊需要開發適合他們現有的雲模型和 IT 基礎架構的定制應用程式監控和管理方法。
Nutanix 產品營銷總監 Sean Roth 強調了 DevOps 在使 IT 團隊和軟體開發人員能夠共同構建和部署現代雲原生應用程式方面的作用。
Roth 說 ：「在許多情況下，開發人員在他們的應用程式和 IT 營運方面都在努力滿足他們的資源需求，DevOps 以及與之相伴的心態，在一定程度上緩解了這一障礙。」
Nutanix 的 DevOps 倡導者Mark Lavi 表示： 「傳統瀑布方法的特點是開發人員和 IT 營運之間存在嚴重脫節，開發週期可能長達數年。雲端原生通過利用雲端運算模型的可擴展性和自動化特性，並將它們與新的 DevOps 實踐相結合，消除了許多這些負擔，這有助於使開發與業務目標保持一致。」
其中一些做法是：
- 採用十二因素方法，通過最大限度地提高可移植性、消除對伺服器管理的需求、增強各種平台和環境之間的超融合、允許工作負載擴展而無需對架構進行重大更改以及實現持續部署，使應用程式適合部署在雲平台上
- 了解何時從頭開始開發新的雲端原生應用程式，何時（以及如何）對現有應用程式進行現代化、重構、擴展或容器化，以及何時購買現成或定制的解決方案來擴展現有工作流程，同時利用雲端
- 將數據與應用程式分離（將處理和數據分解為單獨的組件）並將其儲存在適當的公共、私有或混合雲中
- 通過將應用程式組件分組到預定流而不是連續或按需傳輸來優化應用程式組件之間的通信
- 統一和集中的性能監控以及根據工作負載需求自動配置和取消配置資源實例
- 開發人員和 IT 安全團隊共同承擔責任的 DevSecOps 安全方法；應用程式架構中內置系統性雲端原生安全性，使其能夠使用零信任模型利用身份和訪問管理 (IAM)
- 在整個堆棧和應用程式容器中構建可觀察性以及集中式日誌記錄、監控和持久儲存，以確保對應用程式的所有組件及其處理的數據進行全面和按需可見性
- 自動化的、開發人員驅動的功能測試，讓 QA 團隊能夠專注於集成測試、客戶端測試和性能/負載測試
有一種雲
一直以來，組織一直在努力將其應用程式開發工作與其業務目標相匹配。這可能是雲端原生技術提供最大價值的地方——它通過將基礎設施商品化並為開發人員提供按需 PaaS 體驗，幾乎實現了整個軟體開發生命週期的自動化。
McDowell 解釋道：「如果過去一、兩年教會了我們什麼，那就是您需要能夠根據世界上正在發生的事情動態重新配置您的 IT 環境。使用傳統基礎架構的公司才是真正陷入困境的公司。如果你不採用雲端原生，它不會讓你的公司倒閉，但它會讓你成為行業中的落後者。它現在是我們提供回應式 IT 服務的方式。」
