なぜMuleSoftは”Spark joy”なのか？
MuleSoft Advent Calendar 2019 の25日目ということで、少し個人的な経緯も含めて、なぜMuleSoftがこんなにも ”ときめき(Spark Joy)” をもたらすのか、そして今後ますます重要になっていくのかについて自分の考えをまとめました。
個人的な経緯
部門の異動や緊急プロジェクトなどを間に挟みつつも、2008年にSalesforceに入社してから業務として10年ほど、一貫してパートナーや開発者への技術情報の提供、マーケティング活動、コミュニティ支援などを行っていました。
Salesforceを10年間ひたすら触り続けて来て言えることは、Salesforceは得意領域(CRM + 周辺のライトなアプリ開発)においては間違いなく世界最高のツールです。ただSalesforceはインフラ、ミドルウェア、開発言語、フレームワーク、UIに至る部分まであらゆる面を独自に抽象化して使いやすさ高めている反面、想定規模外のデータ量や複雑性、他のツールと組み合わせた開発プロセスを構築しようとする場合に苦労が多いことも事実です。
2010年台前半までは、Salesforceほど多機能でエンタープライズグレードを謳うクラウドサービスも今ほど多くは無い上に、日本の市場動向などもあり、なるべく多くの業務をSalesforce上に寄せる事がアーキテクチャとして有力でした。(だと思っていました)
しかし昨今ではContainer, Serverless, Service MeshからNoSQL/NewSQL , BigData, DMSA, PipeLine, Cloud AIに至るまで、様々な企業や業界団体からモダンで高機能なサービス・ツール群が多数リリースされ、またそれらが一般的に活用されるようになり開発モデルに大きな変化を見せているので、1社のサービスに過度に寄せずに適宜最適なサービスを組み合わせて利用すべきなのはもはや明白です。
そんな折、2018年にMuleSoftがSalesforceに買収され子会社となり、日本の立ち上げを計画していました。色々調べていくうちにMuleSoftは自分が感じていた課題に対してかなり高いレベルで解決策を提供するサービスだということが分かり、 ”ときめき(Spark Joy)”を感じたのを覚えています。
元々Salesforceではエヴァンジェリストだったので、MuleSoftも含めた全体感を啓蒙する事も可能なロールではあったのですが、エンジニアとしてマーケティングメッセージに依存せずに自分の言葉で会話できる環境と、より高い技術力を付けてそれを活かすために部門(会社？)異動をしました。
エンタープライズシステムが抱える課題
さて、個人的な経緯はさておき、今エンタープライズの世界では（バズワードの呼び声も高い） ”デジタルトランスフォーメーション”が叫ばれています。ビジネス的な側面も含むこの言葉ですが、技術的な側面のみで言えば、ITシステムの利便性と敏捷性を高めて、迫りくるビジネス要件に対して素早く対応できるアーキテクチャを構築する事がゴールとなります。
しかしエンタープライズシステム全体を見回すといくつかの課題があり、この”デジタルトランスフォーメーション”の実現を阻害しています。
アンロック出来ていない既存システム
- レガシーモダナイゼーションを実施し、企業の既存システムとデータをアンロックし利用価値を高めていかなければ競争に勝てない
- しかしどのように既存システムをアンロックしていけば良いのかの知見が少なく、企業は頭を悩ませている
増え続ける接続先とサービス
- GAFA等のIT全体にまたがるプラットフォーマーや多くのSaaSベンダーが次々と有効なツールやサービスを提供しており、素早く取り入れていかなければ競争に勝てない
- 更にモバイル、ウェアラブル/IoTデバイスなど、ネットワークにつながる/繋げなければならないクライアントは増え続ける
- 従来の個別対応では開発と管理の限界が来ている
求められるビジネス要件の増加
- 伴って増え続けるシステムに対する追加・変更依頼から、新たな販売チャネルへの対応などITのバックログが増え続けている
- IT部門の予算や人員は増える要件と比例しないので、ギャップが大きくなる一方
このような状況において、今までのやり方の延長ではなく別のアプローチが必要です。
これからのエンタープライズシステムにとって最も必要なものは何か？
では既存システムのアンロックから、DMSAやらAIのような概念的に新しいものまで、世の中に溢れる多種多様なシステム・サービスと立ち向かわなければならない状況において、エンタープライズシステムにとって最も必要なものは何か？という問いに、私は以下の2つが解だと考えました。
- レガシー/オンプレミスシステム、 マイクロサービス、クラウドなど、全てのシステムとの接続を可能にする相互な接続性
- 多数のシステム間を効率的にオーケストレーションしつつ、それらを効率的に管理する方法論とツール
そして、現時点で最もこの要件を高いレベルで満たす事のできるツールがMuleSoftのAnypoint Platformだと思っています。
”Spark joy”なMuleSoft Anypoint Platform
まず、レガシー/オンプレミスシステムとの接続自体は従来のESBの得意領域ですし、iPaaSと呼ばれる製品であれば、ESBの領域に加えて各種SaaSとの連携やランタイム自体のクラウド上での稼働など、相互な接続性に関して一定の解を与えてくれます。MuleSoft Anypoint PlatformもESBをベースとしたiPaaSの側面を持っていますので様々なシステムとの接続が可能です。
しかしiPaaS製品の課題として、機能としてオーケストレーションフローは持っていても、あくまでPoint to Pointでの接続への最適化を前提としているため、各システムを抽象化し再利用性と敏捷性を高めていくという視点がありません。つまりオーケストレーションのスパゲティコード(フロー)が誕生しがちになります。
では、効率的に管理する方法論とツールはどうすれば良いでしょうか？
私はここにオーケストレーションフローとAPIマネージメントとの統合が重要だと思っています。
例えばJavaの世界では、OOP(オブジェクト指向プログラミング)とDI(依存性注入)、AOP(アスペクト指向プログラミング)の方法論を組み合わせたSpringによってモダンなプログラミング手法が確立されました。
共通化・再利用できる処理はサービスとして切り出し、実装の入れ替えを容易にするためにIntefaceに対して実装をInjectし、横断的な処理はAdviceをWeaveすることで効率性を高めています。
オーケストレーションフローの世界でも、このような効率性の高い設計を可能にするのがAPI管理との統合だと思っています。
MuleSoftの場合、フローを構築する際にコネクタと呼ばれる部品(フロー内の各アイコン)を使って各システムとのやり取りを行いますが、API管理機能と統合されているので、APIマネージャー側で定義したAPI定義+エンドポイントがフロー内からそのまま利用できます。
(正確にはAPIを作成やアップロードするとコネクタが自動生成される）
APIの管理とオーケストレーションフロー内の部品の管理は同一のものとして扱われます。実態がAPI定義+エンドポイントであるということは、オーケストレーションフローに対して認証や流量制限と行ったAPIポリシーなどを後から横断的に定義することも、下位互換のある新しいAPIにバージョンアップすることも、API定義は変えずにバックエンドの実装だけを切り替える事も可能です。
厳密には異なりますが、先程のSpringに例えるならMuleでのフロー開発は
サービスの抽出 -> サブフロー化などフローの再利用
DIによるInject -> API定義と API実装
AOP -> APIポリシーによる横断的な処理
のイメージに近いと思います。1日目にf_yuya773さんが投稿してくれた API-led Connectivity は必ずしもMuleSoftでなくても実現ができるAPIインテグレーションにおけるデザインパターン的な概念ですが、なぜMuleSoftだとそれが実現しやすいのかは、このAPI管理との統合によって、オーケストレーションフローの開発を含めたのSDLC全体が圧倒的に素早く回せることに理由があります。
最後に
必ずしもMuleSoftである必要はありませんが、MuleSoft Anypoint PlatformのようなiPaaSとAPI Managementが完全に統合されたツールがこれから更に多様化していくエンタープライズシステムにとって必要な存在だと信じています。
またその領域に強みを持つエンジニア/アーキテクトも市場の高いニーズによって、より無くてはならない存在になると信じています。
同じような意識を持つ人達で知見や経験を共有し、この領域の発展に貢献できたならと思っています。
皆様2019年はありがとうございました。2020年も宜しくお願い致します。
Merry Christmas & Happy New Year
