雲原生應用程式
在六，七年前雲計算開始大步向前時，人們苦苦掙扎的重要問題之一是：「如果我想在公共雲，私有雲或混合雲中執行它們，我的應用程式將是什麼樣子？ ？
當時有很多方法可以回答這個問題。
乙個流行的隱喻來自比爾·貝克（bill baker）的演講，當時他在微軟。 他將傳統應用程式「寵物」與雲應用程式「牛」進行了對比。 在第一種情況下，您要給寵物命名並在生病時護理它們恢復健康。 在後一種情況下，您給他們編號，如果其中乙個發生問題，您會吃漢堡包並換乙個。
還有其他嘗試將這一區別編成法律。 「 十二要素應用程式 」是用於構建軟體即服務應用程式的顯式方法。 行業分析師gartner從業務角度看問題，使用模式1和模式2區分傳統it（側重於穩定性，健壯性，成本效益和垂直規模等屬性）與雲原生it（強調適應性和靈活性）。敏捷）。
這些仍然是有用的觀點。 許多現代，動態和橫向擴充套件的工作負載均作為虛擬機器在公共雲和私有雲（如openstack）中執行 。 顯然，它們是根據與「 big iron」伺服器上傳統的按比例放大，長期執行的應用程式不同的原理開發和操作的。
但是，雲原生通常意味著更具體的含義，尤其是在應用程式體系結構和設計模式的上下文中。 它是使用精細的api驅動的服務（也稱為微服務）組成的容器化基礎架構和應用程式的交集。 合併是偶然的。 像netflix這樣的公司正在推廣微服務理念，以有效利用雲計算。 首先通過早期的平台即服務產品實施容器，然後將其作為更廣泛的標準化生態系統的一部分，容器是打包，部署和管理這些微服務的好方法。
過去幾年中，容器的最大變化也許是可用於管理容器的工具的數量和成熟度的增加。
順便說一句，不要太在意微服務術語。 重要的是應用程式的整體敏捷性和可維護性。 正如通過使用持續整合和連續交付的devops流程交付的那樣，這往往會導致模組化和鬆散耦合的服務，這些服務的依賴關係已明確定義。
但是，並非所有事情都需要分解為僅通過公開的，穩定的api進行通訊的單功能服務，如果這對應用程式的性質和團隊的規模沒有意義的話。
容器本身維護服務之間的資源和安全隔離。 它們提供了一種快速且節省資源的方式，可以根據需要啟動其他服務，並在需求下降且不再需要它們時退役。 從開發人員的角度來看，容器也是一種出色的生產力工具，因為容器將內容打包為一系列的層，並且可以在需要補丁時快速，一致地進行更新。
過去幾年中，容器的最大變化也許是可用於管理容器的工具的數量和成熟度的增加。 kubernetes是最著名的。 它使linux容器操作自動化，並消除了部署和擴充套件容器化應用程式涉及的許多手動過程。
但是，kubernetes只是涉及容器生態系統中的開源專案的起點。 有像prometheus這樣的監視程式，有像jaeger這樣的分布式跟蹤程式。 istio服務網格連線，管理和保護微服務。 另乙個開發領域是功能即服務（通常稱為無伺服器 ），它響應事件（某種觸發器）執行功能（即執行某些操作的**）。 乙個主要的驅動力是進一步簡化程式設計師建立新服務的方式。
許多甚至大多數工作負載都可以在雲中或在多個雲的混合組合中執行。 但是，「雲原生」應用程式的想法是，在雲計算革命爆發約十年後，我們對充分利用新型基礎架構的最佳方法有了一些紮實的想法。 並且，反過來，我們將繼續改進這些基礎架構技術，以為應用程式開發人員提供所需的工具。 這就是雲原生的真正含義。 靈活，可擴充套件，可重用的應用程式使用了可用的最佳容器和雲技術。
雲原生應用程式
雲原生應用程式的構建
由於雲服務提供商 如aws 微軟和谷歌等 的激增，雲原生已經成為嵌入到現代應用程式開發中的乙個重要概念。簡而言之，雲原生應用程式就是為雲構建的應用程式。如何構建雲原生應用程式？雲原生應用程式是基於雲計算基礎設施設計的，雲計算本身的應用程式開發並不是圍繞內部伺服器 資料庫 連線等建立，而是依賴抽象出硬...
雲原生應用
在峰會的第二天很多企業分享了他們在云原應用方面的實踐和思考。雲原生應用 雲原生是一種方法，用於構建和執行充分利用雲計算模型優勢的應用。雲原生應用充分借助雲計算平台的計算，儲存，網路以及負載均衡等一系列的能力來構建應用。應用本身不用再關注基礎架構，高可用以及服務水平擴充套件等能力，而將重點放在業務本身...
什麼是雲原生？
雲原生從字面意思上來看可以分成雲和原生兩個部分。雲是和本地相對的，傳統的應用必須跑在本地伺服器上，現在流行的應用都跑在雲端，雲包含了iaas,paas和saas。原生就是土生土長的意思，我們在開始設計應用的時候就考慮到應用將來是執行雲環境裡面的，要充分利用雲資源的優點，比如 雲服務的彈性和分布式優勢...