[[184803]]

一、云原生定義

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

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

1.云原生的定義

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

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

一個重要的注意事項： 你不一定只能在云中運用“云原生” 。 這些技術(shù)可以適當(dāng)?shù)刂鸩綉?yīng)用，來幫助您順利地轉(zhuǎn)型到云。

2.云原生的價值

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

有些技術(shù)在這一點上已經(jīng)在以技術(shù)為中心的前瞻性公司中得到證明，這些公司已經(jīng)投入了大量的資源。 想想Google或Netflix或Facebook。 更小，更靈活的公司也在這里實現(xiàn)價值。 然而，這一理念在技術(shù)早期采用者之外應(yīng)用的例子很少。 當(dāng)放眼更廣闊的IT世界，我們?nèi)匀辉谶@個旅程的開始階段。

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

隨著一些早期的經(jīng)驗被證明和共享，那些主題正在出現(xiàn)?

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

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

2-苦逼程度的降低

通過自動化大量的手動的導(dǎo)致痛苦和停機時間的工作。 這采取自我修復(fù)和自我管理基礎(chǔ)設(shè)施的形式。 期望系統(tǒng)做更多。

3-更可靠的基礎(chǔ)設(shè)施和應(yīng)用

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

4-可審計，可見和可辯

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

5-深度安全

現(xiàn)在許多IT系統(tǒng)都是外強中干的。 現(xiàn)代系統(tǒng)應(yīng)該是默認(rèn)的安全和最小的信任。 Cloud Native使應(yīng)用程序開發(fā)人員能夠在創(chuàng)建安全的應(yīng)用程序中發(fā)揮積極作用。

6-更有效地利用資源

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

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

二、云原生實踐

1.因地制宜，循序漸進(jìn)

像其它創(chuàng)新活躍的領(lǐng)域一樣，云原生世界有相當(dāng)多的流派。 如何能夠把上一章里的優(yōu)秀的想法，都***的實現(xiàn)出來并不是能輕易地說清楚。 為此把任何重大的項目重寫都顯得動作太大太夸張了。相反，我鼓勵您對較新的項目或現(xiàn)有項目的新部件嘗試這些新結(jié)構(gòu)。 隨著系統(tǒng)的老組件的改進(jìn)，花時間適當(dāng)?shù)匾胄录夹g(shù)和學(xué)習(xí)。 尋找方法來把新功能或系統(tǒng)實施為微服務(wù)。

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

2.沒有固定和速成套路

每個組織都是不同的，新軟件開發(fā)實踐必須推廣到現(xiàn)有的團隊和項目。 破除團隊的割據(jù)。 一些項目可以進(jìn)行實驗，而其他關(guān)鍵核心業(yè)務(wù)項目應(yīng)該更加地謹(jǐn)慎地靠攏和學(xué)習(xí)。 在這個過程中，也有新技術(shù)需要在被應(yīng)用于到關(guān)鍵系統(tǒng)之前進(jìn)行規(guī)?；蜏y試的必要性的情況。

3.云原生由優(yōu)秀工具和系統(tǒng)定義

云原生由更好的工具和系統(tǒng)來定義的。 沒有這些工具，生產(chǎn)中的每個新服務(wù)的運維成本將會居高不下 。必須把監(jiān)控、跟蹤、配置等當(dāng)做一個獨立的重要的事情。這種開銷是為什么微服務(wù)的規(guī)模應(yīng)該以適當(dāng)?shù)姆绞铰涞氐闹饕蛑弧? 開發(fā)團隊速度的優(yōu)勢必須與在生產(chǎn)中運行更多服務(wù)的成本進(jìn)行權(quán)衡 。同樣，引入新技術(shù)和語言令人興奮的同時，也具有成本和風(fēng)險，必須認(rèn)真加以權(quán)衡。 Charity Majors對此有一個偉大的談話，網(wǎng)址：

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

4.自動化是關(guān)鍵

自動化是降低與構(gòu)建和運行新服務(wù)相關(guān)運維成本的關(guān)鍵 。 像Kubernetes、容器、CI/CD、監(jiān)控等系統(tǒng)都具有相同目標(biāo)，即使應(yīng)用程序開發(fā)和運維團隊更高效，以便他們能夠更快地推進(jìn)并構(gòu)建更可靠的產(chǎn)品。

5.自服務(wù)引爆效率

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

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

三、云原生DevOps

1.文化轉(zhuǎn)型

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

但這可以進(jìn)一步。如果我們重新審視應(yīng)用程序的構(gòu)建方式和運維團隊的結(jié)構(gòu)，我們可以改進(jìn)和深化這種關(guān)系。

2.網(wǎng)站可靠性工程師

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

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

3.激勵SRE和開發(fā)團隊的協(xié)作

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

4.SRE受人尊敬

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

5.運維專業(yè)化

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

運維專業(yè)化    硬件運維

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

運維專業(yè)化   操作系統(tǒng)運維

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

運維專業(yè)化   集群運維

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

運維專業(yè)化    應(yīng)用運維

每個應(yīng)用程序現(xiàn)在可以有適當(dāng)?shù)膶ｉT的應(yīng)用程序團隊。 如上所述，開發(fā)團隊可以并且應(yīng)該在必要時發(fā)揮這一作用。 這個運維團隊希望在應(yīng)用程序上更深入，因為他們不必是其他層面的專家。 例如，在Google，AdWords Frontend SRE小組將與AdWords Frontend開發(fā)小組討論，而不是與集群SRE(小組)小組交談。 這種激勵的一致性可以導(dǎo)致更好的結(jié)果。

根據(jù)組織的需要，可能還有其他專門的SRE團隊的存在空間。 例如，存儲服務(wù)可以被分解為具有專業(yè)技能的SRE的單獨服務(wù)。 或者可能有一個團隊負(fù)責(zé)構(gòu)建和驗證所有團隊?wèi)?yīng)根據(jù)政策使用的基本容器映像。

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

作者:Joe Beda

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