先日(２０２１年１１月)、OutSystems は マイクロサービスアーキテクチャとクライドネイティブアーキテクチャをキーワードに、Project Neo を発表しました。本記事では、マイクロサービスアーキテクチャについて、少し解説してみたいと思います。
私は OutSystems インサイダーですが、本記事は OutSystems の公式文書ではなく、私の個人的な意見が含まれています。執筆時点で GA (製品化)はまだ先で、変更になる可能性があります。
何がマイクロサービス化されたのか
開発者にとって一番影響のある個所は、”アプリケーション”がマイクロサービスになったということになるでしょう。"アプリケーション" とは、OutSystems Neo で開発をするときに定義するワークスペースの名前です。OutSystems 11 までは、モジュール、あるいは eSpace と呼ばれていました。
同じコンテナにデプロイされるようなタイプのライブラリのようなものもでてくると思いますが、基本は、アプリケーションごとにリソースが割り当てられ、それぞれ独立して管理されることになります。
マイクロサービス化が意味するもの
実行時のリソースのコントロールは、かなりやりやすいものになりました。原則システムリソースがアプリ別に分離され、それぞれがオートスケールできるであろうことが、容易に想像できます。
設計・開発時の恩恵もかなりあるでしょう。OutSystems 11 にも、マイクロサービスを定義する機能は備わっていますが、マイクロサービスにするには使っていけない機能や、Zone、複数環境を用意するなど、他にも様々検討要素がありました。Neo では、"アプリケーション" で作れば、マイクロサービスに必ずなるというのは、大きな違いです。
一方でマイクロサービスアーキテクチャでシステムを設計しないと、これらの恩恵にはあずかれないことは理解する必要があるでしょう。疎結合アーキテクチャを理解し、設計できない場合は、１つの "アプリケーション" にすべて機能を盛り込んでしまうモノリシックアプリケーションとなり、結局大きな箱の中で、すべてを動かす旧来通りのシステムになるはずです。
ただ、マイクロサービスアーキテクチャに自信のない方からみて、Neo は難易度が高いものだと思う必要はありません。旧来通りに作れるとも言えるわけです。恐れる必要はありません。むしろ、Neo を通じてマイクロサービスアーキテクチャを習得することで、エンタープライズアーキテクトへの近道を辿ることになるはずです。