「長期規劃」真的無效了嗎？對此，我更傾向持保留意見。自從人類步入快速發展的數字化時代，「可確定的未來」在很多時候確實已成為一種奢侈，就如同新冠疫情絕不會是最后一只黑天鵝，但這并不代表不再「長期規劃」有效。相反地，現在企業的「長期規劃」正在回歸到更為基礎與核心的業務本質，也就是如何在變革的常態中，保持業務競爭力與創新的活力，讓企業具備應對變化的韌性。

事實上，即使在去年商業活動最舉步維艱的那段時間，我們仍看到許多具備靈活性的企業快速適應了新的環境，甚至發掘出新的成長機會。相信很多人和我一樣好奇，這些企業的數字化基礎設施如何能在極短的時間去適應與過去迥異的業務需求。我們很快得到了答案──從去年開始，「現代化應用」被越加頻繁地提及。

這意味著，更多的企業意識到現代化應用的敏捷性、通用性及擴展性等優勢，成為企業立足長期發展的「標配」。當你不知道變化將從何而來，也無法制定如同說明書一樣按部就班的發展計劃時，構建與業務互相搭配且更為敏捷的現代化應用架構，就成了面對不確定性的最佳解。

雖然有時候我們會用微服務、容器化、無服務器這類技術名詞去描述現代化應用，但必須強調的是，現代化應用及實現過程并不是技術和產品的機械化堆棧。企業對現代化應用的向往并不是因為其技術先進，而是為了適應業務需求并助力業務拓展，以不斷發現新的機會，或創造更好的產品和服務。

現代化應用：始于業務、終于業務

雖然現代化應用的價值來自一個長周期內對企業業務支持的「總量」，但基于與眾多用戶的溝通，我們發現現代化應用也同樣是他們立足當下的現實需求。舉幾個有代表性的例子：有些用戶會希望更少關注基礎設施管理，而是專注于業務本身；有些則希望軟件架構從反映企業組織架構轉變為反映業務邏輯；還有些用戶希望開發團隊花費寶貴精力所編寫的每一行代碼都符合業務邏輯。

總結而言，企業使用者需要現代化應用的核心原因之一，就是從設計、構建到管理都與業務緊密相關。現代化應用一定是緊緊圍繞著業務核心，正所謂「始于業務、終于業務」。

至于業務如何從現代化應用中受益，相信很多企業都有自己的看法和期待。在AWS眼中，現代化應用的基本特征，或者說優勢，體現在以下幾點：

一、敏捷性：快速開發、快速應用，并且能夠敏捷地迭代；

二、可擴展性：例如可擴展到數百萬量級的用戶，確保足夠的彈性以保障業務拓展；

三、全球可用：這對于正在「出海」的企業尤為重要；

四、毫秒級的回應能力：并且能夠處理PB級、甚至EB級的數據。

今天，無論是提供給使用者的現代化應用服務，還是自己作為一家公司走過的現代化應用歷程，我們所有的迭代與創新都來自于用戶及亞馬遜自身的業務需求。這些寶貴經驗是AWS 15年持續引領現代化應用的重要基石，正如亞馬遜執行長Andy Jassy所說：經驗沒有壓縮算法（There is no compression algorithm for experience）。我們所有的探索都不白費，每一步都是經過踏實地累積而來。

1995年亞馬遜創立之初，所有的邏輯只在一個單體式應用里，也只有一個數據庫。隨著業務的拓展，到了2001年，亞馬遜進入了面向服務架構（SOA）階段，比如商品、訂單、服務等模塊都在那個時期成形。此后，亞馬遜進入了更多領域，產品迭代和客戶體驗迭代的速度越來越快，這些已經按照SOA拆分出來的模塊，自己又會變成超大的單體。所以2002年到2006年，亞馬遜正式啟動了微服務化架構。

為了支持新的應用架構方法，亞馬遜打破職級，將開發團隊重組為多個小型的自治團隊，規模小到每個團隊只能用兩個披薩就喂飽。我們讓每個「雙披薩團隊」集中開發一個特定的產品、服務或功能集，授權他們成為產品負責人，可以快速對他們負責的產品做出決策。從那時起，亞馬遜不只是從技術，而是包括從組織架構和管理策略，建立一整套微服務體系，團隊可以自行開發營運和迭代。

亞馬遜在建構高度可擴展基礎設施的成功拓展新的核心能力，這才有了AWS在2006年的成立。到2020年，亞馬遜已經有超過10萬個微服務，從起初每年部署幾十個功能，到現在可以每年部署幾百萬個功能。

過去15年來一直在現代化應用領域持續投入與創新。與AWS「同齡」的Amazon Simple Queue Service（Amazon SQS）至今仍被許多客戶采用。2012年我們推出了鍵值和文文件數據庫Amazon DynamoDB，這個可以隨著應用的拓展而幾乎無限擴展的無服務器數據庫，目前每天可以處理超過10兆個請求，在Amazon Prime Day期間一度達到每秒8,920萬次的峰值。

2014年推出的無服務器運算服務Amazon Lambda更是一個劃時代的創新。如果說我們90%的創新是基于客戶提出的具體需求，那么Amazon Lambda就屬于剩下的10%，此是根據客戶「只提出要實現什么目標」而進行的創新。此后，又推出適用于容器的無服務器服務AWS Fargate，和高效能關系數據庫Amazon Aurora──包括后來發布的Amazon Aurora Serverless V2，可在不到1秒的時間內擴展至支持幾十萬個數據處理交易，從而把客戶「希望從基礎設施管理中解放出來而專注于業務」的目標做得更極致。

什么時機、選擇何種實現路徑，仍由業務「做主」

企業的現代化應用轉型，是否有一些可遵循的脈絡？基于過往服務全球數十萬客戶的實戰經驗，總結三個可選擇的路徑，分別是：平移（Replatform）、重構（Refactor）和建構共享服務平臺（Shared Services Platform）。

在大多數情況下，這三個路徑將共同組成一個現代化應用架構的完整生命周期。因此，企業用戶在進行現代化應用轉型時，并非只取其一或遵守固定的順序。在什么時機、什么需求場景、選擇哪種路徑，最終要由企業特性和業務需求來做主。

「平移」通常是企業上云的第一步，即利用容器把本地數據中心的應用遷移到云端，快速實現現代化應用的架構、交付模式和營運模式。對使用者來說，平移的主要目的是把核心應用快速上云，利用云端具備彈性的特點簡化基礎設施營運并降低維護成本。例如在本地使用了Oracle或者SQL Server，就可以快速地將數據先搬到云端托管，暫時無需考慮數據拆分。

容器化是平移的利器，在這一路徑中扮演著相當重要的角色。今天云端托管的容器有80%都運行在AWS上，因為我們在容器的產品和服務方面帶給使用者更靈活的選擇。

而「重構」是透過微服務拆分、數據重構以實現應用基于業務邏輯的重構，從而獲取數據驅動下的敏捷性和創新力。重構過程中，微服務化是最重要的方法──把業務邏輯和數據透過API向其它團隊公開，打造一個高度解耦的架構。微服務的開發團隊可以獨立迭代、發布應用，大幅提升創新速度，同時最小化故障發生時的影響半徑。

重構階段往往是利用新技術的最佳時機。例如，在此階段企業可以優先考慮使用Serverless，讓「企業所寫的每行程序代碼都是應用邏輯」的愿景成真。而在AWS，Serverless并不僅僅是無服務器運算Lambda，而是提供給使用者一整套無服務器服務，來協助使用者開發基于無服務器的端到端核心應用。

從三年前開始，Comcast旗下的影音廣告技術公司FreeWheel開始將多個本地數據中心逐步遷移到AWS全球的基礎設施。FreeWheel透過采用Amazon Elastic Kubernetes Service（Amazon EKS）容器協調服務，在不改變現有架構的情況下實現應用遷移，讓系統獲得了資源彈性；使用Amazon Lambda無服務器運算打造高可用性的微服務，為各種規模的應用程序提供支持，使得系統更易于開發和部署。

一系列云端創新的行動，讓FreeWheel能夠在奧運會、Super Bowl、世界杯等10多個全球收視率最高的賽事活動期間，成功地支持所服務的一線媒體，順利因應2秒內激增100倍的超大流量，大幅提升維運效率并節省了超過50%的資源使用成本。

「建構共享服務平臺」則是為了實現現代化應用的規模化部署。

當企業的微服務達到一定規模，可能會面臨「沒有專門針對微服務應用快速部署營運平臺」的挑戰。建構共享服務平臺就是讓企業利用共享服務平臺標準化、自動化的營運能力，加速現代化應用開發的規模化，協助用戶專注于產品開發、提高生產力。

如何既能讓每個微服務團隊敏捷高效，又能讓其程序代碼部署管理更有一致性？AWS的AWS Proton是第一個針對容器和無服務器應用程序部署的完全托管服務。借助AWS Proton，營運平臺團隊可以提供統一管理的無服務器和容器的模板，使數百或數千支應用開發團隊無須自己管理和維護這些基礎架構，只需專注于開發業務邏輯程序代碼。企業只需按任意順序達成五個元素。

無論企業如何實踐以上三個路徑，最終目標都是為了建構「有效的」現代化應用，使其能夠真實有效地提升企業未來的敏捷性和創新速度。

為此，企業需要做到讓自身的現代化應用按任意順序去達成五個元素，其中既包括設計和建構方式，也包括管理模式的轉型。

五個元素敘述如下：

一、架構微服務化

微服務克服了單體式應用龐大、添加改進功能復雜等挑戰，應用程序由獨立組件組成，每個組件作為一個服務運行，實現一個特定業務功能，按照需求進行靈活更新、部署和擴展。在當下，微服務已經成為現代化應用「靈魂」般的存在。

二、數據庫專用化

應用現代化之后，資料和應用也可以解耦了。數據庫和微服務相輔相成，可以帶來多個好處：微服務數據量成長時只需變動相對應的數據庫，獲得更好的擴展性；可避免單體式數據庫故障而影響整個應用，容錯性更強；微服務可以自由選擇最適合業務需求的數據庫，靈活度更高。

三、自動化的軟件交付管道

當單個團隊獨立交付軟件，尤其是在手動交付時，彼此的協調性和質量一致性就成為挑戰。對此，我們采用的解決方案是標準化和自動化雙管齊下。首先，將軟件交付流程定義為最佳實踐模板，各個團隊都用模板配置基礎設施資源，確保正確起步；其次，透過自動發布管道，包括持續整合和持續部署（CI/CD），可以快速測試和發布大量程序代碼，最大限度地減少錯誤。

四、基礎設施無服務器化

當我們說「無服務器」時，我們指的是那些不需要基礎設施供應和擴展，具有內建的可用性和安全性，并使用按需付費模型的服務。無服務器能夠讓團隊從那些與業務沒有直接關連的基礎設施維護工作中解放出來，專注于創造更有價值的用戶體驗和創新產品。

五、安全特性整合化

在現代化應用中，安全功能內建于每個組件，隨版本變化自動測試和部署。這也意味著，安全不再只是安全團隊的責任，而是深入整合到開發生命周期的各個階段，工程、營運和合規團隊都要發揮作用。

寫在最后

以上是AWS對于現代化應用的一些觀點和經驗總結。我認為現在與大家深入探討現代化應用恰逢其時──企業對基礎設施敏捷性和彈性的高度需求是前所未見的，而作為連續11年被Gartner評為領導者的云端服務供貨商，AWS帶來的一整套現代化應用建構方案及方法論，也確實值得被關注和思考，因為這些探討都經過無數實際應用的檢驗，而且已被證明有效。

現代化應用轉型將是一個長期、持續的過程。在這趟旅途中，AWS也期待聆聽所有客戶的需求，并運用我們在云端服務領域卓越的廣度、深度和創新速度，為每一個客戶建構可支持未來長期業務創新的現代化應用架構。

（本文作者顧凡為AWS大中華區產品部總經理）