一部のおじさんは新しいものが出てきた時にいったん拒否してしまう
岡智也氏：それでは、「アンチCDKだったわたしが『CDK、できる……』と思ったところ」ということで、岡からプレゼンします。
岡と申します。今日は、個人として参加しており、私が話したことや資料の内容は、所属する組織とはなんら関係ありませんので、あらかじめご了承いただければと思います。
まず、「アンチのくせにCDKカンファレンスにお前は何をしにきたんや」というところなんですけれども。やはり歳を取ってくると、新しいものが出てきた時に、おっちゃんは拒否したくなっちゃうんですよね。
あれこれ理由をつけて、まずは否定から入るみたいなところありますよね。例えば「CDK？」「もうCloudFormationとか、Terraformとかあるし、なんでそんなの使わなあかんの？」とかですね。
あと「え？ TypeScriptやPythonでコード書くの？」「それ保守で引き継ぐ時メンテできんの？」みたいな、そういうツッコミをしたりとか、「CloudFormationとかTerraformと比べるとネットの情報は少ないじゃないですか。なにかトラブルが起きたらどうするんですか？」とか、「え？ アプデでちょいちょい言語仕様変わる？ そんなもん怖くてProductionで使えるかよ」みたいに、否定しちゃうわけですよね。
やはり経験だけは多いんで、それっぽい理由をつけるんですが、単に面倒くさいだけというケースが多かったりもします。
アンチの類例ですね。「AWSのサービスアップデート怖い病」というので。これ、僕も罹っているのですが、歳を取ってくると、AWSの新しいサービスや新機能が発表されても、クイックにサササッと動かすのができなくなってくるんですよ。
今週、（※登壇当時）LambdaのURLを生やせるアップデートが出たじゃないですか。そういうアップデートが出ると、「あ、いかん！ これはキャッチアップして実践投入できるか確認しなくては！」と思うんですけど、「でも試す時間がない！」とか言って、強いストレスを感じるわけですね。でもTwitterをやる時間はあったりするわけですよ。
なので、歳を取るといろいろと良くないということで、このCDKも試そう、試そうと思いながらずっと怠けていたわけです。
神本『AWS Cookbook』が出た
ここから本題ですね。CDKと私との邂逅（かいこう）。「邂逅」という言葉を使いたかっただけですが、ある神本が出たんですよ。
『AWS Cookbook』。『AWS Cookbook』ですよ、みなさん。実は、O'REILLYのCookbookシリーズのAWS版が出たんですよ。しかも見てくださいこれ、2021年の年末に出たんですね。だから最新版なんですよ。
著者のお二人は、実はAWSの中の人だそうです。なんと、JAWS-UGの名誉顧問、Jeff Barrさんがはしがきを書いているということで、もうこれは買わざるを得ないということで、買いました。リンクをここに貼っておきます。
これを買ったんですが、お値段がぜんぜんかわいくないんですね。1万円近くするんですよ。高いと思ったんですが、試し読みしたら中身がメッチャ良くて、思わず買ってしまいました。
これはCookbookなので、例えばセキュリティ、AWSのAIやMachine Learningのサービスなど含めて、AWSを活用するためにやりたいことの単位でレシピが書かれているんですね。 AWS CLIやシェル、bashかZshで実行できるようにCookbookが書かれているんですよ。メチャクチャ読みたくなったでしょう？
CLI実行する前提でこのレシピを試すために、AWS上に環境構築が必要になるものがあります。その環境構築のためのIaCのコードがCDKだったんです。v2で、しかも僕が使いたいPythonだったんですよ。
なぜPythonを選んだのかはわからないので、大村さん（※大村幸敬氏）か沼口さん（※沼口繁氏）、著者に聞いてみてください。GitHubで、Pythonのコードが公開されているんですよ。
ソースも公開されていて、本の中身も書いてあるので、「なんだこれ。本を買わなくてもよかったじゃん」と思ったんですけど（笑）。まぁいいんです、いいんです。すごくいい本なのでいいんです。けっこう内容がいいので、「これだったらちょっとCDKをやってみようかなー」と思って、手を出しました。
というのが僕とCDKとの出会いです。この本の出版年月日から逆算してもらうと、僕がCDK素人であることがわかってもらえるかと思います。
CDKを使う前のイメージと、実際に使ってみて思ったこと
CDKを実際に使ってみる前のイメージと認識について。僕も仕事でAWSを使っているので、CDKがサポートする、プログラミング言語があるとか、CloudFormationやTerraformと比べると、コード量が少なくて済むとか。条件分岐みたいなものは当然TypeScriptやPythonで書けるから、自由度が高いんだろうとか思っていたのですが、「その他のメリットってなんなのかしら」と思っていました。
さっきの『Cookbook』のレシピをGitHubからプルしてくれば、若干前準備は要りますが、試せます。コードを読んでいて、CDKがサポートするプログラミング言語の経験が要るかどうかというと、正直そうでもないなと感じました。
オブジェクト指向を駆使して、環境差異を吸収するみたいな、書き方もできますが、大村さん（※大村幸敬氏）の講演にもあったとおり、Constructを並べていくだけでもけっこうな処理ができるので、言語の経験はそんなに要らないだろうなという感じがしました。
あと、CloudFormationやTerraformと比較するとコード量が少なくて済むというのはそのとおりだと思います。また、繰り返しや条件分岐など、メッチャ使うコードも書けると思いますが、むしろいい意味で型にはめようとしているなという印象を持ちました。
その他のメリットは、これですね。やはり「CDKはOSSである」という点が大きいので、そういう貢献できるというのが一番大きいのかなと思いました。（スライドを示して）この後述のところは、ちょっと説明します。
「いい意味で型にはめようとしている印象」とは
まず、いい意味で型にはめようとしているというところですが、AWSではプラクティスになっている実装があるじゃないですか。例えばプライベートサブネットからインターネットに出る時は、NATゲートウェイをサブネットに置いて、そこを経由してインターネットに出るとかあるじゃないですか。そういうのはこのEC2の、「PRIVATE_WITH_NAT」という宣言をするだけで、いい感じに作ってくれるんですよ。
ほかにも、そのサービスを利用するうえで自明な作業については、抽象化されているんですね。先ほど渡邉さん（※渡邉洋平氏）のお話の中にもあったように、ECSでアプリ公開する時は、普通前段にALBを置きますよね。そういうのはもうecs_patternsとして定義されていて、少ないコード量で書くとecsのクラスタも、そのためのALBもできるしということで、すごく抽象化されています。
これはまだ発展途上なので、今全部を任せられるかと言ったらそうではありませんが、この方向性で進化していけば、もしかしたら「とりあえずCDK」で、今は存在しないナンタラというソリューションを使っておけば、基盤はOKみたいな感じになるんじゃないかなと、期待をすごく持ちました。ぜひそうなってほしいなと思っています。
やはり、AWSを使って基盤を作る時のデザインパターンはもういっぱいあるじゃないですか。ビジネスドメインで業務の違いはありますが、インフラレベルでそんなに差が出るかなとずっと思っています。
先ほど、大村さん（※大村幸敬氏）が発表された、すばらしい「BLEA」とか、そういう大ヒットプロダクトが出て、「AWSのインフラはこれを使っておけばセキュアだし、ベストプラクティスがあらかじめ反映されているし、みんながこぞってオープンソースで更新してるし」みたいな、そういう世の中が来るんじゃないかなというのを、CDKは感じさせてくれました。
オープンソースとしてCDKが盛り上がるように貢献したい
「CFnではできなかったこと」。CloudFormationは、正直AWSのアップデートを待つ必要がありましたよね。でもCDKは、気に入らない部分や足りない部分があると思ったら、Construct Hubとかで自分で書けばいいんですよね。
僕もおっさんですが、「まずはお友だちから始めましょう」ではありませんが、ちょっとタイポを修正してみるとか、そういうところから貢献をちょっとしてみようかな、ブログを書いて情報発信していこうかなと思いました。
あとOSSというところで、これを言うと怒られるので冒頭に「個人の発表です」と言ったのですが、AWSにはBabelfishとかBottlerocketとかFirecrackerとか、諸々あって、他のクラウドを使っている人から「AWS、ちょっとただ乗りしているんじゃないの？」みたいなことをちょっと言われる時があるんですね。
ほら、Googleは、MapReduceとか。KubernetesはもともとBorgとかありますもんね。CDKTF（Cloud Development Kit for Terraform）とかですね、CDK8s（Cloud Development Kit for Kubernetes）とか出ているようなので、オープンソースとしてCDKが盛り上がるように、僕もなにかできればなというふうに思いました。
まとめ
まとめです。食わず嫌いは良くないということで、否定する前に手を動かしましょう。この『AWS Cookbook』は神本なので、みなさんに買ってもらいたいですが、内容はGitHubで読めるので、ぜひ読んでください。
CDKはハードルが高そうですが、初めのところは大丈夫です。ただ、やはりProductionで利用に耐え得るコードを書こうと思うとハードルは高くなってくるので、そこはご注意ください。
先ほど、抽象度が高い、型にはめようとしているという話をしましたが、これはまた良し悪しがあります。自分が意図していなかった設定が勝手にされたりする可能性はあるので、ピアレビューやCIで静的解析ツールなどを使ってチェックするのは必須だなと思いました。
あとCDKはオープンソースなので、みんなでがんばって盛り上げていく必要があるなと思いました。私の発表は以上です。ありがとうございました。
