建站
咨詢
售后
建站咨詢
新聞中心
云原生、DevOps和平臺工程都是十分繁雜的概念，其邊界不斷延伸，有許多重合的部分。三者的出發(fā)點卻并不相同，卻可以形成有機的整體。
創(chuàng)新互聯(lián)是專業(yè)的平潭網(wǎng)站建設公司，平潭接單;提供成都做網(wǎng)站、成都網(wǎng)站設計,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行平潭網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!
云原生
云原生基金會關(guān)于云原生的定義如下：
云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中，構(gòu)建和運行可彈性擴展的應用。云原生的代表技術(shù)包括容器、服務網(wǎng)格、微服務、不可變基礎設施和聲明式API。
這些技術(shù)能夠構(gòu)建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動化手段，云原生技術(shù)使工程師能夠輕松地對系統(tǒng)作出頻繁和可預測的重大變更。
可以看到云原生的目的是“夠構(gòu)建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)”，而采用的方法包括“容器、服務網(wǎng)格、微服務、不可變基礎設施和聲明式API”，而這一些還有個前提，需要是在“在公有云、私有云和混合云等新型動態(tài)環(huán)境中”。
這不像一個定義，倒是像一個“萬能”盒子，似乎可以容納任何“正確的”方法。不過這個定義與實際情況匹配，開發(fā)與運維面對的問題很多，并沒有單一方法來解決。人們在實踐中可能發(fā)現(xiàn)某個工具很好用，然后漸漸發(fā)現(xiàn)其背后的思想是成功的關(guān)鍵，于是這個思想被挖掘出來成為一種方法論，然后衍生出更多的工具。一個很棒的例子就是 Kubernetes 的聲明式 API，以及其實現(xiàn)方式 Operator，許許多多的工具，都借用了這個思想，實現(xiàn)了自己的 Operator，共同組成了了一個松耦合的復雜的系統(tǒng)。這些方法最后成為了云原生的一個方法。
可以看出來，“云原生”只是告訴你這有一套方法很好。工具提供者可以用這個方法開發(fā)工具，最終用戶應該用云原生的工具。但是基于這個思想的工具太多了，該如何選擇組合成了一個大問題，所以云原生基金會給大家展示了這樣一個圖景：
圖片
可怕，所以做好云原生的一個關(guān)鍵問題是如何選好工具，這就要求 CTO 和架構(gòu)師需要持續(xù)關(guān)注云原生解決方案，需要更多的同行溝通，這也是為什么我們的公眾號“云云眾生s”為什么要一直給大家介紹一些工具。
不過，任何事情想做好，都不僅僅是技術(shù)的問題，許多云原生踐行者，尤其是在傳統(tǒng)企業(yè)實踐的同僚一定對此深有體會。云原生聚焦于技術(shù)，并沒有太多的意識形態(tài)因素，但不知不覺中技術(shù)改變了人的協(xié)作關(guān)系，由此引發(fā)的問題需要有別的方法來解決。
DevOps
與云原生相比，DevOps 有著眾多存在差異的定義，先看看 Atlassian 的定義：
DevOps 是一套實踐、工具和文化理念，可以實現(xiàn)軟件開發(fā)團隊和 IT 團隊之間的流程自動化和集成。它強調(diào)團隊賦能、跨團隊溝通和協(xié)作以及技術(shù)自動化。
DevOps 運動始于 2007 年左右，當時軟件開發(fā)和 IT 運營社區(qū)開始擔憂傳統(tǒng)的軟件開發(fā)模式。在此模式下，編寫代碼的開發(fā)人員與部署和支持代碼的運營人員會獨立工作。DevOps 這一術(shù)語由“開發(fā)”和“運營”兩個詞構(gòu)成，它反映了將這些領(lǐng)域整合為一個持續(xù)流程的過程。
可以看到，相對于云原生比較關(guān)注方法和工具，DevOps 包含了“實踐、工具和文化理念”三個方面，但是其突出的價值觀是什么，可以從其起源追溯。Atlassian 在DevOps 歷史中寫到：
盡管敏捷開發(fā)方法已興起，但多年來，開發(fā)團隊和運營團隊仍然處于孤立狀態(tài)。DevOps 是協(xié)作工具和實踐的進一步發(fā)展，以更快速地發(fā)布更優(yōu)質(zhì)的軟件。
關(guān)于 DevOps 的起源，馬丁·福勒的Bliki中有以下描述：
Agile software development has broken down some of the silos between requirements analysis, testing and development. Deployment, operations and maintenance are other activities which have suffered a similar separation from the rest of the software development process. The DevOps movement is aimed at removing these silos and encouraging collaboration between development and operations.
按照此文的說法，DevOps 解決的問題是“敏捷開發(fā)”的不同角色的豎井問題，而不僅僅是運維和開發(fā)兩個組織的溝通協(xié)調(diào)問題。此外，”敏捷開發(fā)“這個詞也隱含的說明 DevOps 的前提是敏捷開發(fā)，即使不是，也可能如 ThoughtWorks 網(wǎng)站上所提到的需要考量這些因素：
而且，DevOps 并不是打從一開始就適合每個組織——組織可能必須要做出一些改變。應時刻將康威定律銘記于心——這是一句格言，指出組織所設計的系統(tǒng)反映了組織自身的溝通結(jié)構(gòu)。這意味著，如果您使用一個大型單體應用程序來運行絕大多數(shù)業(yè)務關(guān)鍵應用程序，那么 DevOps 可能不適合您的組織。DevOps 最適合那些能夠?qū)⒐ぷ鞣纸獬梢粋€團隊可以擁有的若干離散小塊的組織。
確實如此，并不是每個組織都能開展 DevOps。一個組織的部門墻越高，越難以實施 DevOps。
盡管不同的組織對于 DevOps 的定義有許多差異，但從前面的描述中，我們也能發(fā)現(xiàn) DevOps 是敏捷開發(fā)的延伸。較早采用 DevOps 的組織本身的部門墻不高，開發(fā)人員的眼界和能力都比較好，所以能夠快速的吸收運維方面最佳實踐，DevOps 實踐也能實現(xiàn)比較好的效果。
但是對于大多數(shù)組織來說，未必有著這樣高能的開發(fā)人員，由”Dev“人員推動的”O(jiān)ps“可能并不專業(yè)，再加上高高的部門墻，推動 DevOps 阻力非常大。
面對 DevOps 在傳統(tǒng)企業(yè)的這種不適，許多廠商也推出了改良版的 DevOps 理念?；蛘叽蛑?DevOps 的旗號推出了許多 DevOps 產(chǎn)品，這些產(chǎn)品回避了 DevOps 中”麻煩“的部分，聚焦于工具，或多或少發(fā)揮了一些作用，尤其是在開發(fā)團隊中，但是往往沒有把能力延伸到運維階段。
還有許多組織，成立了一個專門的 ”DevOps 團隊“，負責DevOps工具和實踐的開展。這樣可以，但是這與開發(fā)團隊把控自己運維的原則有一些背離。
面對企業(yè)級研發(fā)的現(xiàn)狀，需要有一個新的指導方法來解決 DevOps 的問題。
平臺工程
DevOps 運動已經(jīng)有了 15 年的歷史了，但對于大多數(shù)企業(yè)來說，并沒有實現(xiàn)全面的 DevOps，也沒有享受到其好處。這種自治的 DevOps 團隊不僅沒有改善組織的交付水平，反而帶來了許多安全問題。
另一方面，隨著云原生技術(shù)的發(fā)展，創(chuàng)建”平臺“不再是一件難事。一個圍繞平臺的社會技術(shù)管理實踐應運而生，這就是平臺工程。
根據(jù) CNCF 平臺工程白皮書(翻譯)的說法：
分布式計算中的平臺是為多種用途提供通用支持能力和服務的層。平臺為獲取、使用和管理這些功能和服務提供一致的用戶體驗，包括 Web 門戶和頁面、特定于場景的代碼模板、可自動化的 API 和命令行工具。
可能用一張圖更清楚：
圖片
這里說的平臺，大家公認的是內(nèi)部開發(fā)者平臺（Internal Developer Platform, IDP）。
這個平臺成為平臺團隊與應用團隊新的分工界面之所在。團隊之間的協(xié)作會調(diào)整為以下結(jié)構(gòu)：
圖片
運維團隊的專家會變成賦能團隊，主要職責是將能力集成到平臺。原來許多手工的運維工作，已經(jīng)在平臺上實現(xiàn)，而相關(guān)的人則可能要進入平臺研發(fā)團隊，負責將運維工作抽想到平臺。當然，可能也需要一個平臺產(chǎn)品經(jīng)理把控平臺的方向，這可能是原來運維經(jīng)理的角色。
平臺隱藏了包括 Kubernetes 的基礎設施的復雜性，也將最佳實踐封裝，因而研發(fā)團隊可以更輕松的按照業(yè)務需求構(gòu)建自己的基礎設施環(huán)境，又不必擔心違反了安全規(guī)定，或者是沒有遵守最佳實踐。研發(fā)團隊可以通過平臺提供自助服務完成自己的大部分任務，可以為自己的應用”負責“，這與 DevOps 的原則相符。
那平臺工程中的”平臺“與之前的平臺的區(qū)別是什么？我覺得有幾個方面。
- 平臺的用戶不同。傳統(tǒng)的平臺的用戶可能是運維團隊，而內(nèi)部開發(fā)者平臺的用戶是開發(fā)者，也就是應用團隊。
- 兩個平臺的建設者不同。傳統(tǒng)的平臺往往是單獨的研發(fā)團隊研發(fā)，這個團隊最強的能力的是開發(fā)。這個模式的一個原因是之前的工具比較原始，需要較高的抽象才能運行，對研發(fā)的要求更高。這個模式的一個問題是運維知識與平臺的分離，作為平臺的使用者，他們的知識并不能很好的集成到平臺上。而內(nèi)部開發(fā)者平臺的則是偏向運維的平臺團隊建設，各類運維專家更加清楚日常有哪些任務，可以更好的結(jié)合運維專業(yè)知識。
- 平臺的建設思路不同。傳統(tǒng)的平臺往往是專注于能力封裝，也就是將以前各種運維任務簡化。而內(nèi)部開發(fā)者平臺則更注重實際的研發(fā)流程，關(guān)注如何幫助開發(fā)者快速的實現(xiàn)自己的目標。
如果說 DevOps 是從敏捷開發(fā)向運維的延伸，那么平臺工程則是來自管理層對于 DevOps 的回應。就像以前的 ITIL 一樣，現(xiàn)在可以從組織架構(gòu)的角度開始設計，而不必像 DevOps 那樣倒推改革。
三位一體的未來
現(xiàn)在我們再來看一下為什么是三位一體：
- 云原生技術(shù)為構(gòu)建平臺提供了能力。對于大多數(shù)組織來說，在沒有云原生相關(guān)的技術(shù)之前，構(gòu)建自己平臺的難度是非常大的，但現(xiàn)在云原生給許多組織近似的能力。
- DevOps 為協(xié)作提供了文化基礎。越來越多的案例證明，傳統(tǒng)的開發(fā)運維分工不利于高效的交付產(chǎn)品。鼓勵交流協(xié)作的 DevOps 文化已經(jīng)成為了現(xiàn)代應用交付的基石，即使有了平臺，也需要不同的團隊保持相近的文化。
- 平臺工程則在組織層面給出了指導方針。平臺工程概念的推出，讓許多有相似想法的人有了共同的術(shù)語，可以為這個目標一起協(xié)作，從而實現(xiàn)整個行業(yè)的改變。
如前面所述，這三個概念有著許許多多不同的演繹，但是在本文我希望大家抓住各自的重點，能夠體會到三者對我們這個行業(yè)的意義。
平臺工程是我們期望的一種狀態(tài)，云原生是我們達到這個狀態(tài)的工具，而要實現(xiàn)這個狀態(tài)，需要我們每個參與者永遠保持 DevOps 的協(xié)作精神，這就是三位一體。
本文名稱：三位一體：創(chuàng)新互聯(lián)、DevOps和平臺工程
文章路徑：http://m.fisionsoft.com.cn/article/copioji.html
