[[184803]]

一、云原生定義

云原生定義隨著Craig和我開始構建Heptio的旅程，我們一直在思考我們看到的行業。我們花了相當多的時間在Google(我們兩個人之間的16年)，并且很好地了解Google如何構建和管理系統的。 但是，你不能在Google工作。 那么，所有這些不斷發展的新概念如何能應用到傳統的公司/開發商/運營商?

這是一個‘云原生系列文章’的***部分，闡述如思考和應用“云原生”思想的多個角度。

1.云原生的定義

對于 Cloud Native 意味著什么，還不能生硬和快速地對其下定義 。 事實上，還有其他重疊的術語和意識形態。 Cloud Native作為正在構建團隊，文化和技術的根本，以利用自動化和架構來管理復雜性和加快步伐。 在這種模式下運維需要盡可能多的擴展人的方面，同時盡可能多的擴展技術方面。

“Cloud Native作為正在構建團隊、文化和技術的根本，以利用自動化和架構來管理復雜性和加快步伐。”

一個重要的注意事項： 你不一定只能在云中運用“云原生” 。 這些技術可以適當地逐步應用，來幫助您順利地轉型到云。

2.云原生的價值

Cloud Native的真正價值遠遠超出了與其密切相關的一攬子技術。 為了真正了解我們行業的發展方向，我們需要審視我們在哪里和如何使公司、團隊和員工更加成功。

有些技術在這一點上已經在以技術為中心的前瞻性公司中得到證明，這些公司已經投入了大量的資源。 想想Google或Netflix或Facebook。 更小，更靈活的公司也在這里實現價值。 然而，這一理念在技術早期采用者之外應用的例子很少。 當放眼更廣闊的IT世界，我們仍然在這個旅程的開始階段。

“我們才剛剛開始云原生的旅程。”

隨著一些早期的經驗被證明和共享，那些主題正在出現?

1-更高效和更快樂的團隊

云原生工具允許將大問題分解為更小的部分，用于更專注和靈活的團隊。

2-苦逼程度的降低

通過自動化大量的手動的導致痛苦和停機時間的工作。 這采取自我修復和自我管理基礎設施的形式。 期望系統做更多。

3-更可靠的基礎設施和應用

構建自動化來應對那些可以預期的通常會導致意外事件和故障，更好的故障處理模式。 示例：如果是單個命令或按鈕單擊以部署用于開發，測試或生產的應用程序，則可以更容易地在災難恢復方案(自動或手動)中自動部署。

4-可審計，可見和可辯

復雜的應用可能非常不透明。 用于Cloud Native應用程序的工具根據需要通常可以更好地了解應用程序中發生的情況。

5-深度安全

現在許多IT系統都是外強中干的。 現代系統應該是默認的安全和最小的信任。 Cloud Native使應用程序開發人員能夠在創建安全的應用程序中發揮積極作用。

6-更有效地利用資源

自動化的“類云”部署和管理應用程序和服務的方式開辟了應用算法自動化的機會。 例如，集群調度器/編排器可以自動化在機器上的調度工作，而由運維團隊在電子表格中管理類似的分配。

我們在Heptio非常高興能夠幫助將Cloud Native的優勢帶給更廣泛的IT行業。 在本系列的其余部分，我們將討論與現有系統，DevOps，容器和編排，微服務和安全性的集成。 請留意，讓我們知道您最感興趣的是什么。

二、云原生實踐

1.因地制宜，循序漸進

像其它創新活躍的領域一樣，云原生世界有相當多的流派。 如何能夠把上一章里的優秀的想法，都***的實現出來并不是能輕易地說清楚。 為此把任何重大的項目重寫都顯得動作太大太夸張了。相反，我鼓勵您對較新的項目或現有項目的新部件嘗試這些新結構。 隨著系統的老組件的改進，花時間適當地引入新技術和學習。 尋找方法來把新功能或系統實施為微服務。

“如何能夠把上一章里的優秀的想法，都***的實現出來并不是能輕易地說清楚。”

2.沒有固定和速成套路

每個組織都是不同的，新軟件開發實踐必須推廣到現有的團隊和項目。 破除團隊的割據。 一些項目可以進行實驗，而其他關鍵核心業務項目應該更加地謹慎地靠攏和學習。 在這個過程中，也有新技術需要在被應用于到關鍵系統之前進行規模化和測試的必要性的情況。

3.云原生由優秀工具和系統定義

云原生由更好的工具和系統來定義的。 沒有這些工具，生產中的每個新服務的運維成本將會居高不下 。必須把監控、跟蹤、配置等當做一個獨立的重要的事情。這種開銷是為什么微服務的規模應該以適當的方式落地的主要原因之一。 開發團隊速度的優勢必須與在生產中運行更多服務的成本進行權衡 。同樣，引入新技術和語言令人興奮的同時，也具有成本和風險，必須認真加以權衡。 Charity Majors對此有一個偉大的談話，網址：

https://www.oreilly.com/ideas/a-young-ladys-illustrated-primer-to-technical-decision-making 。

4.自動化是關鍵

自動化是降低與構建和運行新服務相關運維成本的關鍵 。 像Kubernetes、容器、CI/CD、監控等系統都具有相同目標，即使應用程序開發和運維團隊更高效，以便他們能夠更快地推進并構建更可靠的產品。

5.自服務引爆效率

把***一代的工具和系統更好地搭配，以實現本地私有云對舊的傳統配置管理工具的需求，因為它們有助于破解傳統的問題，以便它可以很容易地在團隊里推廣。 較新的工具通常賦予個人開發者和運維團隊以自助服務的方式獲得更高的生產力

接下來的第3部分 ，我們將看看Cloud Native如何與DevOps相關。 我們還要了解一下Google如何通過SRE角色實現這一點。

三、云原生DevOps

1.文化轉型

將DevOps視為文化轉型可能是最有用的，開發人員必須關心他們的應用程序如何在生產環境中運行。 此外，運維人員知道并有權知道應用程序如何工作，以便他們可以主動發揮作用，使應用程序更可靠。 在這些團隊之間建立理解和同情是關鍵。

但這可以進一步。如果我們重新審視應用程序的構建方式和運維團隊的結構，我們可以改進和深化這種關系。

2.網站可靠性工程師

Google不使用傳統運維團隊。 Google反而定義了一種稱為“網站可靠性工程師”的新型工程師 。 這些是受過高度訓練的工程師(在與其他工程師相同的水平得到補償)，不僅攜帶尋呼機，而且希望和有能力在通過自動化推動應用程序更可靠的過程中發揮關鍵作用。

“第二天早上10點所發生的定義了SRE。”

3.激勵SRE和開發團隊的協作

當尋呼機在凌晨2點鐘關閉時，任何人對尋呼機都做著同樣的事情 - 試圖找出發生了什么，以便他/她可以回去睡覺。 第二天早上10點所發生的定義了SRE。 做運維的人只是抱怨或者和開發團隊一起合作保證尋呼機上出現的事情不在發生了就夠了么? SRE和開發團隊有使產品盡可能可靠的激勵。 這與無指責的事故分析結合，可以促成沒有技術債務的健康項目。

4.SRE受人尊敬

SRE是Google里最受尊敬的人之一。 事實上，通常產品的發布并不需要SRE，而是期望開發團隊在生產環境中運行他們的產品 。引入SRE的過程通常涉及開發團隊向SRE團隊證明該產品已準備就緒。 預計開發團隊將完成所有的基礎的工作，包括設置監控和警報，警報觸發的工作流和發布流程。 開發團隊應該能夠使尋呼機收到最少的報警，大多數問題已經被自動化。

5.運維專業化

由于運維的角色變得更加復雜和特定于應用程序，因此對于單個團隊擁有整個運維堆棧沒有什么意義。 這導致了運維專業化的想法。在某些方面，這是一種“反奴役”。 讓我們從下到上。

運維專業化    硬件運維

這已經是明顯可分離的。 事實上，很容易將IaaS云看作“硬件運維即服務”。

運維專業化   操作系統運維

有人必須確保機器啟動，并有一個好的內核。 從應用程序依賴性管理中突破這一點反映了集中在托管容器( CoreOS ， Red Hat Project Atomic ， Ubuntu Snappy ， Rancher OS ， VMWare Photon ， Google Container Optimized OS )上的最小操作系統發布趨勢。

運維專業化   集群運維

在容器化的世界中，計算集群成為一個邏輯基礎架構平臺。 集群系統(Kubernetes)提供了一組原子操作，使許多傳統運維任務能夠自我服務。

運維專業化    應用運維

每個應用程序現在可以有適當的專門的應用程序團隊。 如上所述，開發團隊可以并且應該在必要時發揮這一作用。 這個運維團隊希望在應用程序上更深入，因為他們不必是其他層面的專家。 例如，在Google，AdWords Frontend SRE小組將與AdWords Frontend開發小組討論，而不是與集群SRE(小組)小組交談。 這種激勵的一致性可以導致更好的結果。

根據組織的需要，可能還有其他專門的SRE團隊的存在空間。 例如，存儲服務可以被分解為具有專業技能的SRE的單獨服務。 或者可能有一個團隊負責構建和驗證所有團隊應根據政策使用的基本容器映像。

原文鏈接:https://blog.heptio.com/cloud-native-part-3-6f9d888c5f07#.seyinvei7

作者:Joe Beda

【本文為51CTO專欄作者“劉征”的原創稿件，轉載請通過作者微信公眾號“DevOps教練”（MyDevOps）獲取授權】