幾年前,我們遇到了一個有趣的問題。我們是一家完全遙距的公司,所有軟件都在雲端中。我們還有一套 Spring Boot 應用程式,在容器上運行,並具有基礎架構為程式碼。但我們需要業務靈活性。
全球就業市場發展迅速,對新產品總有需求。我們必須想辦法保持我們在業界的領先地位。
我們是一家具有大膽策略的科技公司
在2022 中,我們建立了一個 ADR(架構決定記錄),上面寫著:"serverless-first 和 containers-as-needed。"並引發了近 40 工程團隊的辯論。
讓我們先解釋一些術語
Serverless-first 不僅是功能即服務。它也是一群來自雲端供應商的管理服務,這些服務:
-
不管理基礎架構,降低營運開銷
-
根據需要進行縮放,包括縮放為零,使其完全具有彈性
-
具有彈性定價(您只需為使用的部分付費)
在 G-P 中,無伺服器優先是指我們使用 AWS Lambda、EventBridge、步驟函數、法蓋特、SQS、SNS、應用程式設計介面 閘道、S3、DynamoDB 等。
無伺服器優先意味著當我們選擇運算、儲存空間、通訊或類似的解決方案時,我們希望團隊開始使用無伺服器選項。重要注意事項:如果無伺服器服務無法滿足需求,團隊應該回顧較重的服務,這是需要更多營運投資的服務。
"Containers-as-needed" 澄清了無伺服器優先並不代表只有無伺服器。有時候我們需要容器 (例如安裝COTS 軟體產品)- 這是沒問題的。
優先客戶的技術策略
我們以靈活的步伐,以滿足客戶和用戶的需求。像 Lambda、S3 和 DynamoBD 這樣的服務具有令人難以置信的彈性和速度。透過卸下無差別的繁重工作,我們可以花更多時間為使用者建立功能,而不是處理一般的基礎架構配置。
G-P 的一個關鍵原則是:" 你構建它,你運行它。"我們的團隊擁有他們的軟件。因此,我們不只是將軟件丟在牆上給 DevOps 團隊。
無伺服器優先」的優點
無伺服器本質上是事件驅動的。
我們的架構完全是事件驅動的。通過使用 EDA(事件驅動架構),我們可以擴展我們的組織和軟件。無伺服器強制我們保持小的爆炸半徑,並通過事件以完全雲端原生方式進行通訊。
使能限制
作為全球就業平台,我們認真考慮合規。我們的雲端基礎架構設計完善,並採用多帳戶策略,可區分工作負載並自動符合雲端規範。無伺服器控制佈建雲端資源的方式,協助我們實施高標準。
卸載工作
我們的雲端供應商負責管理我們的無伺服器服務。AWS 整合、保護、調整、啟用和維護的單一組建塊可讓我們更加專注於客戶的價值鏈。
架構完善的工作負載
我們建立的每個工作負載都會使用 AWS 精心架構架構進行審查。我們專注於規模、安全性、可靠性和成本最佳化,以確保不僅達到而且超越我們的 SLA(服務等級協議)。隨著我們持續與雲端環境進步,這使我們的工程團隊能力。
關於我們的團隊
我們的技術策略具有雄心勃勃,這使其具有挑戰性。許多工程師沒有在無伺服器架構(或分散式架構)中工作過。過渡到無伺服器架構並非易事,我們尋找的工程師必須能適應學習、大規模思考,並能按步就班。
有些工程師對於無伺服器(serverless)一詞並不確定(是的,我們知道有伺服器),因為這種方法不只是在函式中寫程式碼。我們的策略需要對經典的雲原生原則採取整體性的方法。
結果
我們在兩年內取得了非凡的進展。現代化有許多好處(請參閱我們關於 AWS/雲端現代化的已知商業價值的文章)。具體來說,我們觀察到以下幾點:
1.速度:我們分解系統的方式使團隊和產品能夠獨立創新和發展。這對業務敏捷性有很大的影響。
2.合規性:我們使用 AWS 良好架構架構來審查所有工作負載。由於我們使用許多 AWS 託管服務,因此我們可以依靠它們的卓越營運,從高品質的地方開始。
3.系統思考:我們必須將許多流程標準化,這樣才能推理出系統、可靠性和商業價值。我們不會花時間在低價值的元件上。
4.創新:無伺服器意味著一切都是應用程式設計介面。這種強制約束需要應用程式設計介面優先的方法。當我們將自己視為一個平台時,我們可以通過 應用程式設計介面 輕鬆連接系統來達到新的創新水平,例如將 G-P Gia™ 插入新的知識庫中。
5.所有權:AWS 擁有我們的基礎架構,但我們擁有我們的業務領域。無伺服器優先與領域驅動設計迫使我們專注於業務問題。這使能夠清楚掌握能力的擁有權。
Serverless-first 不一定更快,但卻更有利。我們寧願優化系統速度,而非個別開發人員的速度。無伺服器優先 (Serverless-first) 並不是要使用函式,而是要思考「程式碼是負擔」。系統就是資產"。我們要寫的程式碼越少,就越能考慮和塑造我們正在建立的商業系統。
在分享我們的故事時,我們的工作速度會變得很明顯,這是無伺服器優先的直接結果。敬請期待。


