はじめに
世の中にはすごいエンジニアや、よりよい物を作ろうと工夫しているエンジニアがたくさんいます。しかもその工夫や苦労をネットに公開してくれていることさえあります。
本になっているわけではないので体系的に学ぶことはできないのですが、そこで考えた工夫やエッセンス、調査内容は必ず誰かの糧になると思います。この記事では私が「読む価値がある！」と思った記事を引用しながら、自分の考えを追加して理解を深めていこうというものです。
今回紹介する記事
素晴らしい記事をありがとうございます！
この記事の概略
次に、Architecture as Code(以降AaC)について説明します。 AaCとは「クラウドアーキテクチャをモデル化・コード化しプロビジョニングすること」になります。IaCはそれぞれ個々のリソースについてコード化していたのに対し、AaCでは、リソースが組み合わされ、モデル化された構造をコード化することになります。
よく、マイクロサービス化すると、同じようなパターンのサービスが点在することになり、そのような類似したパターンをコンポーネントとして再利用可能にして、各サービスに展開できます。
Terraformに代表されるIaCツールでは特定のサービスの設定を変更管理しますが、AaCツールではユーザが最終的に実現したいWebアプリやバッチなどの複数のサービスの組み合わせをAWSが推奨するベストプラクティスに準拠した形で簡単に構築することができます。
AaCの便利な点
紹介されているような構成をまとめて作ってくれるのは非常に強力だと思います。特に似たような構成を大量に作るような仕事であれば使うのが前提になってくるかなと。
またAWSのドキュメントとにらめっこして権限まわりに悩んだり、サービスの勉強をする必要も減るでしょう。
なので個人的に向いているなあと思うのは、ひたすら多種多様なWebサイトをつくる仕事の時とかすごい楽だと思いますね。要するにアプリの動きだけが異なるはんこ型のシステムですね。
AaCが使いづらい領域
AWSを利用する際にやりたいことが特殊だったり、要求が高い場合はマッチしません。
AWSは様々なものに利用できるので、独自の要件で利用しているところは非常に多いと思います。仮に一番最初はこれをつかったとしてもその後の拡張で独自設計や要件がでてきたり、どうしてもベストプラクティスに乗れないところが出てくる場合があるはず です。
またそうなったときに一部をAaC、一部をIaCの管理となると収集がつかなくなります。なので、長期的な運用を考えるとどこかのタイミングでIaCへの移行が必要になります。
また可用性を考慮してマルチクラウドの考え方を導入する案件となると、特定のクラウドにしばられる現在のAaCの考え方は受け入れづらいでしょう。
AaCをもっと使いやすくなる未来を想定する
ますますインフラの仕事がなくなってきますが、理想としてはSLAやセキュリティの要件を入力するとそれ通りのクラウドリソースが自動で作られるというところでしょうか。
- 要件定義
- 基本設計
- 詳細設計
- 構築
- テスト
というフェーズをおこなす中で基本設計の難易度は非常に高いです。AaCの考え方で要件から一足飛びで構築まで完了できるようになれば人力の設計やその管理が不要になるためテストが簡単になり、要件の抜け漏れも気にする必要がなくなりますね。
ここまで書きましたがあくまで妄想なので「どうやるんだ？」のビジョンも見えていませんが…
