本文講的是<b>什麼是雲原生應用程式</b>，【編者的話】我們通常都會在設想什麼是一個Cloud Native Appliction，這也是我們為什麼不停地去測試、學習各種雲服務，學習、使用docker的原因。本文介紹的雲原生應用的出發點，可能和我們的有着異曲同工的地方，，可能在某些方面說的還是比較抽象，但是通過圖檔，我們還是可以清晰明白在非雲應用往雲生應用的發展架構是什麼，會帶來什麼樣的好處等等，以及如何處理好不同域間容量、資料、狀态的關系。
最近，雲原生應用（Cloud Native Application）這個概念又重新被大家提起來，谷歌也組織成立了雲原生計算基金會（CNCF）。很多人都不明白什麼是Cloud Native Application，本文中我試着向大家解釋它。
簡單來說，雲原生應用其實就是需要嚴格的分離架構和資料。但在我看來，我們很難清楚的劃分架構和資料之間的界限。
在這裡，資料是一個相對寬泛的術語，你可以了解為資料庫，但它還應該包括一些配置資料。
換個角度來看，我們也可以把這種分離（界限）描述為『能力（capacity）』和『狀态（state）』。我們可以用下面這副圖檔來解釋這個概念。
請注意這兩個域的特點。
基礎設施中沒有任何需要儲存的資訊。這完全是無狀态的。
另一方面，承載持久化功能的域（在每一個可能的形狀和形式）具有完全不同的特征，因為它需要可靠的、高可用性、持久性和。這個時候，你可能會問，它與傳統的三層Web應用的差別。在我看來，雲原生應用吧應用層和資料層的分離做的更徹底。
這就是虛拟機（又名執行個體）實時托管原生雲應用的代碼。他們完全是無狀态的，他們是一群VM所有相同配置（基于角色）和整個生命周期的自動化。在這樣一個環境中傳統IT概念通常關聯到虛拟機甚至沒有任何意義。下面是一些例子。
不安裝這些伺服器（傳統方法），因為它們是由自動生成腳本由外部事件或政策觸發（如基于使用者需求自動定量前端層）
不操作這些伺服器，原因同上。
不記錄這些伺服器做什麼和如何提供它們，因為代碼生成文檔。
不備份這些伺服器，因為他們沒有狀态。如果你失去了伺服器，你重新執行個體這些伺服器，從頭開始。
你沒有這些伺服器從一個地方遷移到另一個，因為同樣的原因。你重新執行個體這些伺服器，從頭開始。
你不用雲平台級别提供高可用性來保護這些伺服器。沒有任何保護，如果他們失敗了，你重新執行個體伺服器。
你不需要為這些服務規劃基礎設施的大小，你隻需為任何給定的時間點上的消費。
你配置基礎設施的本質與運作代碼中的一部分一樣。你聽說過“基礎設施及代碼”的概念嗎？這就是了。
現今，相當常見的看到實作這類模式被用于實作配置工具組合，然後切換到配置管理工具。
這個想法是為了提供虛拟機，讓配置工具給客人建立适當的個性和角色。
AWS Cloudformations，HashiCorp Terraform，VMware Application Director，RightScale CMP這些都是專注于可程式設計初始化執行個體的幾個例子。
Puppet、Chef、Ansible (等等) 是配置管理工具，專注于通過自動化確定執行個體融合，給定一緻的配置和狀态。
截至2014年底，這幾乎是目前的狀況（和最佳實踐）。
然而幾個新趨勢和模式在上升。他們可能最終收斂彙聚，在某種程度上，你可以看作為一種趨勢。
第一個被稱為不變的工作負載。目前為止，我們已經讨論了被稱為可變負載，這意味着他們的配置可以改變加班一樣配置管理工具配置和重新配置他們需要讓他們收斂到一個理想的最終狀态。換句話說雲本機應用程式目前的最佳實踐建議提供一個基礎模闆和在作業系統核心模闆，確定核心模闆使用特定的配置。不變工作量的哲學表明，執行個體相對應的應該是不變的，如果你需要重新配置一個執行個體（如更新應用程式代碼），你應該摧毀這個執行個體并重新立即部署它最新的配置到模闆中。
第二個趨勢是朝着簡化整個堆棧包括這些工作負載。目前常見的做法是使用虛拟機作為一個占位符，用于運作時（例如AWS EC2執行個體或VMware虛拟機）。這些天有一所新學校的想法說虛拟機太大，太臃腫和雲本機應用程式太重，容器是一個更好的方式來打包和部署雲本機應用程式。我相信你聽說過Docker和相關的動量（或者說是科技泡沫？）。這也很符合另一個趨勢（微服務），這一個博文不夠說了。
有趣的是，許多人也認為這種容器化趨勢隻是某個東西更大（呃，或者說更小？）的過渡。
援引：Invent 2014 AWS介紹了一項新服務，被稱為Lambda雲本機應用程式。這個可以允許開發人員編寫代碼并把代碼作為資料的一部分。當資料發生變化時，事件觸發代碼運作。沒有虛拟機，沒有選擇的容器，代碼隻是突然地運作起來。換句話說，基礎設施沒有簡化，它隻是消失了。
下圖描述了圖形化這一概念：
你可以想象這些概念将會話通向PaaS-ish模型。
現在将自己傳送到另一個次元。
轉換思維。
持久性和彈性問題。很多很多問題。
有幾件事，屬于這個域。
最重要的一個就是在哪持有使用者資料。想想傳統的（關系型）資料庫但也可能是一個存儲庫的非結構化資料（例如對象存儲、NoSQL）。往往這些服務是由雲提供商提供管理服務。并沒有什麼會阻止其他人寫雲本機應用程式部署和管理他們自己的資料庫（關系型或非關系型），通常是利用諸如AWS RDS或AWS DynamoDB等管理服務。
這方法（有價值可選）的優點是，你有你的持久性和可靠性保證而不是花時間讓自己發生。
最後，一個雲提供商用一個完全自動化的方式管理成百不一定上千的執行個體比一個人兼DBA特别是一個開發人員，要好很多。
這些雲托管服務的特點是，他們（通常）和水準呈線性比例關系。
以對象存儲為例，您可以在主宰無限(或觀念上的)的資料量。
想想諸如AWS DynamoDB等服務，你隻需要訂閱這個服務形成SLAs，雲提供商将根據SLA管理所需的容量（背景）。
傳統的關系資料庫（盡管管理，如AWS RDS）通常不提供這種感覺無限的可伸縮性，因為他們常常向外擴充（但不超出）和基于雲執行個體支援管理資料庫大小才有的實際限制。
取決于你的選擇将會有一個變量的基礎設施和核心操作過程的可視性，但所有這些解決方案減輕很多負擔的持久性域的可伸縮、高可用性和彈性。
第二組持久性，屬于這個域的描述是基礎設施，随着應用程式棧，需要部署、推廣和營運。我把它叫做基礎結構狀态。
這樣描述：
核心基礎設施應該像什麼樣的（又名“基礎設施及代碼”）
執行個體化應用程式的存儲庫
應用程式配置。
這種持久性的第二組資料和狀态域可以以不同的方式實作。這可能是一個（或多個）：
一組AWS Cloudformations模闆描述如何模組化你的基礎設施容量
Puppet， Chef， Ansible， Saltstack或是Terraform，聲稱讓你的虛拟機在運作時通過給定的配置集中起來
服務如GitHub托管應用程式的“代碼”
注意基礎設施狀态隻是概念上的使用者資料，它們共享相同的需求（一緻、可靠、耐用等）。然而這些服務可以在實體上分開。
雖然最近用一個雲提供商一起把所有這些環境（基礎設施容量域和資料和狀态域）放在一起是相當普遍的，大家也可以認為他們是松散耦合的環境（如基礎設施容量由兩個雲提供商，業務資料托管在第三個雲提供商和基礎設施狀态托管在其他地方）。
如果你試圖把所有上述成更詳細的圖檔，雲本機應用程式将看起來像是這樣。
在根據上述每個基礎設施狀态邏輯的描述執行個體化（和營運）每個基礎設施，在運作時，應用程式部署在開始消費和互動使用者資料（如資料庫、對象存儲等）。
這張照片缺少的（在許多其他事物）是可伸縮性這兩個域的性質。這是另一個雲平台的核心原則，在這篇文章中我不不涉及過多。這兩種環境中可以根據外部觸發自然增長和收縮（如越來越多的應用程式使用者或越來越多組資料管理）。
是以應用程式所有者将根據實際的，正在被應用程式使用的，資源支付相關費用。
我們已經描述了一個雲本機應用程式的外觀。
但是，你處于什麼位置？
很有可能，除非你是Netflix風格組織，你不在我所說的範圍内。
很有可能你的工作負載可能看起來或多或少是這樣的：
你還記得 [Pets and Cattle](http: //it20.info/2012/12/vcloud-openstack-pets-and-cattle/)的故事嗎？
我不再重複了。你可以閱讀一下那個部落格。
還要注意為何你沒有形成基礎設施容量和資料之間的關系。更不用說基礎設施的狀态了。
95%的組織（完全編造的數字，但我覺得差不了多遠）本質上是處理一群寵物，通過名字召喚，都有自己的獨特的個性和狀态（在本地儲存），當他們死的時候你會哭的很兇。
傳統的（即不是雲原生的）應用程式時，您需要安裝，操作，文檔，備份，遷移和保護您的工作負載。這與你在雲本機應用程式上做的完全相反。
除此之外，沒有特定的分離容量和狀态。所有工作負載的狀态儲存在本地磁盤上的每個執行個體。
在最好的情況下，狀态一直備份到一個Word或Excel文檔。如果（或者當？）工作負載的接近滿負荷，操作員通常會手動地通過一個簡單的模闆根據Word / Excel“使用說明書”重裝一次。
其中的一些工作負載也以資料庫或檔案的形式托管使用者資料。他們需要額外的照顧，這很複雜，甚至以後的可靠性和可伸縮性。
一個很好的試金石：看看您正在運作的舊的應用程式或雲本機應用程式是不是如下。
在周一早上11點邀請我到你的資料中心，關閉并摧毀20%的生産執行個體。
如果您的應用程式部署自我修複本身沒有任何需要你的部分，如果有最小的不中斷你的終端使用者體驗，那麼你正在運作一個合适的雲本機應用程式。
相反，如果你是像“噢，我的天你做了什麼？我有一個星期的工作現在在我的面前!”這樣的，所有你的手機瘋狂地響了，那麼歡迎來到還有剩下的95%的人的現實世界。
記住，自動化和自愈是雲本機應用程式的一個重要宗旨。我記得會見過一個客戶，一個應用程式（計算容量和資料）分布在資料中心的架構隻為了保留一個完整的站點不中斷。他們告訴我，不幸的是，如果一個資料節點壞了，它将花費數周，也許不是數月手動重建環境。如果你問我，那這不是雲。
在這篇文章中我想笨一點方式讓這些概念被更多的人明白（特别是沒有雲或開發人員背景的聽衆）。
總而言之，我認為強分離容量和狀态是其中一個強大的雲咒語，把大多數優勢（和改變？）與傳統IT相比較。
這種分離是一個在任何級别的一個真正的雲的基礎設施都是的核心原則。在這篇文章中，我利用一個大圖提到了全部的複雜的雲本機應用程式。
然而，即使你把雲環境的最小的原子單元（即一個執行個體），分離容量和狀态仍然是核心。看看亞馬遜是如何描述由一個EC2執行個體與一對EBS磁盤（即持久的磁盤）組成的一個基本的工作負載：
在一個小得多的規模它傳達了這篇文章我試圖傳達的同樣的資訊（圖形化）。雲中的各級子產品化是核心。
題外話：具有諷刺意味的是，EC2預設為臨時的磁盤，那麼雲本機應用程式模式（在執行個體級不需要狀态存儲）。然而，為了更好地服務傳統非雲本機應用程式，亞馬遜引入一個EBS（單一執行個體級别持久性）的概念。一個可以稱為在持久的磁盤anti-cloud模式的執行個體。我将因為這點抛棄它。
最後，正如你可能已經猜到了，在這篇文章中你所讀到的關于雲本機應用程式會引入其他流行語如：靈活、DevOps、持續性開發、持續性部署和更多更多。
事實上，沒有一個正确設計雲本機應用程式沒有辦法，做到這些的。
原文釋出時間為：2015-08-16
本文作者：zaburo
本文來自雲栖社群合作夥伴DockerOne，了解相關資訊可以關注DockerOne。
原文标題：什麼是雲原生應用程式