最近，AWS在一技術系列文章（共3篇）中展示了通過構建無服務器後端來加速迭代Web應用程序以及跟蹤產品需求變化的優勢。這些開發方法和架構帶來了靈活性，但增加了與雲供應商服務的耦合。
AWS高級開發者佈道師James Beswick以州立公園的“Happy Path” Web應用程序爲例，解釋了這個項目的目標：
本系列介紹如何構建靈活的解決方案來適應用戶需求的變化。需求可能會快速發生變化是構建現代Web應用程序所要面臨的一個挑戰，對於那些正在尋找適合其產品市場的新應用程序來說尤其如此。很多開發團隊在一開始只構建滿足一組需求的產品，但很快就發現需要構建具有不同特性的產品。
第一個版本允許終端用戶上傳地圖和照片，在後續迭代中添加了更復雜的功能，並轉向一個全新的市場——餐館。代碼可以在GitHub存儲庫中找到，並可以使用AWS無服務器應用程序模型，這是一種用於構建無服務器應用程序的開源框架。
API層通過調用Lambda函數來完成任務，在存儲層存儲和獲取數據，在Amazon S3上部署二進制文件，在Dynamo DB裏存儲元數據。業務邏輯被封裝在AWS Step函數工作流中，Amazon CloudFront則爲最終用戶提供內容。
架構總覽，來源：https://aws.amazon.com/blogs/compute/using-serverless-backends-to-iterate-quickly-on-web-apps-part-1
第一篇文章介紹瞭如何部署應用程序、測試上傳過程和架構評審。第二篇文章解釋瞭如何使用AWS Step函數(一個用於排序AWS Lambda Function的無服務器函數編配器），以及如何部署用於調整鏡像大小的自定義工作流。在第三篇（也是最後一篇）文章中，作者展示瞭如何引入更高級的帶有自定義分支和鏡像調節的工作流。系列文章以一個示例結束，該示例從最初的想法轉到一個不一樣的市場，並能夠重用大部分邏輯。
來源：https://aws.amazon.com/blogs/compute/using-serverless-backends-to-iterate-quickly-on-web-apps-part-1
在另一篇文章中，James Beswick在分析無服務器應用程序中的業務邏輯流時評論道：
好的無服務器應用程序具有固有的靈活性，可以在用戶需求變化時更快地添加新功能。這是因爲工作流的各個部分都是專門化的、鬆散耦合的。這有助於加快迭代開發，還有助於減少在設計發生變化時需要重寫的代碼數量。
雖然本系列介紹AWS技術並依賴於AWS的無服務器應用程序模式，但類似的方法可以在任何爲無服務器工作流提供功能和編排的雲平臺上使用。例如，可以使用Azure Durable Function或Cloud Composer（這是谷歌雲平臺的服務，基於開源的Apache Airflow）來實現迭代。
正如Nick Gottlieb所建議的那樣，依賴無服務器技術並將開發人員從服務器端工作中抽離出來，並不一定要將服務與雲提供商綁定。對於一些開發者來說，迭代速度變慢纔是他們更擔心的，正如Lumigo的開發者佈道師Yan Cui指出的那樣：
在你忙於構建自己的雲計算解決方案時，一個比你更快進入市場、迭代速度更快的競爭對手會在亞馬遜把你鎖在自己的王國之前就把你鎖在這個市場領域之外。
原文鏈接：