「Serverlessを導入するのは難しいですか？」
「サーバーレスを導入するのは難しいですか？」
シンプルな手順を理解して、サーバーレスの導入を成功させましょう
1年以上前、オーストリアのセンメリングでのハイキング中、私たちはトレイルの分岐点で迷ってしまいました。サインポストが曖昧だったため、モバイルを使って手がかりを探しました。複数のTwitter（X）通知の中で、Paul Johnston氏の記事Learning Serverless (and why it is hard)に言及するものが一瞬で過ぎ去りました。
普段ならすぐに読むでしょう。しかし、その場所と家族を森から案内する責任を考えると、サーバーレスのために風光明媚なセンメリングの朝を犠牲にする覚悟はありませんでした。
帰りに読んだところ、ポールの記事では、勇敢にも多くの問題に直面しています！もっと早く自分の考えを加えたかったのですが、Serverless Development on AWS. Building Enterprise-Scale Serverless Solutions（O’Reilly, 2024）という本を完成させるという責任があったため、1年後になってしまいました。今回は、学習に限定せず、全体的な視点でこの問題を見るために、自分自身の経験を活かしていくつかの考えを述べます。
この記事では、商業製品開発、データ駆動型アプリケーションの構築、AI、機械学習など、サーバーレス技術を使用したアプリケーション開発に成功するためのいくつかの要素について説明します。
The Serverless Book
AWSによるサーバーレス開発：企業規模のサーバーレスソリューションの構築
sbrisals.medium.com
車の運転は難しいですか？
- マニュアルトランスミッション車の運転は難しいですか？
- マニュアルトランスミッション車の運転を学ぶのは難しいですか？
答えは人によります。数年間運転してきた場合、最初の質問に対する答えは否定的なものになるでしょう。何年にもわたり、操縦に慣れており、それらを考えずに自然に行えるようになりました。
しかし、初心者の場合、2番目の質問に対する答えは明確に「はい」になるでしょう。運転を学ぶときには、協調を必要とする行動、順序に従った活動、並行して行わなければいけない観察など、考慮すべきことがいくつかあります。車と一緒に動いている間にこれらをすべて行わなければなりません。
ステアリングホイールを回す能力だけでドライバーとしての資格はありません。
自動トランスミッション車を考えてみると、ドライバーとしての活動は一部減少します。いくつかのアクション（クラウドプロバイダがサーバーレスの一部の重い作業を引き受けるように）は、車の機構が処理してくれます。
日常生活には多くの困難なことがありますが、それらを上達させるためにスキルを学び、確立された道筋に従います。サーバーレス開発も同様です。自動トランスミッション車のように少し簡単に聞こえるかもしれませんが、エンジンを始動してすぐに進んでいくわけではありません。
技術の中で間違ったやり方が多くあります。特にサーバーレスではそれが起こりやすいです。サーバーレスサービスを使用した複雑なイベント駆動アーキテクチャを構築することは簡単で時間もかかりません。しかし、モジュラーで観測可能で持続可能なソリューションの設計と開発には、知識と適切なスキルが必要です。これはサーバーレスが難しいことを意味するわけではありません。
テクノロジーでは、間違った方法が多くあります – 特にサーバーレスでさらに多くあります。
サーバーレスは、そのエコシステムを理解しない場合は難しいです。
車には様々なパーツがあります。車のエンジンは主に1つのユニットとして書かれていますが、いくつかのコンポーネントがあります。機能する車にはドライバー（ドライバーレスの場合を除く）が必要で、乗客を乗せます。これら全てが車のエコシステムを形成します。
しばしば、サーバーレスはアーキテクチャの設計図、Function as a Service（FaaS）またはフレームワークとして描かれます。私にとって、それはこれらのすべてを超え、通常私たちが想像する以上のものです。サーバーレスは、ある意味でテクノロジーのエコシステムです。サーバーレスを使用する私たち自身も、車の自動車エコシステムのようにそれに参加します。
画像に示されているように、サーバーレスのエコシステムにはいくつかの要素があります。サーバーレス技術は独自の特性をもたらします。クラウドプラットフォームとその管理されたサービスが基盤を形成します。開発プラクティス、ツール、フレームワークは価値を迅速にもたらすためのフローを可能にします。ビジネスステークホルダーはエンジニアと協力して顧客のためにサーバーレスのモダンな機能を構築します。これらすべてがそのエコシステムの一部です。
上記の描写の目的は、関数の書き方やインフラストラクチャツールについて議論する以外のことを考えさせることです。サーバーレスが組織やチーム、あなた自身にもたらす多様性を考えてみてください。サーバーレスと一緒に働くときは、あなたが複数の役割を果たすことになるためです。以下はリー・ギルモアのものより、次のような考えが過去よりも頻繁になります。私たちが成熟し、サーバーレスのエコシステムの一部になっていくにつれて。
サーバーレスは、間違ったマインドセットで始めると難しいです。
数年前、エンジニアがサーバーレスの旅についてのアドバイスを求めて連絡してきました。チャットを始めて数分後、彼が自分のLambda関数のロジックをクラウドに依存しない方法で実装し、組織の意思決定者が切り替えを望む場合には異なるクラウドプロバイダにすぐに展開できるようにしたいということが明らかになりました。
彼の意図を理解するために、非FaaSサービスへのアプローチやクラウドに依存しない方法について尋ねました。彼の説明は、何かの壮大な実装で六角形アーキテクチャのようなものでした！
通話の終わり近く、彼はまだ本番環境にサーバーレスのワークロードを展開していないことに気付きました！
上記のような考え方やアプローチは、取締役会を喜ばせるかもしれませんが、ビジネスへの課題や価値は評価されていません。企業は、サーバーレスなどの技術を採用して、速度を向上させ、フローを増やし、競争力を築きます。上記のようなマインドセットでサーバーレスに取り組むことは、蜃気楼を追いかけるようで、なかなか何も成し遂げられないどころか、近い将来何も成果を出せない状態になってしまいます。
エンジニアは、フレームワークが提供するマルチクラウドの構成を指摘して（または言い訳として）示すことがあります。実際のところ、ツールは誰でもそれらを使用できるようにその機能を提供しており、マルチクラウドの決定はフレームワークの提供するものに基づきません。こうした間違った戦略が価値を生み出さない場合、サーバーレスへの切り替えは難しい、混乱する、直感に反するといった声が聞こえてきます – Paulが記事で述べているように。
開発ツールは多くの場合、マルチクラウドの機能をサポートしていますが、フレームワークが提供するものを基にマルチクラウドの決定をするべきではありません。
サーバーレスは、簡単過ぎると思うと難しいです。
私はサーバーレスアーキテクチャの提案を聞き、承認するための会議に招待されました。エンジニアは綿密に作成された仮想ボードを提示し、アーキテクチャを説明しました。Lambda関数がソリューションを支配し、いくつかのDynamoDBテーブルが散りばめられている状態で、私は不安を感じ始め、お詫びして会話に割り込んで以下の質問をしました。
サーバーレスのソリューションを以前に構築したことはありますか？
このエンジニアは「はい」と答えました。
設計上で行われたいくつかの選択について、エンジニアに「なぜ」をさらにいくつか尋ねた後、エンジニアは以前にシンプルな機能用にLambda関数を作成しており、イベント駆動型のマイクロサービスのアーキテクチャを設計したり構築したりしていなかったことを認めました。
私の意図はエンジニアを見くだすことではなく、新しい技術を取り入れて働く際に私たちが皆経験する重要な段階を強調することです。Lambda関数の作成と操作方法を知ることは確かに正しいスタートですが、同時に、すべてがサーバーレスで簡単すぎると考えてはいけません。このような姿勢が、複雑なサーバーレスアプリケーションを実装することにつながるのです。
私は、サーバーレスに初めて取り組む人にとって、問題をマイクロサービスに分割し、アプリケーションの同期と非同期の部分を特定し、イベントの観点で考えたり、可観測性を設計したりする知識は複雑だと同意します。実際のところ、これらの側面の多くは新しいものではなく、サーバーレスに特有ではありません。違いは、過去の孤立したチーム構造では、あなたがプログラマーとしてこれらの過程に関与する機会がなかったことです。
車の運転を学ぶとき、実用的な運転テストに自信を持つまでいくつかのレッスンを受けます。同様に、サーバーレスエンジニアとしての仕事と並行して、サーバーレスのスキルを評価し、必要な学習を行う必要があります（後のセクションで説明します）。
サーバーレスは、エンジニアをアーキテクチャの議論から除外すれば難しい。
私がチームを指導する際に取るアプローチは、サービスまたは機能の開発を1人または複数のエンジニアに割り当てることです-アイデアから本番まで。彼らは、製品チーム、ステークホルダー、技術エキスパートとの初期の対話から知識を集めるために早い段階からの旅の一部になります。彼らは必要な発想のセッションや問題分析に参加し、シニアやエキスパートの指導のもと、アーキテクチャの草案を作成し、全員がレビューするためのソリューション設計書を作成します。ここから、実装チケットが作成され、反復的な開発とデリバリーのフェーズに入ります。
サーバーレス開発におけるソリューション設計の重要性-パートI
それがもたらすもの、そしてなぜ必要なのか？
sbrisals.medium.com
上記のアプローチは意図的です。欠点や批判はありますが、チームとエンジニアのプロフェッショナルな成長に多くの利益をもたらします。エンジニアを教育し、サーバーレスエコシステムの一部にするために、アーキテクチャの設計図を与え続けるのではなく、アイデアとリソースを提供して一緒にアーキテクチャを進化させ、学習し、開発し、デリバリーする必要があります。
自分のチームのエンジンルームでサーバーレスアーキテクチャを作り出すのです。
ある組織で、新しい機能を導入するために複数のチームが協力しました。以前のセッションで意見を出し合った人々とのいくつかのアイデアのセッションがあり、高レベルの提案が合意に達し、それが詳細に記述される解決策の設計に取り組まれました。その後、エンジニア数名が、自分たちのチームの解決策の一部を実装するためのチケットを割り当てられました。しかし、これらのエンジニアは以前のセッションの一部には参加しておらず、説明も受けていませんし、以前の会話のすべてのメモ、図面、思考の記録が残っている仮想ボードも見たことがありませんでした。
想像できるように、上記のエンジニアは困難な状況に置かれました。エンジニアの能力や問題の平凡さに関係なく、サーバーレスの開発をVisual Studio（VS） Codeから始めないようにしてください。もし始めてしまうと、サーバーレスの経験がスムーズになるという保証はありません。
エンジニアの能力や問題の平凡さに関係なく、サーバーレスの開発をVS Codeから始めないでください。
完璧主義よりも実践主義を求める場合、サーバーレスは難しい。
私の「サーバーレスチームを成長させる方法」についての話では、実践的な思考のチームがサーバーレスで加速する一方、完璧主義的な視点ですべてを完璧にしようとする純粋主義者のチームは遅れを取ることを示すスライドを共有しています。
しばしば、情報の過多や実用的なエンジンルームの経験がないアイボリータワーの建築家の完璧主義が、サーバーレスの導入を困難なものにし、経験を悪化させることがあります。
かつて私はコミュニティの会話で二つのサーバーレスチームの話を聞いたことがあります。両チームには共通点がありました。彼らはそれぞれの境界内で運営され、イベント駆動型のマイクロサービスを開発し、明確に定義されたAPIを持っていました。
一つ目のチームは、本番のAWSアカウント（テスト、QA、プレプロダクションなどの個別のアカウントを含む）でマイクロサービスを所有・運営し、Lambda関数をカスタムVPCの外部に保持し、必要な場所だけでVPCを設定し、Amazon API GatewayでAPIをホストしていました。彼らのサービスは、Amazon EventBridge上のカスタムイベントバスによって調整されます。このチームにとって、新しいマイクロサービスの開発、デプロイ、運用は効率的に行われているように思われました。
しかし、二つ目のチームは、純粋主義的な考え方に従い、各マイクロサービスを別々のAWSアカウントにホストし、Lambda関数をカスタムVPC内にデプロイしました。さらに、すべてのAPIは異なるゲートウェイ着陸プラットフォーム上でホストされていました。マイクロサービスの数は20以上になり、その複雑さに苦労していました。
もちろん、異なる選択や意思決定をする場合もありますが、管理しきれなくなる状況に陥ることを避けるために、評価し、方針を修正するべきです。
サーバーレスを採用する主な動機の一つは、重い作業をクラウドプロバイダーにオフロードすることですが、戦略でサーバーレスの強みに逆行すると、サーバーレスはますます難しくなります。
チームの境界が歪むと、サーバーレスは難しくなる。
チームの境界について考えるとき、誰もが領域限界（ドメイン駆動設計の一部として）を考えます。ただし、オートノマスな2ピザのサーバーレスチームには、以下にリストされる他の境界も関連しています。境界が歪むことで、サーバーレスの経験が難しくなります。
- 領域限界
- チームの責任範囲
- チームの所有範囲
- ソースコードリポジトリの境界
- クラウドアカウントの境界
最初の3つは依存関係があり、重なり合います。チームが組織のドメインの一部である境界の管理者であれば、素晴らしい状況です。この場合、チームはこの境界内のすべての要素、サービス、実装アーティファクトに対して責任を持ち、所有します。
所有するアセットの実装アーティファクトは、チームメンバーが貢献し、共有するリポジトリにあります。
AWSクラウドアカウントの境界は、デプロイとクラウドおよびサーバーレスのアセットの運用範囲を示します。
理想的な世界では、チームとこれらの境界との間に1対1の対応関係があります。
- 境界限界のためにチームが存在します。
- チームは境界内のすべてに責任を持ち、所有します。
- チームにのみ貢献するリポジトリを持っています。
- チームは専用のクラウドアカウントで所有するすべてを運用しています。
サーバーレスエンジニアとしての生活は、できるだけシンプルで楽しいものになります！
さあ、少しずつ緩和し、境界を開放し、何が起こるかを想像しましょう。
たとえば、ビジネスの優先事項と納期の達成のために、別のチームからエンジニアを呼んで、あなたのチームの境界への貢献の責任を共有させるとします。すると、チームの焦点が変わるようになります。
- チーム同士がお互いの作業方法を知るようにするにはどうすればいいですか？
- コード品質を均一にするにはどうすればいいですか？
- AWSサービスの選択とアーキテクチャパターンの整合性を確保するにはどうすればいいですか？
- 操作上の責任に抜けがないようにするにはどうすればいいですか？
これらのチームは協力して状況を改善することができます。ただし、協力にはチャット、ペアプログラミング、レビュー、ディスカッション、ミーティングなどが必要であり、これらは両チームの焦点と効率に影響を与えます。
適切な思考の下でチームの境界を開放し、共有責任を持つことは組織に否定的な影響を与える可能性があります。サーバーレスの開発が難しくなり、開発者の経験が悪くなることもあります。
人々の成長に投資しない場合、サーバーレスは難しくなります。
私たちの周りの世界は、ショートカットでいっぱいです。いくつかのショートカット方法を教える手段がLambda関数を書く方法を教えてくれます。このファストフード式の学び方は、食べ物がある限りは良いですが、食欲を満たすためにはもっと頼まなければなりません。サーバーレスで成功するためには、学び続ける必要があります。
Paulの記事では、学習に焦点を当て、サーバーレスに参入した人々が技術とエコシステムについて苦労することが多いと説明しています。Paulが説明するように、サーバーレスに未経験の人にとって、シングルパーパスLambda関数の概念自体が理解するのに時間がかかります。
サーバーレスで成功するためには、シングルパーパスLambda関数を理解した後、多くの進歩を遂げる必要があります。成功への道のりは多くの跳躍を必要とし、途中で多くの特性を身につけます。
私はよく、サーバーレスがチームにエンジニアリングの多様性をもたらすことを強調します。これは、サーバーレスを簡単にするために必要な認識です。
エンジニアは、ステークホルダーの要件を理解させ、アーキテクチャを提案させ、シングルパーパス関数とマイクロサービスの利点を教え、セキュリティの組み込み方法を示し、可観測性の原則を教え、本番環境にデプロイさせ、そのサービスのオーナーとしてラベルを付けるために、導かれ、育まれ、指導され、訓練されるべきです（または、組織内で使用される用語）。これらは数日間のビデオ視聴によってすぐには身につかないものです。ここで、質の高いトレーニングと長期的な人材育成戦略が重要です。
エンジニアを企業のビューロクラシーで制約しないでください。彼らには新しいことを学ぶ自由を与え、カンファレンスに参加し、テクニカルワークショップや共同作業に参加することができるようにしてください。
ある会議で、エンジニアリングマネージャと話していました。彼女は、数時間以上続くEventStormingやArchitecture Katasなどのワークショップは時間の無駄で、チームの生産性に影響を与えると述べました。そこで私は彼女に尋ねました。もし数人の機会を逃し不満を持ったエンジニアが1日または2日欠勤した場合、どのように生産性を確保するのかと。彼女には答えがありませんでした！
サーバーレスのブートキャンプは、エンジニアにサーバーレス技術エコシステムの基礎を備えさせる簡単な方法です。一部の組織は、そのようなプログラムを成功裏に実施しています。AWS HeroのMatt Coulter氏は、Liberty Mutualで新入社員向けの成功したプログラムを一度言及しました。組織は、そのようなイニシアチブがもたらす利益を評価せず、予算の制約を理由に優先順位を下げることがしばしばあります。
サーバーレスのトレーニングにおいて課程の質とカバー範囲の技術的、開発的、アーキテクチャル、運用的要素が課題となります。数多くのコースの中で、Yan CuiのProduction-Ready Serverlessトレーニングワークショップには素晴らしいフィードバックがあります。YanはAWS Serverless Heroであり、サーバーレスの知識の宝庫です。
Production-Ready Serverless
本番環境で利用可能なサーバーレスアプリケーションを構築するためのベストプラクティスを学びましょう。
productionreadyserverless.com
エンジニアにステークホルダーの要件を理解させ、アーキテクチャを提案させ、シングルパーパス関数とマイクロサービスの利点を教え、セキュリティの組み込み方法を示し、可観測性の原則を教え、本番環境にデプロイさせ、そのサービスのオーナーとしてタグを付けることを
サーバーレスが簡単になるでしょう…
運転が経験によって良くなり、容易になるように、サーバーレスも経験を積み重ね、エコシステムに慣れ親しむことで生産的で楽しいものになります。
ローラーコースターは、誰にでも好きなものではありません。スリルを求める人々が他の人々に対して最も共通して提案するアドバイスは「手を放して学ぶしかありません！」です。
サーバーレスのテクノロジーに信頼を置くことを学びましょう。AWSが管理対象のソリューションを提供している場合は、それらを活用してビジネス価値を倍増させてください。不要な複雑なソリューションを構築し、自らに負担をかける理由はありません。
成功裏にサーバーレスを導入した人々からインスピレーションを得ましょう。
最後に、モメントズのテーマよりもぴったりのフレーズは見つけられませんでした。AWS re: Invent 2023 コミュニティパーティー–
サーバーレスを信じよう！
はい、サーバーレスを信じて、手放すことを学びましょう！
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
