Itaraは、分散システムのトポロジを明示的で、宣言可能、検証可能、かつ実行可能なレイヤーとして扱うことを目的としたオープンソースプロジェクトです。従来の分散システムでは、トポロジ（存在するコンポーネント、それらの接続方法、使用するトランスポート、障害処理方法）はコードベース全体に散在し、実装上の決定の副産物として扱われてきました。Itaraは、専用の設定レイヤーを導入することでこの問題を解決します。
コアとなるのは「ワイヤリングエージェント」（wiring agent）と呼ばれるコンポーネントで、アプリケーション起動前にYAML設定ファイルを読み込み、すべての接続を解決し、コンポーネントを配線します。準備が完了するとエージェントは終了し、アプリケーションは仲介者やランタイムの決定なしにフルスピードで実行されます。設定ファイルはシステムトポロジの信頼できる表現であり、ノード、コンポーネント、接続を記述します。たとえば、簡単な設定ファイルで「gatewayNode」と「calculatorNode」という2つのノードを定義し、それらの間のトランスポートを「direct」または「http」と指定できます。
Itaraのツールエコシステムにより、トポロジレイヤーは安全かつ管理しやすくなります。CLIツールには「itara inspect」（トポロジの可視化）と「itara verify」（デプロイ前の設定エラー検出）が含まれます。さらに、各コンポーネントは.itaraメタデータファイルで識別子、バージョン、APIコントラクト、機能を宣言し、ツールチェーンは作成時に互換性を検証し、誤ったトポロジが静かにデプロイされるのを防ぎます。
プロジェクトの中心的な設計原則は「トポロジを第一級の市民として扱う」ことです。コンポーネントはインターフェースのみを宣言し、呼び出し方法は宣言しません。これは設定ファイルで宣言されます。ワイヤリングエージェントは起動時に設定を読み込み、すべての接続を準備して終了します。そのため、コードは変更されず、通信方式は設定ファイルの変更だけで切り替えることができ、コード変更、再デプロイ、移行スクリプトは不要です。
Itaraは段階的に採用できるように設計されています。コンポーネントを参加させるには、APIアーティファクト（インターフェース）、アクティベーター（ファクトリメソッド）、設定ファイルエントリの3つが必要です。導入する唯一の依存関係は、コアライブラリ（itara-commonなど）です。ビジネスロジック自体にItaraのインポートは不要です。1つのサービス境界だけでItaraを採用しても、その接続の構造的可観測性と明示的なトポロジ宣言という即時の利益が得られます。
プロジェクトはJavaとRustのリファレンス実装を提供し、Go、Python、C++のサポートを計画しています。異なる言語で実装されたコンポーネントは同じトポロジグラフに参加し、同じ分散トレースを生成します。可観測性に関して、Itaraは可観測性を第一級の市民として扱います。各コンポーネント呼び出しは、4つのイベント（CALL_SENT、CALL_RECEIVED、RETURN_SENT、RETURN_RECEIVED）を生成します。これらのイベントの配置により、トランスポートオーバーヘッド（シリアライゼーション、ネットワークレイテンシなど）をモニタリングコードなしで直接測定できます。プラグインはカスタムスパンを発行でき、OpenTelemetryリファレンス実装はJVM間および言語間で分散トレースを提供します。
Itaraはイベント駆動型トポロジもサポートしており、仮想ノードとイベントコントラクトを通じて実現されます。たとえば、Kafkaトピックを仮想ノードとして宣言でき、イベント駆動型通信も4つのイベントモデルに従います。
現在、Itaraは概念実証段階にあり、Javaの「gateway」コンポーネントがRustの「calculator」コンポーネントを呼び出すデモが含まれています。設定を変更することで、直接呼び出しからHTTP呼び出しに切り替えることができ、コンポーネントコードは変更されません。プロジェクトは今後、ビジュアルエディタやコントローラなどのツールを開発する予定です。
従来のサービスメッシュやサイドカーパターンとは異なり、Itaraはネットワークを隠蔽せず、トポロジを明示化します。ランタイムオーバーヘッドを導入せず、トポロジ決定を起動時に先行して行います。プロジェクトのビジョンは、分散システムのトポロジを設定やInfrastructure as Codeのように管理可能な実体とすることです。