JAWS PANKRATION 2024で「What we keep in mind when migrating from Serverless Framework to AWS CDK and AWS SAM」というタイトルで登壇しました

JAWS PANKRATION 2024で「What we keep in mind when migrating from Serverless Framework to AWS CDK and AWS SAM」というタイトルで登壇しました

Clock Icon2024.08.27

データ事業本部の笠原です。

2024/08/24 (土) - 2024/08/25 (日) にかけて開催された「JAWS PANKRATION 2024」で登壇しました。

Session Info

登壇資料

動画

https://youtu.be/5hTBb4CTP3M

概要

現在我々のチームでは、Serverless Framework V4からの有料ライセンスに伴い、Serverless FrameworkからAWS CDKやAWS SAMへの移行を行なっております。

主張したい点は以下の通り。

  • 各サービスを比較して、各々のプロジェクトにとって最適なサービスを選んで移行する
  • AWS CDKに移行する前に開発経験を積む
  • 既存の定義ファイルを有効活用する
  • まずはチームで適用しやすい形で導入し、適宜改善を行う

サービス間比較

資料は英語訳の比較表を掲載していますが、日本語の比較表は以下のブログ内に記載があります。

比較表をベースに、Serverless Framework V4で継続する点を先に考慮した上で検討していきましょう。

  • ライセンスコストと移行コストの比較
  • 将来の成長性見込み

AWS CDKに移行する前に経験を積む

我々のチームではAWS CDKの開発経験が乏しかったので、意向や比較の前にAWS CDKの開発経験を積む必要がありました。幸い、早い段階で2つの新規プロジェクトでAWS CDKでの構築を試すことができました。

  1. Box → Lambda → S3
  2. S3 → Lambda → External SaaS (REST API)

また一部のプロジェクトでは、CDKで移行するために事前にPoCをする機会が得られたのが、とてもありがたかったです。

事前にCDKの経験を積んだので、比較や移行が大変捗りました。

既存の定義ファイルを有効活用する

移行の際はなるべく既存の定義ファイルを有効活用して、変更を少なくするように心がけます。

特にCDKはYAMLで定義していた内容をTypeScriptで定義し直す必要があるため、
できるだけ既存ファイルを使って移行工数を減らしたい意図があります。

まずはチームで適用しやすい形で導入し、適宜改善を行う

AWS CDKやAWS SAMに移行するにしても、元々Serverless Frameworkで構築した際の知見は生かした上で、チームで適用しやすい形で導入するとスムーズです。最初からベストプラクティスに沿うのが良い場合は多いですが、無理して従う必要はないと考えています。

例えば、VPC等のネットワークインフラストラクチャ定義は、元々Cfnで定義したり、我々には操作権限がない形で既に定義されていたりしていました。

そのため、AWS CDKやAWS SAM上で無理して再定義する必要はなく、既存のリソースを参照する形で留めています。
AWS CDKでの開発知見が増えた際に、改めてAWS CDKでインフラ定義を行うことを検討していきたいと思います。

感想

実は初めてCfp申請受理されて登壇したのがこのイベントでした。
また、資料は全て英語なので、英語での資料作成に慣れてないからキツかったです。
グローバルイベントに登壇するきっかけを得たので、今度は英語で喋る登壇もしないといけないかもですが、英語が全然喋れない身なので、何とかしたい。

参考

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.