向Cloud Native應用的轉變以及對未來的展望
軟件組織正在快速地實施云技術，但遷移始終是一個無法回避的挑戰。哪些部分是需要你密切留意的？哪些應用程序更適合于進行遷移？如何對應用程序進行重構以適用于云端？經歷了這一轉變的先行者為我們留下了什么啟示？在這一系列文章中，你將從那些在幫助企業成功地遷移至云環境方面富有經驗的專家那里獲得實用的建議。這一領域應得到高度關注，我們希望你也能夠參與這方面的討論。
軟件企業正在實施云基礎設施的道路上不斷加速，隨著這種轉變的持續推進，理解在云環境中運行對于應用程序來說意味著什么，這一點也變得十分重要。
傳統意義上，應用程序依賴于冗余的、并且高度優化的基礎設施以維持高可用性及可靠性，而不是依賴于軟件架構。其結果是基礎設施的能力往往沒有得到充分的發揮，那些額外的運行能力就意味著金錢的浪費。隨著現代化的組織對于節約成本、提高效率以及改進靈活性的需求的浮現，這種浪費是不可接受的，也這是軟件組織向云環境遷移的重要驅動力。
Cloud Native應用
在云環境中運行的應用程序本身要承擔起更大的責任，它的架構方式必須能夠提高它的正常運行時間、容錯性以及可伸縮性。雖然許多云提供商不斷地宣傳它們的服務是多么可靠，但真正的范式轉變在于：正常運行時間的職責已經轉移到應用程序的層面，取決于應用程序對基礎設施的感知以及控制能力。對于要成為 “cloud native”的應用來說，這一點是最基本的。
對cloud native的應用來說，首先，也是最重要的一點在于在架構與設計時必須考慮到故障的應對。Netflix公司是在創建cloud native的應用方面得到業界高度評價的專家，他們經常在博客中提到如何 為應對故障而進行設計 。在這方面已經出現了許多優秀的模式與實踐，不僅能夠幫助你從意外的故障情況中進行恢復，還能夠確保當意外發生時讓應用程序能夠優雅地退化。Netflix提供了 大量的工具 對故障與延遲情況進行模擬，以幫助他們創建cloud native的應用。
想要理解怎樣架構與設計cloud native的應用程序，閱讀與學習 十二要素方法 是一種很好的上手方式。十二元素方法提供了一系列元素，可以在創建交付為服務的現代化軟件時應用在任何編程語言中。
現在讓我們來回顧一下十二元素原則中的部分內容，看看它是如何幫助我們架構cloud native的應用的。“所有的進程都必須是 無狀態且無共享的 ”，無論是用于保存狀態還是其它原因而存在的數據，它都會限制某個進程成為分布式并且輕易地實現水平伸縮的能力。這就意味著你在某個進程的架構中不應預期某個數據片段會被持久化，而是使用某種附加的服務在進程之外將所有數據進行持久化，例如某個數據庫或其它數據存儲系統。
另一個基本原則是“ 依賴應當被顯式地聲明并且進行隔離 ”。在實踐中，這就意味著應用程序本身對于運行的環境是不可知的，除了已經顯式聲明的工具或庫之外不會使用其它任何外部依賴。與依賴的定義與隔離相關的一點在于： 配置文件中保存的內容對于每個執行環境都是獨立的 ，例如開發環境與生產環境上的認證信息。無論是連接字符串、身份認證還是不同的主機名都應保存在某種類型的配置文件中，并與使用它的代碼區分開來。以上只是一部分模式與實踐的示例，為了讓所創建的現代化應用能夠適用于在云環境中進行部署，了解這些模式與實踐是十分必要的。
你能做些什么
在開始下一個項目之前，請確保你和你的團隊都已經充分地了解了什么是滿足十二元素的應用，可以在 十二元素應用 網站上獲得更多的信息。
現代化應用的未來
那么打造cloud native應用的下一步是什么呢？在軟件工程中，有些新興的趨勢與技術正在熱火朝天的發展中。在 CenturyLink Labs ，我們已經開展了 容器化方面的工作 ，對于容器在架構、分布式以及部署軟件方面未來所扮演的角色進行了研究。容器正在變得越來越流行，在應用程序容器化之外，它就變得非常容易打包、發布并且隨處運行。與傳統的虛擬化技術不同，容器在應用程序層面提供了一個輕量級的虛擬化功能，因此它能夠更充分地利用一點一滴的可用能力。
容器的另一個優點在于它們能夠快速地啟動與中止（次秒級），這樣一來，只需簡單地啟動新的容器，就能夠實現水平伸縮與故障恢復了。而快速啟動與中止的能力正是十二元素應用的核心原則之一，即 易處理性 （disposability）。雖然容器并沒有涵蓋這方面的細節，但確實是因為容器的能力讓易處理性的實現變得非常容易。
IBM在一篇優秀的論文中對于 虛擬機的性能與Linux容器 進行了詳細的說明，如果你想要對容器與VM的能力進行比較，可以在這篇論文中找到大量的細節對比。
容器承諾它們能夠帶來更快的速度、成本的節約以及靈活性。它們也為軟件的架構帶來了一些新的思想，例如 使用短期的容器實現異步處理及工作流 。如果你對容器在這方面的應用感興趣，請參考一下CenturyLink Labs發布的 dray.it項目 。
你能做些什么
如果你還沒有開始學習容器技術，網上有大量的資源可以參考，例如 Docker 以及 CenturyLink Labs的博客 。也可以考慮在你的公司內部進行一次概念驗證，以獲得一些實際的動手經驗。
不可變基礎設施及部署
由于容器的出現，使得另一個新興的實踐在軟件工程社區內產生了大量的討論與爭辯，這就是不可變基礎設施與部署的概念。這一實踐是指永遠不要改動運行中的基礎設施或應用程序，而總是將應用或基礎設施銷毀后再重新生成。但是為什么要這么做呢？
從根本上說，原因是十分簡單的：比起創建新的內容，對已有的內容進行變更并追蹤這些變更要更加困難，它要求你對于某個復雜系統中的一切變量都充分理解并且具有控制權。對于小型應用程序來說這一點或許問題不大，但大多數現代化的復雜應用程序都是通過特性與補丁的無數次迭代混合而成的。在這種復雜應用中進行手動變更幾乎是不可能的。因此，要點在于整個系統必須處于一種“已知”的狀態，具體來說就是一種經過了充分測試的環境，并且你能夠在任意一種環境中輕易地重建整個系統。
你能做些什么
如果你在配置管理工具（Puppet、Chef、Ansible等等）方面還沒有投入過多的精力，那么你可以考慮學習不可變基礎設施與部署的實踐，這種方式或許更易于讓系統保持在一種已知的狀態，同時對于部署的速度、應用的穩定性與可測試性都有所幫助。
微服務
我們最后討論的一種趨勢是基于微服務架構的興起。微服務是一種面向服務的模型，應用程序中的每一種細分功能都被分解為一個獨立的自包含程序（即服務）。這意味著多數現代web應用都至少需要操作10個以上的微服務。容器再度體現出它的不凡功用，它能夠簡化應用初始時的生成操作，并提供了高度的封裝能力。
不過，微服務并非分布式應用架構的一劑靈丹妙藥，人們最終意識到這一架構通常只在某些情況下能夠發揮作用。它主要針對的情形是應用程序本身與團隊非常龐大，并且大多數開發者都在一個代碼庫中進行工作的復雜性已經開始影響到了團隊的生產力。如果你也遇到了這種問題，那么將你的架構重構為微服務或許是個好點子。在開始設計下一個特性的時候，不要將它加入已有的代碼庫中，而是將其分解為一種微服務。然后逐漸讓你的應用逐漸演化，從一體性架構或面向宏服務的架構分解為微服務應用。
將系統分解為較小的塊，這種做法比起一體性的應用更易于進行錯誤診斷、變更以及迭代。而不同的成員也可以專注于不同的微服務所提供的特定功能。
你能做些什么
如果你也體會到大型的代碼庫與大型團隊所帶來的問題，那么多學習一些微服務方面的知識。可以在這個演講中了解微服務的優勢與陷阱：“ Gilt的大規模化：從一體性Ruby應用轉為分布式Scala微服務架構 ”。對于任何一種新興的架構范式來說，都需要理解其中的權衡之處，微服務也不例外。在Martin Fowler的一篇優秀博文“ 一體性優先 ”（Monolith First）中，他談到了以微服務的方式設計一個全新的應用時存在的各種陷阱。
學習與探索
了解新興技術、模式或實踐的權衡之處是十分重要的。世上沒有免費的午餐，雖然有些技術或實踐能夠在某些方面帶來一些改進，但很可能會讓其它方面變得更加復雜。以上所談到的新趨勢大多還不具備成熟的工具。軟件企業應當始終對新興技術的權衡做到充分理解，通過在實際應用中的概念驗證，對這些技術進行持續地測試、探索與學習。同時軟件企業還需要設計專門的人員，讓他們專門負責了解這些新興技術，以及它們潛在的益處與影響。
在未來的幾年中，cloud native應用、應用容器、不可變基礎設施與微服務等技術注定將對現代化應用的創建、交付與運維產生實質性的影響，它們將對改進每個商業機構的基礎成本、效率以及靈活性起到關鍵的作用。
關于作者
Ross Jimenez 相信偉大的人造就了偉大的技術。他在web方面的經驗已經超過20年，曾經在Hewlett-Packard、Compaq Computer與Sandia National Laboratories等公司擔任過技術領導職位。他目前在CenturyLink Innovation Labs擔任工程總監。