[[184803]]

一、云原生定義

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

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

1.云原生的定義

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

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

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

2.云原生的價值

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

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

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

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

1-更高效和更快樂的團(tuán)隊(duì)

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

2-苦逼程度的降低

通過自動化大量的手動的導(dǎo)致痛苦和停機(jī)時間的工作。 這采取自我修復(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-可審計(jì)，可見和可辯

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

5-深度安全

現(xiàn)在許多IT系統(tǒng)都是外強(qiá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)用算法自動化的機(jī)會。 例如，集群調(diào)度器/編排器可以自動化在機(jī)器上的調(diào)度工作，而由運(yùn)維團(tuán)隊(duì)在電子表格中管理類似的分配。

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

二、云原生實(shí)踐

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

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

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

2.沒有固定和速成套路

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

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

云原生由更好的工具和系統(tǒng)來定義的。 沒有這些工具，生產(chǎn)中的每個新服務(wù)的運(yùn)維成本將會居高不下 。必須把監(jiān)控、跟蹤、配置等當(dāng)做一個獨(dú)立的重要的事情。這種開銷是為什么微服務(wù)的規(guī)模應(yīng)該以適當(dāng)?shù)姆绞铰涞氐闹饕蛑弧? 開發(fā)團(tuán)隊(duì)速度的優(yōu)勢必須與在生產(chǎn)中運(yù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)建和運(yùn)行新服務(wù)相關(guān)運(yùn)維成本的關(guān)鍵 。 像Kubernetes、容器、CI/CD、監(jiān)控等系統(tǒng)都具有相同目標(biāo)，即使應(yīng)用程序開發(fā)和運(yùn)維團(tuán)隊(duì)更高效，以便他們能夠更快地推進(jìn)并構(gòu)建更可靠的產(chǎn)品。

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

把***一代的工具和系統(tǒng)更好地搭配，以實(shí)現(xiàn)本地私有云對舊的傳統(tǒng)配置管理工具的需求，因?yàn)樗鼈冇兄谄平鈧鹘y(tǒng)的問題，以便它可以很容易地在團(tuán)隊(duì)里推廣。 較新的工具通常賦予個人開發(fā)者和運(yùn)維團(tuán)隊(duì)以自助服務(wù)的方式獲得更高的生產(chǎn)力

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

三、云原生DevOps

1.文化轉(zhuǎn)型

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

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

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

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

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

3.激勵SRE和開發(fā)團(tuán)隊(duì)的協(xié)作

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

4.SRE受人尊敬

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

5.運(yùn)維專業(yè)化

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

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

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

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

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

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

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

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

每個應(yīng)用程序現(xiàn)在可以有適當(dāng)?shù)膶ｉT的應(yīng)用程序團(tuán)隊(duì)。 如上所述，開發(fā)團(tuán)隊(duì)可以并且應(yīng)該在必要時發(fā)揮這一作用。 這個運(yùn)維團(tuán)隊(duì)希望在應(yīng)用程序上更深入，因?yàn)樗麄儾槐厥瞧渌麑用娴膶＜摇?例如，在Google，AdWords Frontend SRE小組將與AdWords Frontend開發(fā)小組討論，而不是與集群SRE(小組)小組交談。 這種激勵的一致性可以導(dǎo)致更好的結(jié)果。

根據(jù)組織的需要，可能還有其他專門的SRE團(tuán)隊(duì)的存在空間。 例如，存儲服務(wù)可以被分解為具有專業(yè)技能的SRE的單獨(dú)服務(wù)。 或者可能有一個團(tuán)隊(duì)負(fù)責(zé)構(gòu)建和驗(yàn)證所有團(tuán)隊(duì)?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)】