什麼是 AWS 應用模式？
雲原生方法不僅僅關於計算能力和雲服務。採用雲原生的態度不能是“設置了就忘掉它”，因為其中有太多變數，而且複雜性極高。相反，這種方法需要不斷的測試、優化和改進。這在DevOps方法論的兩個關鍵詞句中得到了體現：持續整合和持續交付。
然而，要使之成為現實，需要採取戰略方法來定義應用程序模式，這些模式將規範雲原生應用的構建和交付方式，而不是一次性的努力。由於AWS是領先的雲提供商，我們應該討論與AWS平台相關的應用模式。在考慮AWS應用模式時有許多方面需要考慮，我們將在這裡涵蓋它們。
操作卓越
對於應用模式而言，最好的起點是致力於操作卓越。通常，“Ops”一詞用來指代IT團隊，但在這種情況下，操作卓越的責任落在開發、QA和Ops團隊的肩上。在跨功能的DevOps團隊中，每個成員應該在每一步甚至是最小的任務中都追求操作卓越。
在其關於操作卓越的白皮書中，AWS鼓勵其用戶將操作視為代碼管理。這有助於避免人為錯誤，實現複雜流程的自動化，並在發生錯誤時快速輕鬆地回滾。根據AWS的說法，失敗是學習的機會。他們甚至建議執行“預先死亡分析”，試圖在部署前預測潛在的失敗點。
AWS受信任顧問是一個有用的工具，它使團隊內部的責任和共享責任成為可能。它檢查並審查您的新的和現有的AWS工作負載，尋找節省成本、提高性能、加強安全或遵循最佳實踐以擴展操作的機會。
安全性
安全性是一個不可談判的模式。術語“DevOps”啟發了另一種變體“DevSecOps”，這表明了這個事實。當談論到DevOps時，安全操作佔據了中心舞台。
DevSecOps有趣的地方在於，如果做得正確，它實際上會在團隊之間帶來更多的自由、靈活性和信任。這不同於傳統的安全措施，那種做法創造了隔離，抑制了創造力，並減緩了創新速度。安全現在是謎題的關鍵部分，不是事後才考慮的。AWS擁有許多基於機器學習的安全解決方案，如Macie，它能自動識別並保護個人身份信息(PII)。
與此同時，使用AWS IAM配置基於角色的訪問控制對於更好地控制誰或哪些應用程序訪問數據以及訪問多久非常重要。訪問控制列表管理對存儲在AWS S3桶中的數據的訪問。
新聞上充斥著因安全政策和訪問控制薄弱而導致數據泄露的實例。資本一號的數據泄露就是一個近期的例子，影響了1億用戶。雖然雲安全比以往更加複雜，但AWS擁有必要的工具和系統。組織有責任實施一個安全策略，以防止他們的數據被濫用。
可靠性
如今，對於停機時間的容忍度很低，因為這可能導致收入損失。鑑於利害攸關，可靠性是任何應用程序管理者的優先列表上的重要模式。AWS擁有多個報告和健康監控工具，讓你不斷掌握應用程序的脈搏。
像微服務這樣的架構模式通過將單體應用分解成更易於管理的服務塊，實現了更好的韌性。這種“分而治之”的方法導致更高的可用性，這對於SaaS應用至關重要。
像混亂工程這樣的模式尋求故意停用隨機實例和服務，迫使DevOps團隊為每種情況找出解決方法和備份。
應用性能
隨著數據的爆炸式增長，應用程序總是在處理大量的數據傳輸、存儲和處理。一個應用程序的性能取決於三個因素：後端數據存儲層、中間件組件和前端。
後端數據層是性能方面最關鍵的組件。選擇合適的存儲格式、數據庫類型、存儲設備和組織模式都有助於提高數據訪問速度。AWS提供了驚人的存儲服務陣容，包括S3、RedShift、Aurora和Glacier。AWS為其用戶提供了各種存儲解決方案，所有這些都應該被考慮以改善數據管理。
AWS正在設計新方法來查詢大型數據集，而不會對您現有的系統造成負擔。RedShift Spectrum就是一個例子。這是一種“最小化需要通過新增節點來擴展Redshift的需求，這可能很昂貴”的好方法。如果您仍然不想自己管理任何RedShift集群，AWS Athena是一個很好的無服務器(serverless)替代方案。
這讓您擁有所需的全部能力，以在S3中查詢大型數據集，而無需維護任何自己的集群。
這種按使用付費的模型正在遍及整個AWS堆棧，像ECS和Fargate這樣的服務提供完全無服務器的體驗，當操作規模擴大時操作容器。從AWS Lambda開始的事物正在迅速流行起來，許多AWS服務，就像上面提到的那些，使無服務器體驗成為可能，著重於應用性能。
成本優化
轉向雲計算時，定價完全不同。與支付永久許可證不同，您現在支付每一個小資源所使用的小費用。雖然單獨看來很小，但您很快就會意識到，如果不仔細關注支出，雲成本可以很容易地上升。
隨著在雲中擴大操作，成本優化是必要的。成本優化包括尋找更有效的服務，無論是在相同的供應商平台還是不同的平台。最起碼，它可能需要一種提升和轉移的方法，從昂貴的舊基礎設施過渡到便宜的新替代品。例如，在相同的平台內，將工作負載從虛擬機轉移到容器再到無服務器，可以顯示出巨大的成本節約，因為容器和無服務器通常比虛擬機更具成本效益。
利用這一領域專家的專業知識是有益的。他們理想情況下應該是那些使用AWS多年、瞭解優良架構最佳實踐並找到了從相同預算中削減成本並獲得更多價值的方法的人。
應用模式使擴展性成為可能
微服務應用採用了可插拔架構。這使得它們能夠輕鬆地與外部應用集成。通常，基於API的通信模式最為常見。AWS API Gateway是一項服務，它為AWS應用管理API設計。在某些情況下，選擇SDK可能是更好的選擇——例如，當您需要對開發者體驗和整合有更多控制時。知道何時選擇哪個選項很重要。
應用模式使可移植性成為可能
可移植性是指在不中斷其功能的情況下，跨實例移動工作負載的能力。隨著實例的變化，它們支持的工作負載不應受到影響。只有在工作負載與運行它們的基礎設施之間有一個清晰的分離層時，這才是可能的。
應用模式使向左轉移成為可能
DevOps方法論以鼓勵軟件交付的向左轉移方法而聞名。這意味著不僅是開發人員，QA和運維團隊也會參與應用程序的設計和開發階段。這促進了團隊間更深入的合作，打破了孤島。
向右轉移的方法同樣適用。向右轉移意味著開發者對他們寫的代碼負責。他們與運營團隊一樣是應用程序韌性和他們引入系統的錯誤的共同擁有者。將所有權和責任放在它應該屬於的地方的做法，對DevOps團隊非常有益。
AWS使用諸如CodePipeline、CodeCommit和CodeDeploy等工具促進管道管理。它們各自執行相似但互補的角色，幫助構建CI/CD管道。它們使在AWS平台內開始使用CI/CD變得容易。
對於在雲旅程中走得更遠的組織而言，AWS的管道管理工具對於像GitOps這樣的事情來說可能顯得過於簡單。相反，他們會想要尋找AWS之外的工具，如Jenkins X或Weave Flux，這些工具是以GitOps自動化為目的設計的。無論是簡單還是進階路線，管道都會帶來比手動開發過程更大的好處。
結論
雖然工具使實現有用的應用模式成為可能，但它們本身是無效的。應用模式需要一個深思熟慮的策略和一個開始的方法。只有在有了策略之後，您才能決定使用哪些工具。有了堅固的策略，這裡提到的任何工具都可以被其他更好的工具替換，結果將是相同的。重要的是不要被下一個閃亮的工具分散注意力，而應該密切關注實施AWS應用模式的策略。
正如我們在這裡看到的，應用模式多種多樣，但它們都是相互建立的。如果缺少了這些支柱中的任何一個，組織將無法實現雲原生應用的目標。另一方面，如果他們仔細考慮這些應用模式的每一個，組織將交付前沿應用程序，隨著時間的推移，這些應用程序只會越來越好。
