雲的革命（三）原生雲

 原 生 雲

     術語原生雲已成爲一種愈來愈流行的簡化方式，用於談論利用雲，容器和編排的現代應用程序和服務，一般基於開源軟件。實際上，雲計算本地計算基金會（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的平臺和工具仍然是有意義的。

    將消失的是軟件工程師和運營工程師之間的明顯區別。它如今只是軟件，咱們都是工程師。