原 生 雲
術語原生雲已成為一種越來越流行的簡化方式，用於談論利用雲，容器和編排的現代應用程序和服務，通常基於開源軟件。實際上，雲計算本地計算基金會（CNCF）成立於2015年，用他們的話說，“圍繞一系列高質量項目建立社區，這些項目將容器作為微服務架構的一部分進行編排。”
作為Linux Foundation的一部分，CNCF旨在將開發人員，最終用戶和供應商（包括主要的公共雲提供商）聚集在一起。 CNCF旗下最着名的項目是Kubernetes本身，但該基金會還孵化和推廣雲原生態系統的其他關鍵組件：普羅米修斯，特使，頭盔，流利，gRPC等等。
那么雲本地人究竟是什么意思呢？像大多數這樣的事情，它對不同的人意味着不同的東西，但也許有一些共同點。
原生雲應用程序在雲中運行;這沒有爭議。但是，僅僅使用現有應用程序並在雲計算實例上運行它並不會使其成為原生雲。它既不是在容器中運行，也不是使用Azure的Cosmos DB或Google的Pub / Sub等雲服務，盡管這些可能是原生雲應用程序的重要方面。讓我們來看看大多數人都同意的雲原生系統的一些特征：
自動化
如果應用程序要由機器而不是人工來部署和管理，則需要遵守通用標准，格式和接口。 Kubernetes提供這些標准接口的方式意味着應用程序開發人員甚至不需要擔心它們。
無處不在，靈活多變，因為它們與磁盤等物理資源分離，或者它們碰巧運行的計算節點的任何特定知曉處，所以容器化微服務可以很容易地從一個節點移動到另一個節點，甚至一個集群移動到另一個節點。
彈性和可擴展性
傳統應用程序往往有單點故障：如果主進程崩潰，或者底層計算機出現硬件故障，或者網絡資源變得擁擠，應用程序將停止工作。雲本機應用程序因其本質上是分布式的，可以通過冗余和優雅降級實現高可用性。
動態
容器協調器（如Kubernetes）可以調度容器以最大限度地利用可用資源。它可以運行它們的許多副本以實現高可用性，並執行滾動更新以平滑地升級服務，而不會丟失流量。
可觀察
雲本機應用程序本質上更難以檢查和調試。因此，分布式系統的一個關鍵要求是可觀察性：監控，日志記錄，跟蹤和指標都可以幫助工程師了解他們的系統正在做什么（以及他們做錯了什么）。
分散式
Cloud native（原生雲）是一種構建和運行應用程序的方法，它利用了雲的分布式和分散式特性。它是關於您的應用程序如何工作，而不是它運行的位置。雲本機應用程序往往由多個協作的分布式微服務組成，而不是將您的代碼部署為單個實體（稱為整體）。微服務只是一個獨立的服務，只做一件事。如果你把足夠的微服務放在一起，你會得到一個應用程序。
它不僅僅是微服務
微服務並不是靈丹妙葯。 Monoliths更容易理解，因為一切都在一個地方，你可以追蹤不同部分的相互作用。但是，就代碼本身和維護代碼本身的開發團隊來說，很難擴展monoliths。隨着代碼的增長，其各個部分之間的交互呈指數級增長，整個系統的增長超出了單個大腦的能力來理解它。
精心設計的雲本機應用程序由微服務組成，但決定這些微服務應該是什么，邊界在哪里，以及不同服務應該如何交互也不是一件容易的事。良好的雲原生服務設計包括明智地選擇如何分離架構的不同部分。然而，即使是設計良好的原生雲應用程序仍然是一個分布式系統，這使得它本身就很復雜，難以觀察和推理，並且以令人驚訝的方式容易出現故障。
雖然雲本機系統往往是分布式的，但仍然可以使用容器在雲中運行單一應用程序，並從中獲得可觀的商業價值。這可能是逐步將整體部件向外遷移到現代微服務的道路上的一步，或者是在將系統重新設計為完全雲原生之前的權宜之計。
運營的未來
運營，基礎設施工程和系統管理是高技能的工作。他們是否在雲原生未來面臨風險？我們不這么認為。相反，這些技能只會變得更加重要。分布式系統的設計和推理很難。網絡和容器協調器很復雜。開發原生雲應用程序的每個團隊都需要操作技能和知識。自動化使員工免於枯燥，重復的手工工作，以處理計算機無法自行解決的更復雜，有趣的問題。
這並不意味着所有當前的運營工作都得到保證。系統管理員曾經能夠在沒有編碼技能的情況下順利通過，除了可能編寫奇怪的簡單shell腳本。在雲中，那不會飛。
在軟件定義的世界中，編寫，理解和維護軟件的能力變得至關重要。如果你不能或不會學習新技能，世界將會讓你落后 - 而且一直都是這樣。
分布式DevOps
不是集中在為其他團隊提供服務的單一運營團隊中，運營專業知識將分散在許多團隊中。
每個開發團隊至少需要一名操作專家，負責團隊提供的系統或服務的運行狀況。她也將成為開發人員，但她也將成為網絡，Kubernetes，性能，彈性以及使其他開發人員能夠將其代碼交付給雲的工具和系統領域專家。
由於DevOps革命，大多數組織不再擁有無法操作的開發人員或不開發的操作員。這兩個學科之間的區別是過時的，並且正在迅速被完全抹去。開發和運行軟件只是同一件事的兩個方面。
有些事情會保持集中
DevOps有限制嗎？或者傳統的中央IT和運營團隊是否會完全消失，融入一群流動的內部顧問，指導，教學和解決操作問題？
我認為不是，或者至少不完全。有些事情仍然受益於集中化。每個應用程序或服務團隊都有自己的方式來檢測和傳達生產事件，例如，或者自己的票務系統或部署工具，這是沒有意義的。每個人重新發明自己的輪子都沒有意義。
開發人員生產力工程
關鍵在於自助服務有其局限性，DevOps的目標是加速開發團隊，而不是通過不必要的冗余工作來減緩他們的速度。是的，傳統操作的很大一部分可以而且應該轉移到其他團隊，主要是那些涉及代碼部署和響應代碼相關事件的團隊。但要實現這一目標，需要建立一個強大的中央團隊並支持所有其他團隊運營的DevOps生態系統。
開發人員生產力工程（DPE）。 DPE團隊竭盡所能幫助開發人員更好，更快地完成工作：運營基礎架構，構建工具，解決問題。
雖然開發人員生產力工程仍然是一項專業技能，但工程師本身可能會向外部進入組織，以便在需要的地方提供專業知識。
Lyft工程師Matt Klein建議，雖然純粹的DevOps模型對初創公司和小公司有意義，但隨着組織的發展，基礎架構和可靠性專家自然傾向於吸引中央團隊。但他說團隊無法無限期縮放：
當一個工程組織達到約75人時，幾乎可以肯定有一個中央基礎設施團隊開始構建產品團隊構建微服務所需的共同基板功能。但有一點，中央基礎架構團隊不再能夠繼續構建和運營對業務成功至關重要的基礎架構，同時還要保持幫助產品團隊完成運營任務的支持負擔。
此時，並非每個開發人員都可以成為基礎架構專家，就像單個基礎架構專家團隊無法為越來越多的開發人員提供服務一樣。對於大型組織，雖然仍然需要中央基礎架構團隊，但還有一個案例是將站點可靠性工程師（SRE）嵌入到每個開發或產品團隊中。他們將自己的專業知識作為顧問帶到每個團隊，並在產品開發和基礎設施運營之間架起橋梁。
你是未來
如果您正在閱讀，那就意味着您將成為這個新的原生雲未來的一部分。我們將介紹作為使用雲基礎架構，容器和Kubernetes的開發人員或操作工程師所需的所有知識和技能。
其中一些將是熟悉的，一些將是新的，但我們希望，當你完成這本書后，你會對自己獲得和掌握雲本地技能的能力更有信心。是的，有很多東西需要學習，但這是你無法處理的。
摘要
必定會讓您快速瀏覽一下原生雲DevOps環境，期待它足以讓您快速了解雲，容器和Kubernetes解決的一些問題，以及它們可能會如何變化IT業務。如果您已經熟悉這一點，那么我們感謝您的耐心等待。
快速回顧一下要點：
雲計算使您免於管理自己的硬件費用和開銷，使您可以構建彈性，靈活，可擴展的分布式系統。
DevOps認識到現代軟件開發並不止於發布代碼：它是關閉編寫代碼的人和使用代碼的人之間的反饋循環。
DevOps還為基礎架構和運營領域帶來了以代碼為中心的方法和良好的軟件工程實踐。
容器允許您在小型，標准化，獨立的單元中部署和運行軟件。通過將容器化的微服務連接在一起，這使得構建大型，多樣化的分布式系統變得更容易和更便宜。
業務流程系統負責部署容器，調度，擴展，網絡以及優秀系統管理員可以執行的所有操作，但是采用自動化，可編程的方式。
Kubernetes是事實上的標准容器編排系統，現在可以立即用於生產。
Cloud native是一個有用的簡寫，用於討論基於雲的容器化分布式系統，這些系統由協作的微服務組成，由自動化基礎架構作為代碼動態管理。
運營和基礎設施技能遠非被雲本土革命淘汰，而且將變得比以往任何時候都更加重要。
對於中央團隊而言，構建和維護使所有其他團隊都能使用DevOps的平台和工具仍然是有意義的。
將消失的是軟件工程師和運營工程師之間的明顯區別。它現在只是軟件，我們都是工程師。