OutSystms Developer Cloud ( ODC ) とは? ~OutSystems 11との違いをわかりやすく解説~(vol.22)
- 公開日:
- 最終更新日:
2023年4月より、OutSystemsの新製品である「OutSystems Developer Cloud(以降、ODCという)」の日本での提供が開始されました。
「ODC」は、“クラウドネイティブな環境で”アプリケーションを開発・運用することができるローコードアプリケーション開発プラットフォーム製品として再構築されており、開発者はさらに優れたパフォーマンスや、卓越したDevOpsなどのメリットを享受することができます。
本ブログ記事では、「ODC」の概要・特長や、従来の製品である「OutSystems 11(以降、OS11という)」との違いについて解説します。
OutSystems Developer Cloud(ODC)の特長とは?
「OutSystems Developer Cloud(ODC)」は、OutSystems社が提供するAWSを基盤とした最新のローコードアプリケーション開発プラットフォームです。Self-Managed(オンプレミス)のエディションも選択できた従来の「OS11」と比べると、最初からクラウドの利点を最大限に活用できるよう設計された“クラウドネイティブ”な製品として、主に次の2点の効果を享受できるようになりました。
コンテナ技術の採用による可搬性(ポータビリティ)の向上
「ODC」で開発したアプリケーションは一つの“コンテナ”にまとめられます。“コンテナ”はいわば、仮想化技術における「ゲストOS」から「アプリケーション」までを一つのパッケージにまとめたものです。これによりコンテナの特長である「可搬性(持ち運びやすいこと。ポータビリティ)」を、OutSystemsでも活かせるようになりました。
- コンテナのメリット①今までよりもさらに高速なデプロイ
DevelopmentステージでアプリケーションをPublishすると、ステージ上でコンテナイメージ(コンテナを生成できるもの)が作成されます。QAステージやProductionステージへのデプロイは、コンテナイメージをそれぞれの環境でコンテナにパッケージ化するのみですので、高速なデプロイが期待できます。OS11でデプロイごとにアプリケーションをビルドしていた場合と比べても、その差をはっきりと体感できることでしょう。 - コンテナのメリット②オートスケール
ステージ上のアプリケーションのCPUやRAMの使用状況は常に監視されており、負荷の高まっているアプリケーションのコンテナを自動で複製(スケールアウト)して、負荷を分散させることができます。
また、コンテナのコンピューティング能力そのものをさらに強化すること(スケールアップ)も自動で行ってくれます。「OS11」のCloudエディションでは、サーバの拡張は個別にサポートチケットをリクエストする必要があったため、「オートスケール」によって得られるメリットは「OS11」とは比較にならないほど大きいでしょう。
マイクロサービス化による拡張性・柔軟性の向上
コンテナ技術が採用されたことにより、アプリケーションはマイクロサービスとして機能することが前提になりました。マイクロサービスとは、アプリケーションを細かな機能に分割し、それぞれ独立したサービスとして開発・デプロイするアーキテクチャの思想です。アプリケーション間の通信はAPIを介するため、互いの依存関係は弱い状態(疎結合)となります。
マイクロサービスアーキテクチャは、コンテナ技術と組み合わさることでもたらされる拡張性の高さや、機能に変更が発生した際の影響範囲を極小化できることが特長です。OS11でもマイクロサービスアーキテクチャを設計することはできましたが、「ODC」ではコンテナ技術のメリットを最大化すべく、機能面でもマイクロサービスアーキテクチャ化を前提とした設計ができるよう、様々な変更が施されました。変更の詳細は、次章で解説します。
OutSystems Developer Cloud(ODC)とOutSystems 11との違いとは?
OutSystems社は、「ODC」について、「OS11」と変わらない開発体験を提供していると謳っています。実際に筆者が「ODC」でアプリケーションの実装を行ったところ、画面やビジネスロジックなどの機能については、「OS11」からの大きな変化を感じることなく実装することができました。
しかし、必ずしも「OS11」と変わらない開発体験とは言い切れないポイントも体感しました。
そこで、いくつかの代表的な「OS11」からの変更点を解説します。
- モジュールが撤廃
「ODC」では、モジュールの概念が撤廃され、よりシンプルな構成になっています。新規作成時に選択できるアプリケーションの形式は「App(Web/ Tablet/Phone)」 または 「Library」のどちらかです。ここでの選択は実装できる機能に大きく影響するため、事前にビジネスコンセプトを分析しておく必要があります。
「App」と「Library」には、次のような違いがあります。
【App】
Appは、「OS11」で実装できたほとんどの機能に加え、「Service Action」が標準で実装できるようになっています。実装面では「OS11」からの変化を感じることはあまりないですが、Public化できる要素は大きく変化しました。
「ODC」でPublicにできるのは、画面 / Service Action / Entity / Static Entity / Structure のみです。またEntityは読み取り専用としての公開となります。つまり、「ODC」のAppからの公開要素はすべて弱い依存関係(疎結合)の状態となるものに限られました。
(画像出典:OutSystems Developer Cloudのアプリ)【Library】
Libraryは、「OS11」にも存在していた同名のモジュールタイプの概念を継承しています。Entity / Role / 公開API / Client Variables を作成することができないのは、「OS11」の時から変わりません。
大きな変化点として挙げられるのは、リビジョン(バージョン)の管理が可能になったことです。「ODC」においては、Libraryを「Publish」するだけではコンシューマー側の参照の更新は求められません。Libraryを「Release」することで初めて環境全体のAppで参照可能になります。またコンシューマー側はリビジョンのアップデートを好きなタイミングで実施することができます。
LibraryとAppは密結合状態になるため、Libraryのリビジョンの柔軟性が高まったことは、アプリケーション開発のライフサイクルを向上させる点において、非常に効果的なアップグレードと呼べるでしょう。
その他の変化点としては、Static EntityをLibraryで作成した際、OutSystems内部での扱いとして、データベーステーブルではなく列挙型のように定義されるようになりました。
(画像出典:OutSystems Developer Cloudのアプリ) - 管理コンソールの統合
「ODC」では、「ODC Portal」という環境の管理コンソールが提供されます。
「ODC Portal」では、以下のような管理操作を行うことが可能です。【アプリケーションの管理】
・「設定(旧Site Property)」の変更
・ログの分析
・デプロイ【開発者の管理】
・組織ユーザー(旧ITユーザー)の作成
・組織ユーザーの権限の管理【エンドユーザーの管理】
・エンドユーザーの作成
・グループの作成
・エンドユーザーやグループへのアプリケーションロールの紐づけ「OS11」では、これらの機能は 「Service Center」 「Users」 「LifeTime」 の3つのアプリケーションに分離していました。開発者は操作する内容によってコンソールを往復する必要があり、やや非効率な側面がありました。
「ODC」ではこれらの環境管理の機能が統合され、使いやすくなっています。
また、これまで別々に管理されていた「組織ユーザー」と「エンドユーザー」が統合されています。これにより、ユーザーにまつわる概念は格段に理解しやすくなりました。 - システムロールの概念が廃止
「ODC」では、アプリケーションへのアクセス権限を定義する際、「Everyone(全員)」 か 「Authenticated Users(認証済みユーザー)」 のいずれかを選択します。「Everyone」を指定した場合は、URLにアクセスできる全てのユーザーにアプリケーションが公開されます。「Authenticated Users」を指定した場合は、App内で定義した一つ以上のRoleにチェックをつけて、アクセス権限を与える必要があります。「OS11」では、ログイン済みのユーザーを「Registered」というシステムロールとして扱い、その他のカスタムロール(モジュール内で独自に定義したロール)を持たなくともアクセスできる状態が実現可能でした。
「OS11」の時も権限管理上、多くのアプリケーションでカスタムロールを作成しユーザーに付与する運用をしていたでしょうから、アプリケーションのセキュリティを向上させる改善として良い変更と受け取れます。
まとめ
本ブログ記事では、「ODC」の特長と、従来の「OS11」との違いについて解説して参りました。
「クラウドネイティブ」や「マイクロサービスアーキテクチャ」を中心に据える開発プラットフォームとなったため、パフォーマンスやDevOpsの側面でプラットフォームに一任できる要素が非常に増えたように感じられます。
一方で、プラットフォームの特長を活かすためには、開発者はこれらの技術要素を理解し、適切にアプリケーションを設計できる必要性が高まりました。OutSystemsは導入するだけで上手くいくものではありません。OutSystemsならではのノウハウを常に学び、開発者に共有する仕組みの存在がその成功を左右することでしょう。
ODCにおけるLibraryの概要と「リリース」機能の特長について「OutSystems Developer Cloud ( ODC ) のLibraryとは?~リリース機能について、実際の画面で解説~(vol.23)」のブログで解説しておりますので、是非ご覧ください。
また、ODCにおけるIdPの概要とその設定方法について、「OutSystms Developer Cloud ( ODC ) のIdP認証機能とは? ~特長と設定方法を実際の画面で解説~(Vol.24)」のブログで解説しておりますので、そちらも併せてご覧ください。
弊社では様々なOutSystemsの導入・開発の知見をもとに、お客様の社内でOutSystemsの活用を推進するCenter of Excellence(CoE)チームを組成し、スムーズな導入と利用範囲の拡大をご支援するサービスをご提供しております。CoEチームの有用性や組成方法についてご興味のある方は、是非、弊社までお問い合わせください。
弊社電通総研は、ローコード開発プラットフォーム:OutSystemsの導入/活用を支援する様々なサービスメニューをご用意しております。
ローコード開発のはじめの一歩を、電通総研と一緒に踏み出してみませんか?
電通総研のOutSystems関連サービスページ:https://itsol.dentsusoken.com/outsystems/service/
本ブログは、2023年12月1日時点の情報をもとに作成しています。
OutSystemsに関する詳しいお問い合わせは、弊社Webサイトからお問い合わせください。
https://itsol.dentsusoken.com/outsystems/inquiry/