数年前に興味深い問題がありました。 当社は、クラウド上のすべてのソフトウェアを備えた完全なリモート企業です。 そして、Infrastructure as Code のコンテナーで実行する Spring Boot アプリケーション一式がありました。 しかし、ビジネスの俊敏性が必要でした。

世界の雇用市場は急速に動いており、常に新製品に対する需要があります。 業界全体でリードし続ける方法を見つけなければなりませんでした。

大胆な戦略を持つテクノロジー企業である

2022年、私たちはADR（建築決定記録）を作成し、その中で、Raffenseserverless-firstとコンテナー-as-neededと述べました。 また、 40 近くのエンジニアリングチームで議論が繰り広げられました。

まず、いくつかの用語について説明します。

サーバーレスファーストは、サービスとしての機能だけではありません。 また、クラウドプロバイダーのマネージドサービスグループでもあり、以下のことを行います。 

  • インフラストラクチャを管理しないことで運用オーバーヘッドを削減

  • 必要に応じて拡張します。これには、完全に弾力性を持たせるためにゼロにスケーリングすることも含まれます。

  • 価格に弾力性がある（使用するものに対してのみ支払う） 

G-P では、サーバーレスファーストとは、AWS Lambda、EventBridge、Step Functions、Fargate、SQS、SNS、API Gateway、 S3、DynamoDB などの使用を指します。

サーバーレスファーストとは、コンピューティング、ストレージ、メッセージングなどのソリューションを選択する場合、チームはサーバーレスオプションから始めてほしいということです。 重要な注意：サーバーレスサービスがニーズに合わない場合、チームはより重いサービス、つまりより多くの運用投資を必要とするサービスにフォールバックする必要があります。

“Containers-as-need”は、サーバーレスファーストはサーバーレスのみを意味するものではないことを明らかにしています。 コンテナが必要なとき（ COTSソフトウェア製品のインストールなど） はありますが、問題はありません。

顧客を優先する技術戦略

当社は、顧客とユーザーのニーズを満たすために機敏なペースで動きます。 Lambda、 S3、DynamoBDなどのサービスは、信じられないほど回復力があり、高速です。 未分化の重量物の荷下ろしにより、一般的なインフラストラクチャ構成ではなく、ユーザーの機能構築により多くの時間を費やすことができます。

G-P における重要な原則は、以下です： \"Ratem\"あなたはそれを構築し、あなたはそれを実行します。 私たちのチームはソフトウェアを所有しています。 ですから、私たちはソフトウェアを壁に投げるだけでなく、DevOpsチームに投げ込むのです。 

“サーバレスファースト”の利点

サーバーレスは本質的にイベント駆動型です。

当社のアーキテクチャは、完全にイベント駆動型です。 EDA（Event-Driven Architecture）を使用することで、組織とソフトウェアの両方を拡張できます。 サーバーレスは、小さなブラスト半径を維持し、イベントを介して完全にクラウドネイティブな方法で通信することを強制します。

制約を有効にする

global employment platform 企業として、私たちは コンプライアンス を真剣に受け止めています。 当社のクラウドインフラストラクチャは十分に設計されており、ワークロードを分離し、クラウドコンプライアンスを自動化するマルチアカウント戦略を使用しています。 サーバーレスは、クラウドリソースのプロビジョニング方法を制御することで、高い基準を適用します。

作業のオフロード

当社のクラウドプロバイダーは、サーバーレスサービスを管理します。 AWS が統合、セキュリティ保護、調整、有効化、保守する 1 組のビルディングブロックにより、お客様のバリューチェーンの高まりに集中できるようになります。

よく設計されたワークロード

私たちが作成するすべてのワークロードは、AWS Well-Architected Framework でレビューされます。 当社は、SLA（サービスレベル契約）を満たすだけでなく、それを上回ることを保証するために、スケール、セキュリティ、信頼性、コストの最適化に重点を置いています。 これにより、クラウド環境で進化し続けるエンジニアリングチームが強化されます。 

チームについて

当社の技術戦略は野心的であり、それがそれを困難にしています。 多くのエンジニアは、サーバーレスアーキテクチャ（または分散アーキテクチャ）で働いていません。 サーバーレスアーキテクチャへの移行は容易ではなく、学習、大きな思考、ペースの速い動きに慣れたエンジニアを探しています。

一部のエンジニアは、サーバーレスという用語について確信が持てません（サーバーがあることはわかっています）。なぜなら、このアプローチは関数にコードを書く以上のものだからです。 当社の戦略には、従来のクラウドネイティブの原則に対する包括的なアプローチが必要です。

結果

2年で驚異的な進歩を遂げました。 近代化には多くの利点があります（ AWS / クラウド近代化の既知のビジネス価値に関する記事を参照）。 具体的には、以下を観察しました。

1. スピード: システムを分解する方法により、チームと製品は独立して革新と進化を遂げることができます。 これは、ビジネスの俊敏性に大きな影響を与えます。

2. コンプライアンス: AWS Well-Architected Framework を使用して、すべてのワークロードをレビューします。 当社は多くのAWSマネージドサービスを使用しているため、その卓越した運用に頼り、高品質の場所から始めることができます。

3. システム思考：システム、信頼性、およびビジネス価値についての理由が分かるように、多くのプロセスを標準化する必要がありました。 価値の低いコンポーネントに時間を費やすことはありません。

4. イノベーション：サーバーレスとは、すべてがAPIであることを意味します。 この強制的な制約には、APIファーストのアプローチが必要です。 自分自身をプラットフォームと考えると、 G-P Gia™ を新しいナレッジベースにプラグインするなど、APIを介してシステムを簡単に接続することで、新しいレベルのイノベーションを達成できます。

5. 所有権：AWS はインフラストラクチャを所有していますが、ビジネスドメインを所有しています。 ドメイン主導の設計によるサーバーレスファーストは、ビジネス問題に焦点を絞ることを余儀なくされました。 これにより、能力の所有権が明確になります。

サーバーレスファーストは必ずしも速いわけではありませんが、より有益です。 個々の開発者の速度よりも、システムの速度を最適化する方がよいでしょう。 Serverless-first は、関数を使用するということではなく、Code は責任です。 制度は資産である。 私たちが書くコードが少なければ少ないほど、私たちが構築しているビジネスシステムを検討し、形成することができます。

私たちのストーリーを共有すると、私たちが取り組んでいるスピードが明らかになり、サーバーレスファーストの直接的な結果になります。 ご期待ください。