什麼是AWS應用模式？

雲原生方法不僅僅是關於計算能力和雲端服務,一味「設置好就忘了它」的態度是行不通的。雲原生環境中有太多移動的零件,複雜度也非常高。相反,這種方法需要持續測試、優化和改進。這正體現在DevOps方法論中的兩個關鍵短語:持續整合和持續交付。

然而,要實現這一點,需要制定應用程式模式的策略性定義,來規範雲原生應用程式的構建和交付方式,而不是一次性的努力。由於AWS是領先的雲端供應商,我們應該討論哪些應用程式模式與AWS平台相關。在AWS應用程式模式方面,有許多需要考慮的方面,我們將在這裡介紹。

卓越運營

應用程式模式的最佳起點是致力於卓越運營。通常,術語「Ops」用於識別IT團隊,但在這種情況下,卓越運營落在Dev、QA和Ops團隊的肩上。在跨職能的DevOps團隊中,每個成員都應該在每一個小任務中追求卓越運營。

在其關於卓越運營的白皮書中,AWS鼓勵其用戶將運營視為代碼。這有助於避免人為錯誤、自動化複雜流程,並在發生錯誤時快速輕鬆地回滾。根據AWS的說法,失敗是學習的機會。他們甚至建議在部署之前進行「預先剖析」,試圖預測潛在的失敗點。

AWS Trusted Advisor是一個有用的工具,可以在團隊內實現這種問責制和共同責任。它會檢查並審查您的新舊AWS工作負載,尋找節省成本、提高性能、加強安全性或遵循最佳實踐來擴展運營的機會。

安全性

安全性是一種不可協商的模式。「DevOps」一詞啟發了另一種變體,稱為DevSecOps,這正體現了這一事實。安全運營在談論DevOps時處於中心位置。

有趣的是,做好DevSecOps實際上會在團隊之間帶來更多自由、靈活性和信任。這與傳統的安全方法不同,傳統方法會造成孤島、扼殺創造力並減緩創新步伐。安全性現在是拼圖的關鍵部分,而不是事後考慮的事情。AWS有許多基於機器學習的安全解決方案,如Macie,可以自動識別和保護個人身份信息(PII)。

除此之外,使用AWS IAM配置基於角色的訪問控制也很重要,可以更好地控制誰或哪些應用程式可以訪問數據,以及訪問的時間長度。訪問控制列表管理對AWS S3存儲桶中存儲的數據的訪問。

新聞中充斥著由於安全政策和訪問控制薄弱而導致的數據外洩事件。資本一號就是一個最近的數據外洩事例,影響了其100萬名用戶。雖然雲端安全性比以前更複雜,但AWS擁有必要的工具和系統。現在看組織是否能實施一種防止數據被濫用的安全策略了。

可靠性

如今,由於潛在的收入損失,人們對停機時間的容忍度很低。由於賭注如此之高,任何應用程式管理人都會將可靠性放在優先考慮的模式之列。AWS有多種報告和健康監控工具,可以讓您時刻掌握應用程式的脈搏。

微服務等架構模式可以通過將單體應用程式分解為更易於管理的服務來提高彈性。這種「分而治之」的方法可帶來更高的可用性,這對於SaaS應用程式至關重要。

混沌工程等模式有意殺死隨機實例和服務,並迫使DevOps團隊為每種情況找出解決方案和備份。

應用程式效能

隨著數據的爆炸式增長,應用程式總是要處理大量需要傳輸、存儲和處理的數據。應用程式的性能取決於三個因素:後端數據存儲層、中間件組件和前端。

後端數據層是性能最關鍵的組件。選擇正確的存儲格式、數據庫類型、存儲設備和組織模式都有助於提高數據訪問速度。AWS提供了令人驚嘆的存儲服務陣列,包括S3、RedShift、Aurora和Glacier。AWS為其用戶提供了各種存儲解決方案,都應該考慮使用以改善數據管理。

AWS正在設計新的方式來查詢大型數據集,而不會給您現有系統帶來負載。RedShift Spectrum就是一個很好的例子,它是一種「最小化需要擴展RedShift新節點的方式,這可能會很昂貴」。如果您仍然不想自己管理任何RedShift集群,AWS Athena是一個很棒的無伺服器替代方案。

它為您提供了所需的一切功能,可以在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應用程式模式的策略。

正如我們在這裡看到的,應用程式模式是百百種,但它們都建立在彼此之上。如果缺少任何一個支柱,組織就無法實現雲原生應用程式的目標。另一方面,如果他們對這些應用程式模式中的每一個都深思熟慮,組織就能交付前沿的應用程式,隨著時間的推移,這些應用程式只會變得更好。