本文最初發布於 The Startup 博客，經原作者授權由 InfoQ 中文站翻譯並分享。
註：這是本系列文章的第一部分，其他文章會在接下來的幾周內陸續發表。
很多時候，圍繞雲原生的討論會直接進入技術選擇，如容器化和微服務。毫無疑問，這些都是雲原生項目的潛在組成部分，但肯定不是全部。在本系列文章中，我們將從幾個不同的角度探索雲原生，包括技術和基礎設施，還包括架構、設計，以及可能最容易被忽視的人員和流程。用最簡單的術語來說，雲原生不只是說要遷移到雲，而是要充分利用雲基礎設施和服務的獨特性來快速交付業務價值。
雲原生的概念在這個術語投入使用之前就已經存在了。從某種意義上說，雲原生是從公有雲提供商開始提供簡單廉價的彈性計算能力實例開始的。接下來的問題就變成了，你該如何編寫應用程式來利用這種新的基礎設施的靈活性，以及你可以因此獲得什麼業務收益？
在過去的十年中，雲原生方法和技術已經發生了很大的變化，並且仍在不斷發展，但是雲原生應用程式所要實現的核心的技術和業務目標仍然沒有變，這包括：
敏捷性和生產力：支持業務指標指導下的快速創新。降低維護風險並保持環境的持續更新。彈性和可伸縮性：以自修復和無停機時間的持續可用性為目標。提供彈性縮放和容量無限的感覺。優化和效率：優化基礎設施和人力資源成本。可以在不同位置和提供商之間自由遷移。在後續的文章中，當我們回顧雲原生的「為什麼」時，我們將對這些目標進行更細的分解，但即使從這個簡單的定義來看，我們也應該清楚，雲原生並不僅僅是指簡單地遷移到一種新類型的基礎設施，其含義要更廣泛。然而，儘管這些目標很正確，但我們很難看到它們被應用於具體的雲原生環境。我們需要做更多的工作來明確雲原生到底是什麼意思。
一些與雲原生相關的流行的參照標準，比如微服務，以及更早的宣言，比如12要素應用，可能會讓你得出這樣的結論：雲原生是一種架構風格的描述，其他選擇都是遵從這一架構。這當然有一定的道理，雲原生架構確實存在。然而，為了在雲原生應用上取得成功，企業必須有一個更全面的視角。除了架構和基礎設施決策，還有組織和過程決策。這讓我們認識到一個關鍵問題：
技術本身並不能獲得業務成果。
下圖顯示了這些決策之間的相互作用。
技術本身並不能獲得業務成果。
在文章「避免不完全的雲原生」中，我們舉了一個很好的例子，描述了這些方面相互之間是如何連結在一起的，並專門指出了這些連結斷開時會發生什麼。在本系列文章中，我們將探討雲原生的成功與以下三個關鍵領域的協同變革的關係：架構與設計、技術與基礎設施、人員與流程。下面我們將逐項進行討論。
技術與基礎設施：「雲原生」語境下的「雲」是什麼？
十多年前，「雲」這個詞很大程度上指的是位置。通常，它指的是可以通過網際網路訪問的位於他人數據中心裡的基礎設施。然而，如今的「雲」更多的是指如何與那個基礎設施交互。事實上，位置元素已經基本消失了，因為現在常見的是，一個類似雲的設施運行在自己的數據中心裡——「私有雲」，以及混合解決方案（可能會包含跨雲的服務和工作負載）。
所以，如今的雲計算更多的是關於你如何與基礎設施交互，它至少要提供以下內容：
自助配置：可以即時申請新的虛擬資源（伺服器、存儲、網絡）。彈性：根據需求自動調整資源（及相關成本）。自動恢復：資源可按設計在沒有人為幹預的情況下從故障中恢復，將對服務可用性的影響降至最低。然而，隨著雲平臺及概念的成熟，雲原生中的雲實際上還意味著對底層基礎設施的進一步抽象。
不可變部署——例如，基於容器鏡像的部署。聲明式配置——「基礎設施即代碼」提供將來狀態。運行時無關——平臺將組件（例如容器）視為黑盒，不需要理解它們的內容。組件編排——通過通用的聲明式策略和配置賦能管理（監控、伸縮、可用性、路由等）。在雲原生的早期，這些功能通常是高度專有的，但現在，容器以及容器編排功能（如 Kubernetes）似乎已無處不在。像上面這樣的列表是針對容器的，還有其他值得注意的選項，如無伺服器/函數即服務(function As a service)，它們被進一步從基礎設施中抽象出來，而且將來可能會變得更加突出。
我們可能會涉及更多，如構建自動化、服務網格、日誌、跟蹤、分析、軟體定義網絡和存儲等等。因而，屆時我們將進入雲平臺上目前看來更專有的方面。希望隨著時間的推移，這些方面也會變得更加標準化。因此，在這裡，「雲」實際上是指具有上述特性的基礎設施和技術。
架構與設計：「雲原生」裡的「原生」是什麼意思？
我們所說的「原生（native）」是指我們將構建的解決方案不僅僅是「運行在雲上」，而是專門利用了雲平臺的獨特性。應用程式不會魔法般地繼承底層雲基礎設施的優點，我們必須教會它們方法。
我們在語言上要特別小心。當我們使用「原生」來指「雲平臺的獨特性」時，我們並不是指特定雲提供商的特定方面。那將是「雲提供商原生」，實際上，這將完全背離可移植性和使用開放標準的目標。我們指的是，對於所有雲平臺來說在概念上都通用的東西。換句話說，就是我們在上一節中所強調的基礎設施和技術。
這對架構和設計有重要的影響。例如，我們需要確保編寫的解決方案可以水平伸縮，並且可以利用自動恢復機制。在這裡，雲原生可能與微服務概念存在很大的重疊。例如，這包括編寫具有以下特性的組件：
將有狀態性降至最低減少依賴有明確定義的接口輕量級一次性我們將在下一篇文章中更深入地描述它們，但是現在，最重要的是要注意，它們之間存在著高度的依賴關係。例如，如果組件是高度有狀態的，那麼創建一個一次性的組件就會困難很多。本質上，減少依賴關係有助於使組件更加輕量化。定義良好的接口將使得重新綁定一次性組件更容易，諸如此類。這只是一個小例子，是為了說明更廣泛的觀點，即遷移到雲原生方法需要同時在許多相關方面進行變革。我們逐漸發現，這些雲原生要素是相輔相成的。
人員和流程：「雲原生」對我們的組織和工作方式有何影響？
這可能不太明顯，當我們運用上述關於架構和底層基礎設施的假設和決策時，我們就獲得了從根本上改變人員和流程處理方式的機會。事實上，我們可以說，它需要這些改變。
下面我們探討了微服務方法對人員/流程的一些影響：
微服務意味著你將在小型、自治團隊中構建服務。這只是康威定律的簡單應用——如果你希望自己的系統是由解耦的小組件組成，那麼你的團隊也必須很小，並且與其他團隊之間是鬆耦合的——只允許通過定義良好且妥善治理的接口進行正式通信。微服務還意味著你正在使用敏捷方法，並將DevOps原則應用到開發過程中。如果沒有，你會無法獲得端到端的反饋和對代碼的快速迭代，這是該方法的核心優勢。DevOps則意味著進一步的流程改進，如持續集成和持續交付/部署（CI/CD）。DevOps需要你採用其他特定的技術流程，如自動化測試（可能包括測試驅動開發），並引導你走向基於主幹的開發。最小化測試周期的願望可能會進一步引導你探索改變人們工作的方式（例如，結對編程）。同樣，容器技術對所需的技能集、角色和流程也有影響：
通常，雲基礎設施使用通用的雲平臺技能（比如Kubernetes的知識）來實現更多的操作（部署、擴展、高可用性等），而不是特定的運行時或產品技能。這從根本上減少了跨技術領域工作人員的學習曲線，並實現了更廣泛的角色和知識共享，提高了效率，降低了成本。它還鼓勵人們向站點可靠性工程師轉變，儘可能地實現操作任務的自動化。容器，特別是容器鏡像技術簡化了CI/CD管道的自動化，縮短了構建/發布周期，提高了生產率。管道實現方式趨同，意味著它們更容易維護，實際上也更容易被更廣泛的人群所使用。不可變容器鏡像與聲明式「基礎設施即代碼」相結合，提高了跨不同環境部署的一致性，降低了測試和診斷成本，提高了部署速度，並減少了停機時間。從流程的角度來看，這使得可靠性、性能和安全測試等方面的「左移」成為可能。反過來，這也增強了DevOps/DevSecOps文化，使開發人員對代碼的操作質量負起更多的責任。小結：「雲原生」到底意味著什麼？
綜上所述，我們可以看到，雲原生需要從三個不同的方面進行定義。
對基礎設施複雜性進行抽象的平臺。（基礎設施和技術）充分利用基礎架構抽象的解決方案。（架構和設計）開發、操作和業務流程的自動化，以及開發團隊自治性的提升。（人員和流程）如今，技術方面的重點當然是容器化，但重要的是該技術的自助配置、彈性和自動恢復等特性，而不是技術本身。
在架構上，我們最常用的方法是，根據微服務原則來創建更加輕量級、細粒度、狀態最小化的組件，以便可以更好地映射到抽象的基礎設施。如果沒有正確的設計原則，那麼我們的解決方案將無法從平臺中獲益。例如，它不會動態伸縮，或提供細粒度的彈性，或提供快速構建和部署，或與平臺上的其他應用程式保持操作一致性。
通常，人們會認為，人員和流程的變革與雲原生無關，但實際上，它們關係密切，我們將它們視為是特性定義的一部分。缺少軟體開發生命周期的自動化，將意味著團隊要將更多的時間花在日常事務上，而將相對較少的時間花在業務價值上。一個笨重的、自上而下的組織和治理結構將無法提供團隊所需的自主權來幫助他們進行業務創新。
因此，在對雲原生的實際含義有了更具體的定義後，我們就可以進行下一步並擴展前面的圖表了。
在上面的圖表中，我們針對這些方面的關鍵要素列出了一些問題。在本系列的後續文章中，我們將考慮「如何」構建雲原生解決方案，並從人員和流程方面入手詳細研究每個要素。
然而，應該清楚的是，實現完全的雲原生並非易事，並且需要業務支持。因此，在另一篇文章中，我們將對成功實現雲原生所需的投入進行總結，並回過頭來，重新考慮下，你實現微服務的初衷是什麼，以及你希望獲得什麼樣的好處。
感謝
我們要誠摯地感謝 Holly Cummins 和 Callum Jackson，感謝他們對該文章系列的輸入和評論.
原文連結：
What Does Cloud-Native Really Mean?
https://medium.com/swlh/what-does-cloud-native-really-mean-1b10ed003aa9
延伸閱讀：
2021年，不能錯過的十大技術趨勢 | InfoQ特別策劃-InfoQ
關注我並轉發此篇文章，即可獲得學習資料~若想了解更多，也可移步InfoQ官網，獲取InfoQ最新資訊～