通常，圍繞云原生的對話會直接潛入諸如容器化和微服務之類的技術選擇中。這些絕對是云原生項目的潛在組成部分，但絕對不是全部。在本系列文章中，我們將從幾個不同的角度探討本機云，當然包括技術和基礎架構，還包括架構，設計，以及可能最被忽略的人員和流程。用最簡單的術語來說，云原生意味著不僅要遷移到云，還要充分利用云基礎架構和服務的獨特性來快速交付業務價值。

在該術語本身開始使用之前，就已經存在云原生概念。從某種意義上說，云原生始于公共云供應商開始提供對彈性計算能力實例的輕松且負擔得起的訪問。問題就變成了，如何利用該新基礎架構的靈活性來編寫應用程序，以及由此帶來的業務收益?

在過去十年中，云原生方法和技術發生了很大變化，并且仍在不斷發展，但是云原生應用程序要實現的核心技術和業務目標卻保持不變。這些包括：

敏捷性和生產力：實現以業務指標為指導的快速創新。降低維護風險，并使環境保持最新狀態。 彈性和可伸縮性：以自我修復和無停機的持續可用性為目標。提供彈性縮放和無限容量的感知。 優化和效率：優化基礎設施和人力資源的成本。啟用位置和提供者之間的自由移動。

當我們回顧云原生的“為什么”時，我們將在后面的文章中進一步細分這些目標，但是希望即使是從這個簡單的定義來看，也應該清楚的是，云原生的范圍比僅僅向新的類型遷移還廣?；A設施。但是，盡管這些目標是準確的，但很難看出它們專門適用于本機云。我們需要做更多的工作來定義云原生的真正含義。

與云原生相關的流行參考點(例如微服務)和較早的清單(例如12factor應用)可能會讓您得出結論，云原生是對體系結構樣式的描述，其他選擇也隨之而來。毫無疑問，云原生架構確實存在。但是，為了在云原生平臺上取得成功，公司必須采取更全面的看法。除了架構和基礎架構決策外，還存在組織和流程決策。這導致我們實現了一個關鍵的實現：

單憑技術無法取得業務成果

 

下圖顯示了這些決策如何相互作用。

單憑技術無法取得業務成果

我們的文章“避免使用不完整的云原生采用”中描述了如何將這些方面相互鏈接以及有關鏈接斷開時發生的警告的一個很好的示例。在本系列文章中，我們將展示云原生的成功如何與這三個關鍵領域的變更協調相關聯，以便成功進行協調：架構與設計，技術與基礎架構，人員與流程。讓我們更詳細地探討每一個。

技術與基礎設施：在“云原生”的背景下，“云”是什么?

 

十年或更早之前，“云”一詞主要是關于位置的。它通常指的是位于可通過Internet訪問的其他人的數據中心中的基礎結構。但是，今天的“云”更多地說明了您如何與該基礎架構進行交互。確實，位置元素幾乎消失了，因為現在很常見的是在您自己的數據中心中運行類似云的設施-“私有云”，以及可能涉及在兩者之間運行的服務和工作負載的混合解決方案。

因此，今天的云更多地與您如何與基礎架構互動有關，至少必須提供以下內容：

自我配置：即時獲取新的虛擬資源(服務器，存儲，網絡)。 彈性：根據需求自動向上和向下擴展資源(及其相關的成本)。 自動恢復：資源旨在從故障中恢復而無需干預，并且對服務可用性的影響最小。

但是，隨著云平臺和概念的日趨成熟，云原生云實際上也意味著對基礎架構的更大抽象。

不變的部署-例如基于容器映像的部署 聲明式配置-提供基礎狀態的“基礎架構即代碼” 與運行時無關—平臺將組件(例如容器)視為黑盒，而無需了解其內容 組件編排—通過通用的聲明性策略和配置啟用管理(監視，擴展，可用性，路由等)。

在云原生的早期，這些功能通常是高度專有的，但是現在，這種功能幾乎以容器和容器編排功能(例如Kubernetes)的形式無處不在。因此，上面的列表非常特定于容器的詞匯表，但是值得認識到還有其他選擇，例如無服務器/作為服務的服務會進一步從基礎結構中抽象出來，并且將來可能會變得更加突出。

我們可以包括更多內容，例如構建自動化，服務網格，日志記錄，跟蹤，分析，軟件定義的網絡和存儲等。但是，我們隨后將涉足云平臺當前更具專有性的方面。希望隨著時間的流逝，這些也將變得更加標準化。因此，在這種情況下，“云”實際上表示具有上面列出的特殊屬性的基礎架構和技術。

架構與設計：“云原生”中的“原生”是什么意思?

 

“原生”是指我們將構建的解決方案不僅要“在云上運行”，而且要特別利用云平臺的獨特性。應用程序不僅神奇地繼承了底層云基礎架構的優勢，還必須教會他們如何操作。

在這里，我們需要非常小心地使用語言。當我們使用“原生”來指“云平臺的唯一性”時，我們并不是指特定云提供商的特定于供應商的方面。那將是“云提供商本機”，實際上，這將完全與圍繞可移植性和使用開放標準的目標背道而馳。我們的意思是概念上所有云平臺都通用的東西。換句話說，我們在上一節中有關基礎結構和技術的內容中強調了這些內容。

對體系結構和設計有重要影響。我們需要編寫解決方案以確保例如它們可以水平縮放，并且可以與自動恢復機制一起使用。在這里，云原生可能與微服務概念重疊最多。例如，這包括編寫以下組件：

最小化狀態 減少依賴 具有定義明確的界面， 輕巧 是一次性的

在下一篇文章中，我們將對它們進行更深入的描述，但是到目前為止，可能要注意的最重要的一點是它們都是高度相互依賴的。例如，如果要創建具有高度狀態的一次性組件，則要困難得多。減少依賴關系從本質上將有助于使組件更輕便。具有明確定義的界面將使可拋棄的組件更容易重新實例化，依此類推。這只是一個更廣泛點的小例子，即遷移到云原生方法需要同時在許多相關方面進行更改。我們逐漸發現的這些云原生成分是相輔相成的。

人員和流程：“云原生”如何改變我們的組織和工作方式?

 

可能不太明顯的是，當我們使用有關架構和底層基礎結構的上述假設和決策時，它為我們提供了從根本上改變我們處理人員和流程方式的機會。的確，可以認為必須進行這些更改。

下面，我們探討了微服務方法對人員/流程的影響：

微服務意味著您是在小型自治團隊中構建服務。這只是Conway定律的應用-如果您希望系統由小的，解耦的組件組成，則必須允許您的團隊規模較小，并且不能與其他團隊緊密耦合-僅允許通過定義明確且受控接口。 微服務還意味著您正在使用敏捷方法并將DevOps原理應用于開發流程。如果沒有，您將如何獲得端到端的反饋以及對代碼的快速迭代，這是該方法的核心優勢。反過來，DevOps將意味著進一步的流程改進，例如持續集成和持續交付/部署(CI / CD)。 DevOps要求您采用其他特定的技術流程，例如自動化測試(可能包括測試驅動的開發)，并強烈引導您進行基于主干的開發。最小化測試周期的渴望可能會進一步導致您探索改變人們與工作相結合的方式(例如，結對編程)。

同樣，容器技術也會影響所需的技能，角色和流程：

云基礎架構通常使用諸如Kubernetes知識之類的通用云平臺技能，而不是特定的運行時或產品技能，在操作(部署，擴展，高可用性等)上實現更多目標。這從根本上減少了跨多個技術領域工作的人員的學習曲線，并實現了更廣泛的角色和知識共享，從而提高了效率并降低了成本。它還鼓勵現場可靠性工程師轉向盡可能使操作任務自動化。 容器，特別是容器映像技術，簡化了CI / CD管道的自動化，從而縮短了構建/發布周期時間，并提高了生產率。構建管線實現方式的同質性提高意味著可以更輕松地維護它們，并且確實可以由更廣泛的人群使用。 不變的容器映像與聲明性的“將基礎結構作為代碼”結合使用，可以提高跨不同環境的部署的一致性。這降低了測試和診斷成本，提高了部署速度，并減少了停機時間。從過程的角度來看，這可以實現可靠性，性能和安全性測試等方面的“左移”。反過來，這又帶來了更多的DevOps / DevSecOps文化，在這種文化中，開發人員對代碼的操作質量負有更大的責任。 總結“云原生”的含義

 

綜合到目前為止所討論的內容，我們可以看到需要從三個不同方面定義云原生。

抽象化基礎架構復雜性的平臺。(基礎設施和技術) 充分利用基礎架構抽象(架構和設計)的解決方案 開發，運營和業務流程的自動化，以及開發團隊(人員和流程)的自主權不斷提高

今天，技術方面當然非常關注容器化，但是重要的是諸如該技術的自我配置，彈性和自動恢復之類的屬性，而不是該技術本身。

在體系結構上，我們最常使用微服務原理來創建更輕量，細粒度，狀態最小的組件，從而更好地映射到抽象基礎架構。沒有正確的設計原則，我們的解決方案將無法從該平臺中受益。例如，它將不會動態擴展，也不會提供細粒度的彈性，不會提供快速的構建和部署，也不會與平臺上的其他應用程序保持操作一致性。

人們通常將人員和流程更改與云原生隔離開來，但實際上它們是并駕齊驅的，我們認為它們是定義特征的一部分。缺乏軟件開發生命周期的自動化將意味著團隊需要花更多的時間在平凡的事情上，而花在商業價值上的時間卻相對較少。繁重，自上而下的組織和治理結構將無法為團隊提供幫助他們進行業務創新所需的自主權。

因此，有了對云原生實際含義的更具體定義，我們就可以開始下一步，并擴展之前的圖表。

在上圖中，我們提供了有關這些方面的關鍵要素的一些信息。在本系列的后續文章中，我們將考慮“如何”構建云原生解決方案，并從人員和流程問題入手詳細研究每個要素。

但是，應該已經很清楚，完全采用云本地化并非易事，并且需要業務贊助。因此，在另一篇文章中，我們將匯總我們所學到的有關成功實現云原生所需的承諾的知識，并退后一步來重新考慮“為什么”您可能首先使云原生移動，以及什么?您可能希望實現的好處。

網頁名稱：云原生究竟意味著什么？
轉載來于：http://www.js-pz168.com/news35/201885.html

成都網站建設公司_創新互聯，為您提供App設計、ChatGPT、品牌網站制作、動態網站、虛擬主機、網站策劃

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯