OutSystemsの 「将来を見据えた開発」について(2022/3月時点)

OutSystemsが約束する「将来を見据えた開発」(以下、引用は2022/3/3時点のもの)に、今後のプロダクト開発の方針が述べられている。Project Neoがこれからリリースされるという状況で、既存ユーザーへの説明の意味もありそう。

個人的なポイント

  • OutSystemsはこれからも新技術を取り入れて進化していく。なるべく既存ユーザーのアプリケーションに影響を与えないように配慮するが、いくらかの修正は必要になる
  • Project Neoはクラウドだけでなくプライベートクラウド(具体的な条件は不明)でも動作するようになる(2024年末予定)
  • Project Neoのリリース予定は今年(2022年)上半期
  • OutSystems 11には投資を継続する。しかし、将来的に(早くとも2027/3末)Project Neoへの移行は強制される

OutSystemsを利用することによる実行スタックの抽象化

以下の部分に書いてあること。

アプリケーションの設計を(手続き型コードではなく)モデルとして抽象化すると、アプリケーションの実装を基盤テクノロジースタックから分離することができます。

OutSystemsで作成するプログラムは、以下の図でいうと、赤枠のモデルベースのもの。

このモデルベースのプログラムはOutSystemsが提供する言語・ライブラリ・開発環境にのみ依存する。そのため、OutSystemsがバージョンアップし、全く別の実行環境を利用するようになっても、同じモデルベースのプログラムを、新しい実行環境の言語にコンパイルされるため、そのまま利用できる、ということ。

例:OutSystemsバージョン10で作ったWebアプリケーション(現在のTraditional Web)はUI部分とSessionなど一部を除くと同じプログラムをReactive Web Appでも利用できる。

とはいえ、この方法も完全なわけではなく、例えばTraditional Web → Reactive Web Appの移行でも、UI部分は全然別なので乗り換えるならUI部分の再開発が必要だった。

(なお、OutSystems 10の頃には公表されていたアーキテクチャ設計手法に従っておらず、UIとビジネスロジックが混在したプログラムを書いてしまっていたら、多分そんなに簡単なことではなかった)

長期間稼働する予定のシステムをOutSystemsで構築するということは、この実行スタックの移行(最新技術への追随)をOutSystems社がうまいことやってくれるだろう、と賭けていることになる。例えば、20年運用するなら、こういう大規模な変更が2,3度はあるのでは?

Project Neoへの強制移行

実際は強制とは書いていないけど、以下の部分を見ると実質的に強制に見える。

クラウドについて

2027年3月までにユーザーがアプリケーションをProject Neoに移行しなかった場合は、Project Neoでの実行に必要なアプリとデータのアップグレードをOutSystems側で実施します。この場合も追加開発を行う必要はありません。

オンプレミスについて

OutSystems 11 Cloudユーザーと同様、少なくとも2027年3月まではセルフマネージドアプリケーションの実行を継続できます。また、OutSystems 11でのセルフマネージドアプリケーションのサポート終了の少なくとも2年前にはその旨をお知らせします。

プライベートクラウドとは?

プライベートクラウドって言ったら、普通は、いわゆるクラウドPaaSのベンダーが提供するものとは別に、ユーザー企業で独自に作るものな気がするが、

OutSystems 11アプリケーションをユーザーのプライベートクラウドで実行可能なProject Neoにアップグレードするためのオプションを提供します。これにより、アプリの実行に必要なものがすべてドメイン内に配置され、データやIPをすべて自分で制御できるようになります。このオプションは2024年末までに提供予定です。

これだと、AWSなんかが提供している機能(をたぶんProject Neoで利用しているので)と同等のものがプライベートクラウド側にある前提に見える。

今の段階では全然見えないが、プライベートクラウド運用をするときに必要な前提条件は結構難しい気がする。

デタッチは緊急脱出口程度に考えるのがいいんじゃないかな

  • Project Neoでは、生成したコード、アプリデータ、コンテナ構成、インフラ構成テンプレートをエクスポートできます。ユーザーがアプリを実行・運用するには、特定のPaaS機能をユーザーが所有するサービスに置き換える必要があります。このアプローチは、ロックインを防ぐためのものです。

とあるので、Project Neoでも、たとえOutSystemsをやめたとしても、モデルをコンパイルしたソースコードを取り出す機能は維持される。

現状でも十分難しいと思う(OutSystemsで作った大量のプログラムからデタッチしたC#・JavaScriptを始めとしたソースコードを見せられて、保守を引き受けます、なんていう技術者や会社がいるだろうか?)。しかし、Project Neoではコンテナを始めとする構成要素が複雑化しているので、ますまず難しそうだ。

デタッチ機能は、どうしてもやむを得ない場合の緊急脱出口程度に考えるのがいいんじゃないかな。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする