Development

Everything as Code - トレンドか必然か？

Created   Updated
  1. as codeの主な利点：
  2. as codeの主な課題：
  3. 正当化されるか？
  4. 各ドメインにおけるas codeの状況
  5. Diagram as Codeリソース
  6. 結論

💡 Everything as Codeとは？

Everything as codeは、ソフトウェア開発、デリバリー、運用のあらゆる側面を、アプリケーションコードと同じツールやプロセスを使用してバージョン管理、テスト、デプロイできるコード成果物として扱うパラダイムです。

クラウドコンピューティング、自動化、DevSecOpsの時代において、「everything as code」または単に「as code」という概念は、ますます人気が高まり、重要性を増しています。しかし、それは何を意味し、採用することの利点と課題は何でしょうか？

🧬 ご存知でしたか？

生命のコードはゲノムです。DNAが生物の構築と動作の指示をエンコードするように、「as code」はソフトウェアシステムの構築と動作の指示をエンコードします。どちらもバージョン管理され（進化またはバージョン管理を通じて）、テストされ（自然選択または自動テストを通じて）、デプロイされます（繁殖または継続的デプロイメントを通じて）。

as codeは、次のようなさまざまなドメインを包含します：

  • Infrastructure as code (IaC): サーバー、ネットワーク、ストレージなどのクラウドリソースを、設定ファイルやスクリプトを使用して定義・管理する実践。Terraformは Infrastructure as codeの最良の代表例です。
  • Policy as code: セキュリティ、コンプライアンス、ガバナンスのルールを、開発およびデプロイメントパイプラインに統合できるコードとして表現・実施する実践。
  • Architecture as code: ソフトウェアアーキテクチャの決定、パターン、構造を、バージョン管理と検証が可能なコードベースの形式で定義・文書化する実践。StructurizrやC4モデルなどのツールにより、アーキテクトはシステムアーキテクチャをプログラム的に記述でき、アーキテクチャドキュメントが実装と同期した状態を保つことができます。
  • Diagram as code: アーキテクチャ図やフローチャートなどの図を、グラフィカル形式にレンダリングできるコードを使用して作成・更新する実践。
  • Presentation as code: スライドやレポートなどのプレゼンテーションを、異なる形式やプラットフォームに変換できるコードを使用して作成・更新する実践。slidevはそのようなツールの1つですが、HTML/CSS/JSやVBAは人間にとって可読性の低い代替手段となります。
  • Database as code: データベーススキーマ、データ、マイグレーションを、データベースエンジンやツールで実行できるコードを使用して定義・管理する実践。
  • Documentation as code: MarkdownやAsciiDocなどのプレーンテキスト形式を使用してドキュメントを作成・維持する実践。これらはドキュメント生成ツールで処理したり、コードリポジトリに統合したりできます。プログラマーフレンドリーなコードから人間が読めるドキュメントを生成するフレームワークは数え切れないほどあります。
  • Configuration Management as code: 環境変数やフィーチャーフラグなどのアプリケーション設定を、動的または静的に適用できるコードを使用して定義・管理する実践。
  • UI as code: Webページやモバイルアプリなどのユーザーインターフェースを、異なるデバイスやプラットフォームにレンダリングできるコードを使用して作成・更新する実践。UIは通常XMLやHTMLで保存されますが、プログラミング言語から生成することも珍しくありません。
  • AI as code: 機械学習やディープラーニングモデルなどの人工知能モデルを、AIフレームワークやプラットフォームを使用してトレーニングおよびデプロイできるコードを使用して作成・更新する実践。一方、モデルは推論によって「レイヤー化」できます。Ollamaには、システムプロンプトの他にその目的で使用できるDockerfileのようなas codeがあります。

as codeの主な利点：

  • 一貫性: as codeは、ソフトウェア開発、デリバリー、運用のすべての側面が互いに、そしてアプリケーションコードと一貫していることを保証します。これにより、手動またはアドホックな介入から生じる可能性のあるエラー、競合、不一致が減少します。
  • 再利用性: as codeは、異なるプロジェクト、環境、チーム間でコード成果物の再利用を可能にします。これにより、開発者とオペレーター間の効率、生産性、コラボレーションが向上します。
  • 追跡可能性: as codeは、ソフトウェア開発、デリバリー、運用のあらゆる側面に加えられた変更の明確で完全な履歴を提供します。これにより、ソフトウェアライフサイクル中に発生する可能性のある問題の監査、デバッグ、トラブルシューティングが容易になります。
  • スケーラビリティ: as codeは、変化する需要や要件に対応するために、クラウドリソース、ワークフロー、モデルを簡単かつ迅速にスケーリングできます。これにより、ソフトウェアシステムのパフォーマンス、可用性、回復力が向上します。
  • 自動化: as codeは、退屈で時間がかかり、エラーが発生しやすいタスクの自動化を可能にします。これにより、開発者とオペレーターは、より創造的または戦略的な活動に集中できます。
  • AI対応: as codeは、AIシステムが簡単に解析、理解、生成できる構造化された機械可読形式を提供します。これにより、AIアシスタントがインフラストラクチャ、ドキュメント、設定、その他の成果物の作成、変更、最適化を支援でき、開発ワークフローを加速し、人的エラーを削減します。

as codeの主な課題：

  • 複雑性: as codeは、ソフトウェア開発、デリバリー、運用に追加の抽象化レイヤーと複雑性をもたらします。これにより、開発者とオペレーターは、as codeのさまざまなドメインに対処するために、新しいスキル、ツール、言語を学ぶ必要があります。
  • 統合: as codeは、as codeのさまざまなドメインをサポートするために、さまざまなツールとプラットフォームの統合を必要とします。これにより、開発者とオペレーターに互換性の問題、セキュリティリスク、メンテナンスのオーバーヘッドが生じる可能性があります。
  • テスト: ほとんどのas codeは、正確性、信頼性、品質を保証するために、コード成果物の厳密なテストを要求します。これには、開発者とオペレーターに追加のリソース、時間、専門知識が必要になる場合があります。

正当化されるか？

各ユースケースでas codeを使用することは正当化されるでしょうか？答えは、次のようないくつかの要因に依存します：

  • プロジェクトの性質と範囲: プロジェクトによっては、サイズ、複雑さ、ドメインに応じて、as codeからより多くの恩恵を受ける場合があります。たとえば、大規模、分散型、データ集約型のプロジェクトは、小規模、モノリシック、ロジック集約型のプロジェクトよりも、IaC、WaC、AICからより多くの恩恵を受ける可能性があります。
  • ツールとプラットフォームの成熟度と可用性: ツールやプラットフォームによっては、機能、機能性、互換性に応じて、as codeをより適切にサポートする場合があります。たとえば、一部のクラウドプロバイダーは他のプロバイダーよりもIaCのオプションと柔軟性を提供する場合があり、一部のAIフレームワークは他のフレームワークよりもAICの機能とパフォーマンスを提供する場合があります。
  • 開発者とオペレーターのスキルと好み: 開発者やオペレーターによっては、スキル、経験、スタイルに応じて、as codeを好む場合があります。たとえば、一部の開発者はグラフィカルインターフェースを使用するよりもコードを書くことを楽しむ場合があり、一部のオペレーターはダッシュボードを使用するよりもコードを使用することを好む場合があります。

各ドメインにおけるas codeの状況

📊 As Code成熟度評価

現在の業界での採用とツールの成熟度に基づく：

as code 状況 正当性（最大5つ星）
Infrastructure 非常に成熟しており広く使用されている ⭐⭐⭐⭐⭐
Policy 成熟しているが広く使用されていない ⭐⭐⭐
Architecture StructurizrやC4などのツールで採用が拡大中 ⭐⭐⭐⭐
Diagram 図のタイプによる。レイアウト調整が難しいものもある ⭐⭐⭐
Presentation レイアウトの微調整とアニメーション作成が難しい ⭐
Database ⭐⭐⭐⭐⭐
Documentation Markdownなど多数 ⭐⭐⭐⭐
Configuration ⭐⭐⭐
UI プログラミング言語で生成可能 ⭐⭐⭐⭐
AI モデルをレイヤー化可能 ⭐⭐

Diagram as Codeリソース

Mermaid JS

https://mermaid.js.org/

YAML言語で図をas codeとして表現する最良の方法は、オンザフライで図を生成できるJavaScriptライブラリであるMermaidJSを使用することです。GitHubや多くのプラットフォームがMermaidJSをネイティブにサポートしています。このブログを生成するHexoなどの他のプラットフォームにも、MermaidJSで図をレンダリングするプラグインがあります。エラーメッセージは、他のdiagram as codeライブラリと比較して非常に直感的です。シンプルな図を書くために強く推奨されます。

PlantUML

https://github.com/plantuml/plantuml

よく知られたdiagram as codeジェネレーターで、人間が読める言語から画像を生成します。Javaプログラムを処理する場合でも、許容できる速度で画像を生成します。このツールは複数ページの図をサポートしています。ただし、さまざまなレイアウトタイプをサポートしているにもかかわらず、配置をマスターするのは困難です。図が複雑になるにつれて、線がラベルの上を走ったり、その他の問題が発生したりする可能性があります。

AWS Diagram-as-Code

https://github.com/awslabs/diagram-as-code

このプロジェクトは2024年2月に始まったばかりで、比較的新しいものです。図はアイコンとグループ化で見栄えがします：

AWSの例

YAMLを使用していますが、その構造で図を書くことは、リソース間のリンクを設定し始めると苦痛になる可能性があります。Source、Target、SourcePosition、TargetPositionなど、効果的に記述するには少なくとも4行を書く必要があります：

links.yaml
Links:
   - Source: ALB
     SourcePosition: NNW
     Target: VPCPublicSubnet1Instance
     TargetPosition: SSE
     TargetArrowHead:
       Type: Open

SourcePositionとTargetPositionが必要なのは、線がリソースに対して自動的に配置されないためです。図は見栄えがしますが、コールアウトのようなAWSスタイリングをサポートしていません。CloudFormationのinfrastructure as codeから、またはTerraformから変換して、素早く図を作成したい場合を除き、推奨されません。ただし、図を完成させるにはまだ多くの作業が必要です。

結論

結論として、as codeは、ソフトウェア開発、デリバリー、運用を強化できる強力で有望なパラダイムです。しかし、採用する前に慎重に検討する必要がある独自の課題とトレードオフも伴います。

🎯 重要なポイント

As codeは万能のソリューションではなく、プロジェクト、ツール、関係者に依存する文脈依存の選択です。

シェア