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