傻瓜教程：什么是云原生應用程序？
我們通常都會在設想什么是一個Cloud Native Appliction，這也是我們為什么不停地去測試、學習各種云服務，學習、使用docker的原因。本文介紹的云原生應用的出發點，可能和我們的有著異曲同工的地方，可能在某些方面說的還是比較抽象，但是通過圖片，我們還是可以清晰明白在非云應用往云生應用的發展框架是什么，會帶來什么樣的好處等等，以及如何處理好不同域間容量、數據、狀態的關系。
最近有試著描述“現代應用程序”或“現代工作負載”。
Twelve-Factor App就是一個很好的嘗試。
這是一個很好的方法來描述這樣的工作量但我認為這些概念需要降低一個數量級使普通人正常理解他們。
這就是我想要在這個博文上做的。我們將省略一些重要的細節通過這樣做但沒關系。
讓我直接點：在(我的意思是非常)高水平云本機應用程序是一個應用程序,該應用程序有一個明確的“基礎設施”和“數據”之間的分離。至少在我看來,設計一個云本機應用程序沒有畫這個明確的分離。
我用數據作為一個非常松散的術語。你可能正在考慮一個“基于數據”(哪個都行)但這真的應該包括“配置”。
另一種方法來描述這種分離可能是“容量”和“狀態”。不僅僅是這樣。
讓我們立刻開始用一幅畫來描述這一概念：
請注意這兩個域的特征。
基礎設施容量沒有你需要或想要保護的自己的狀態(至少在本地存儲中)。
這是完全無狀態,你可以通過自動化輕松地(反復)創建它,因此,它不需要有彈性。
另一方面承載了你的持久性的域(在每一個可能的形狀和形式)具有完全不同的特征,因為它需要可靠的、高可用性、耐用和這一切。
此時,您可能想知道這是如何不同與傳統模式相比在3層web應用程序。在我看來，云本機應用程序在隔離傳統“應用層”與傳統的“數據層”將envelope推到極端。
基礎設施容量域
這就是虛擬機(又名實例)實時托管原生云應用的代碼。他們完全是無狀態的，他們是一群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模型。
#p#
數據和狀態域
現在將自己傳送到另一個維度。
轉換思維。
持久性和彈性問題。很多很多問題。
有幾件事,屬于這個域。
最重要的一個就是在哪持有用戶數據。想想傳統的(關系型)數據庫但也可能是一個存儲庫的非結構化數據(例如對象存儲、NoSQL)。往往這些服務是由云提供商提供管理服務。并沒有什么會阻止其他人寫云本機應用程序部署和管理他們自己的數據庫(關系型或非關系型)，通常是利用諸如AWS RDS或AWS DynamoDB等管理服務。
這方法(有價值可選)的優點是，你有你的持久性和可靠性保證而不是花時間讓自己發生。
***，一個云提供商用一個完全自動化的方式管理成百不一定上千的實例比一個人兼DBA特別是一個開發人員，要好很多。
這些云托管服務的特點是，他們(通常)和水平呈線性比例關系。
以對象存儲為例，您可以在主宰***(或觀念上的)的數據量。
想想諸如AWS DynamoDB等服務,你只需要訂閱這個服務形成SLAs，云提供商將根據SLA管理所需的容量(后臺)。
傳統的關系數據庫(盡管管理，如AWS RDS)通常不提供這種感覺***的可伸縮性，因為他們常常向外擴展(但不超出)和基于云實例支持管理數據庫大小才有的實際限制。
取決于你的選擇將會有一個變量的基礎設施和核心操作過程的可視性,但所有這些解決方案減輕很多負擔的持久性域的可伸縮、高可用性和彈性。
第二組持久性,屬于這個域的描述是基礎設施,隨著應用程序棧,需要部署、推廣和運營。我把它叫做基礎結構狀態。
這樣描述：
- 核心基礎設施應該像什么樣的(又名“基礎設施及代碼”)
- 實例化應用程序的存儲庫
- 應用程序配置。
題外話： Twelve-Factor App聲明中描述將應用程序代碼從應用程序配置中分離是一個***實踐。通過這樣做你可以實例化不同的環境(開發、測試、分期、生產)通過簡單地指向一個不同的應用程序配置。模塊化(各級)規則在云本機應用程序。
這種持久性的第二組數據和狀態域可以以不同的方式實現。這可能是一個(或多個)：
- 一組AWS Cloudformations模板描述如何建模你的基礎設施容量
- Puppet, Chef, Ansible, Saltstack或是Terraform，聲稱讓你的虛擬機在運行時通過給定的配置集中起來
- 服務如GitHub托管應用程序的“代碼”
注意基礎設施狀態只是概念上的用戶數據,它們共享相同的需求(一致、可靠、耐用等)。然而這些服務可以在物理上分開。
雖然最近用一個云提供商一起把所有這些環境(基礎設施容量域和數據和狀態域)放在一起是相當普遍的，大家也可以認為他們是松散耦合的環境(如基礎設施容量由兩個云提供商,業務數據托管在第三個云提供商和基礎設施狀態托管在其他地方)。
讓我們一起把它們組裝起來
如果你試圖把所有上述成更詳細的圖片，云本機應用程序將看起來像是這樣。
在根據上述每個基礎設施狀態邏輯的描述實例化(和運營)每個基礎設施，在運行時，應用程序部署在開始消費和交互用戶數據(如數據庫、對象存儲等)。
這張照片缺少的(在許多其他事物)是可伸縮性這兩個域的性質。這是另一個云平臺的核心原則,在這篇文章中我不不涉及過多。這兩種環境中可以根據外部觸發自然增長和收縮(如越來越多的應用程序用戶或越來越多組數據管理)。
因此應用程序所有者將根據實際的，正在被應用程序使用的，資源支付相關費用。
#p#
你今天站在哪里?
我們已經描述了一個云本機應用程序的外觀。
但是，你處于什么位置?
很有可能，除非你是Netflix風格組織，你不在我所說的范圍內。
很有可能你的工作負載可能看起來或多或少是這樣的：
你還記得 Pets and Cattle的故事嗎?
我不再重復了。你可以閱讀一下那個博客。
還要注意為何你沒有形成基礎設施容量和數據之間的關系。更不用說基礎設施的狀態了。
95%的組織(完全編造的數字，但我覺得差不了多遠)本質上是處理一群寵物，通過名字召喚，都有自己的獨特的個性和狀態(在本地保存)，當他們死的時候你會哭的很兇。
傳統的(即不是云原生的)應用程序時,您需要安裝，操作，文檔，備份，遷移和保護您的工作負載。這與你在云本機應用程序上做的完全相反。
除此之外，沒有特定的分離容量和狀態。所有工作負載的狀態保存在本地磁盤上的每個實例。
在***的情況下，狀態一直備份到一個Word或Excel文檔。如果(或者當?)工作負載的接近滿負荷，操作員通常會手動地通過一個簡單的模板根據Word / Excel“使用說明書”重裝一次。
其中的一些工作負載也以數據庫或文件的形式托管用戶數據。他們需要額外的照顧，這很復雜，甚至以后的可靠性和可伸縮性。
一個很好的試金石：看看您正在運行的舊的應用程序或云本機應用程序是不是如下。
在周一早上11點邀請我到你的數據中心，關閉并摧毀20%的生產實例。
如果您的應用程序部署自我修復本身沒有任何需要你的部分，如果有最小的不中斷你的終端用戶體驗，那么你正在運行一個合適的云本機應用程序。
相反，如果你是像“噢，我的天你做了什么?我有一個星期的工作現在在我的面前!”這樣的，所有你的手機瘋狂地響了，那么歡迎來到還有剩下的95%的人的現實世界。
記住，自動化和自愈是云本機應用程序的一個重要宗旨。我記得會見過一個客戶，一個應用程序(計算容量和數據)分布在數據中心的架構只為了保留一個完整的站點不中斷。他們告訴我，不幸的是，如果一個數據節點壞了，它將花費數周，也許不是數月手動重建環境。如果你問我，那這不是云。
結論
還有許多其他云本機應用程序的特點,這里我不贅述了。如果你是一個高級的開發人員加入到這個行列中，你***立刻先把Twelve-Factor App 的說明讀一遍。
在這篇文章中我想笨一點方式讓這些概念被更多的人明白(特別是沒有云或開發人員背景的聽眾)。
總而言之，我認為強分離容量和狀態是其中一個強大的云咒語，把大多數優勢(和改變?)與傳統IT相比較。
這種分離是一個在任何級別的一個真正的云的基礎設施都是的核心原則。在這篇文章中，我利用一個大圖提到了全部的復雜的云本機應用程序。
然而,即使你把云環境的最小的原子單元(即一個實例)，分離容量和狀態仍然是核心。看看亞馬遜是如何描述由一個EC2實例與一對EBS磁盤(即持久的磁盤)組成的一個基本的工作負載：
在一個小得多的規模它傳達了這篇文章我試圖傳達的同樣的信息(圖形化)。云中的各級模塊化是核心。
題外話:具有諷刺意味的是，EC2默認為臨時的磁盤，那么云本機應用程序模式(在實例級不需要狀態存儲)。然而，為了更好地服務傳統非云本機應用程序，亞馬遜引入一個EBS(單一實例級別持久性)的概念。一個可以稱為在持久的磁盤anti-cloud模式的實例。我將因為這點拋棄它。
***,正如你可能已經猜到了，在這篇文章中你所讀到的關于云本機應用程序會引入其他流行語如：敏捷，DevOps，持續性開發、持續性部署和更多更多。
事實上,沒有一個正確設計云本機應用程序沒有辦法，做到這些的。
Massimo。
