目次
まえがき
第1章 Terraformに疲れたのでAWS CDKを使っていきたい話
第2章 Serverless Frameworkを用いたサーバーレスアプリケーションの構築
第3章 社内プロダクト開発の特徴を考える
第4章 挫折した人向け ふりかえり再入門
第5章 ゼロから開発組織を立ち上げて学んだこと
あとがき
まえがき
まずは「for Startups Tech Book Vol.1 — スモールチームで開発するためのプラクティス —」を手に取っていただき、ありがとうございます。
本書は、フォースタートアップス株式会社（以下、フォースタートアップス）のシステム開発チームである「テックラボ」の有志メンバーによる共著となります。
簡単にフォースタートアップスについて紹介させていただくと、私たちは「for Startups - 全ては日本の成長のために。スタートアップスのために。」というビジョンのもと、インターネット/IoTセクターをはじめ、Fintechやリアルビジネス領域も含めたIT、AI、SaaS、DeepTech、DisruptTech、ドローンテック、MaaS、5G市場などの転職支援と起業支援を中核とした、成長産業支援事業を推進しています。
テックラボでは、成長産業支援事業における課題をテクノロジーで解決すべく、社内向けのプロダクト「タレントエージェンシー支援システム（SFA/CRM）」や、成⻑産業領域に特化した企業情報プラットフォーム「STARTUP DB（スタートアップデータベース）※」を展開しています。
※スタートアップを中心とした13,000社以上（※2020年12月時点）の企業情報を掲載
本書の中では、上述のシステム開発を通じて得られた知見や、現在も開発現場で実践している手法などを、エンジニアのメンバーとCTOが執筆しています。
対象読者としては、スタートアップや小規模チームでインフラを担当する（または予定している）エンジニアや、プロダクトオーナー、アジャイル開発を実践中のチーム、またエンジニアメンバーをマネージメント管理するポジションの方などです。各章に文章としての繋がりや関連はありませんので、目次をご覧いただき、興味を持った章から読み進めていただければと思います。
本書は『技術書典10』に初出展した時の内容に、一部加筆・修正を加えております。拙い文章ではありますが、最後までご拝読いただけたら幸いです。
第1章 Terraformに疲れたのでAWS CDKを使っていきたい話
2019年に、Infrastructure as Code界に現れたAWS CDK。ようやくちゃんと向き合うことができたので、経緯やサンプル、小ネタもはさみつつ紹介していこうと思います。
1.1 Terraformのツラミ
フォースタートアップスではIaCとして、HashiCorp社が開発しているOSSのTerraformを採用しています。
Terraformは、HCL（HashiCorp Configuration Language）というDSLを用いてリソースを定義していきます。特徴として、管理対象プラットフォームごとに「プロバイダ」といわれるプラグインがあります。公式に提供されているプロバイダ以外にも、カスタムプロバイダという形でユーザーが独自にプロバイダを作ることができます。
そういった設計からもわかる通り、TerraformはAWSやGCP・Azureといった有名どころのIaaSだけでなく、様々なクラウドプラットフォームのインフラを定義することもできます。
これだけ聞くと「すごいじゃん、全部Terraformで定義しちゃえばいいんじゃないの？」となると思いますが、現実とは、そう簡単にはいかないもの。運用していくうちに、ちょいちょいと問題（というほどでもありませんが）が出てきました。
まずは、その独自のDSLやプロジェクトの構成によるもの。
フォースタートアップスでも昨今の流れに違わず、各ドメインのコードをマイクロサービスとして、別のプロジェクトにしています。対して、インフラ担当はSRE一人のみ。さすがに無理があります。全体の共通基盤ならばまだしも、各サービスごとのアプリケーションインフラに関しては、それぞれの開発チームである程度担保できると、いざというときにも安心です。
そうなった場合、完全な独自DSLであるHCLや特徴的なディレクトリー構成・モジュールシステムというのは、普段アプリケーション（フォースタートアップスでは主にRailsやVue）を書いているエンジニアにとってはとっつきにくく、習得にもオーバーヘッドがあります。やはり、普段書いているプログラミング言語に近い構文やモジュールシステムである方が、なにかと効率がいいのは間違いありません。
そしてもうひとつは、その柔軟性ゆえに、記述しないといけないリソースが多い、ということが挙げられます。
「そんなの当たり前」という意見ももっともではあるんですが、そもそもAWSやGCP・Azureといったクラウドインフラは、正直言って細かいリソースに関してはよくわかっていなくても、環境を作ることができるというものでした。もちろん、わかっていないとカスタマイズしたり、いざというときに修正したりといったことができないので、知らなくてもいいというわけではありません。ですが、知らなくてもできるというのは、明確なメリットだったはずです。
Webのマネージメントコンソールからポチポチしていけば、その「知らなくてもできる」ができていたものが、Terraformを使うと、全てのリソースを自力で定義しないといけません。インフラの知識云々というよりも、その時間、人的コストは馬鹿にできないものがあります。
上記から、Terraformで全てのインフラを管理することに対して、エンジニア全体として少なからず負担になっていました。
1.2 AWS CDKとは
そこで候補に上がってきたのが、AWS CDKです。
AWS CDK（Cloud Development Kit）とは、「AWSリソースを既存の言語を用いて構築することができる」フレームワークのことで、2019年7月にGAとなっています。
対応言語は2021年3月現在、TypeScript（JavaScript）、Python、Java、C#の4種類（5種類）ですが、GA当初はTypeScriptとPythonだけだったので、今後も増えていく可能性はあると思います。
※2021年4月末にはGo言語も開発者プレビューですが、利用可能となっています。
https://aws.amazon.com/jp/about-aws/whats-new/2021/04/aws-cloud-development-kit-aws-cdk--v2-and-go-cdk-is-now-available-for-developer-preview/
構築自体はそれらプログラミング言語で行うことができますが、バックエンドではCloudFormationが使われており、AWSのマネージメントコンソールから、その存在を確認することが可能です。
「AWS」と冠している通り、定義・操作できるのはAWSリソースのみで、GCP・Azureはもちろんのこと、Auth0などのTerraformでプロバイダが提供されていたようなプラットフォームにも対応していません。当然ですが。
なので、それらプラットフォームのインフラを扱う場合には、採用できないです。