博士

ロボ子、今日のITニュースはアプリケーションアーキテクチャの進化についてじゃぞ。90年代の3層アプリケーションから、マイクロサービスやサーバーレス機能へと変わってきたのじゃ。

ロボ子

博士、3層アプリケーションというのは、データソース層、ドメイン層、プレゼンテーション層のことでしたね。それがどのように進化したのでしょうか？

博士

そうじゃ！プレゼンテーション層はWebインターフェースへ、ドメイン層はマイクロサービスへと分散していったのじゃ。でも、ここで問題が発生したのじゃ。

ロボ子

問題ですか？

博士

分散バックエンドでのオペレーション調整が難しくなったのじゃ。複数のサービスで一連のオペレーションをアトミックに実行したり、タスクを正確に1回だけ実行させたりするのが大変になったのじゃ。

ロボ子

なるほど。そこでオーケストレーション層が登場したのですね。

博士

その通り！オーケストレーション層は、分散マイクロサービス全体のオペレーションを調整し、フロントエンドにシンプルなAPIを提供するのじゃ。まるで指揮者のようじゃな。

ロボ子

記事によると、オーケストレーション層の構築方法には、DIYと専用の外部オーケストレーターの2種類があるようですね。

博士

DIYは、Apache KafkaやAWS SQSなどのメッセージブローカーを使う方法じゃな。でも、正確に実装するには深い知識が必要になるぞ。

ロボ子

専用の外部オーケストレーターは、AWS Step FunctionsやApache Airflowなどを使うのですね。ワークフローとしてプログラムを作成できるのが便利そうです。

博士

じゃが、オーケストレーション層とアプリケーション層の分離が複雑さの原因になることもあるのじゃ。そこで、DBOS Transactという軽量オーケストレーションライブラリが登場したのじゃ。

ロボ子

DBOS Transactは、プログラムをステップのワークフローとして記述し、Postgresデータベースに実行状態を保持するのですね。オーケストレーション層を排除できるのが画期的です。

博士

そう！アプリケーションは再び3つの層を持つようになるのじゃ。オーケストレーションの機能をアプリケーション層とデータベース層に分散させることで、シンプルになるのじゃな。

ロボ子

なんだか、振り出しに戻ったような感じもしますね。

博士

まさに、歴史は繰り返す、じゃな！でも、より洗練された形で繰り返されるのじゃ。…ところでロボ子、オーケストラの指揮者って、実はそんなに仕事してないって知ってたか？

ロボ子

えっ、そうなんですか？

博士

冗談じゃ！…たぶん。