Apigee Edgeプラットフォームを活用し、レガシーシステムからマイクロサービスへの移行を支援。
はじめに
Apigeeエッジは新しいマイクロサービスベースのアーキテクチャの一部であったため、マイクロサービスに代わってレガシー認証機能を呼び出すためにApigeeレイヤーを活用しました。
ロイヤルカリビアンについて
私たちのクライアントは、10年前のレガシー・システム(モノリシック・アプリケーションのセット)ですべてのIT要件に対応していた。 今日、ソフトウェアとITの要件は非常にダイナミックであり、最高の消費者体験を提供するためには、クライアントは迅速な変更を行う必要がある。
主要な目標のひとつは、デジタル領域で機敏かつ迅速に動き、顧客に新しいアプリケーションやサービスを継続的に展開し、競争力を維持することだった。 私たちは、新サービスの迅速な展開というニーズに応え、既存システムのもろさ(新しい変更の導入が難しく、そのサイクルが長引く)を取り除くために、マイクロサービス・ベースのアーキテクチャの採用を提案した。 マイクロサービスとは、ひとつの仕事をうまくこなすことであり、可能な限りモジュール化することで、モノリシックなシステムの課題を解決するものである。 最も単純な形では、アプリケーションを小さなサービス群として構築するのに役立ち、それぞれがプロセス内で動作し、独立してデプロイできる。
課題
主な課題は、現在のアプリケーションを新しいアプリケーションに移行する一方で、すべてをそのまま生かして稼働させることだった。 そこで、移行には段階的なアプローチを採用し、一度に1つのサービスを実装し、レガシーシステムの現在の機能をそのマイクロサービスに置き換えることにしました。
しかし、レガシー・アプリケーションの一部は、ビジネスに役立っていたので、まだ使うことができる。 特定のコンポーネントの機能を新しいアーキテクチャで再利用する方法を見つける代わりに、システム全体を移行する必要はない。 そのような機能のひとつが、ロールベースの認証コンポーネントである。ユーザーとそのロールの認証には、複数のレガシー・コンポーネントが関与するため、複雑な機能であった。 このサービスを移行するのは大変な作業で、ビジネス上の付加価値もなかったので、レガシー認証を続けることにしました。
ユーザーを認証するために、すべてのマイクロサービスがレガシーシステムの認証機能を呼び出していた。 その後、多くのマイクロサービスを通じてレガシー・サービスを呼び出すことはアイドルではないことに気づいた。 セキュリティ上の脅威が発生する可能性があり、すべてのサービスで機能を複製しなければならなくなる。
解決策
Apigeeエッジは新しいマイクロサービスベースのアーキテクチャの一部であったため、マイクロサービスに代わってレガシー認証機能を呼び出すためにApigeeレイヤーを活用しました。 Apigeeを使用することで、マイクロサービスをレガシーアプリケーションに対して不可知論的に保つことができました。Apigeeは、ユーザーを認証するためにレガシーアプリケーションと通信する唯一のレイヤーだったからです。
上の図では、Product、Order、Inventoryマイクロサービスを直接呼び出す代わりに、ユーザはApigeeにAPIコールを行います。 Apigeeはレガシー認証サービスを使用してAPIコールを認証し、リクエストが認証された場合、APIはAPIコールを基礎となるマイクロサービスに委譲します。
その結果
– Apigee Edgeプラットフォームを活用することで、お客様はシステムを稼動させたまま、レガシーサービスを段階的にマイクロサービスに移行することができました。
– システムに対するユーザーのインタラクションは、アピジー層のみに限定された。したがって、マイグレーション・プロセスで発生するすべての基礎的なマンボ・ジャンボに対して、ユーザーは不可知論的であり続けた。
– ApigeeはOAuthとLDAPのセキュリティ・ポリシーをすぐに使えるので、新しいシステムはより安全です。
ケーススタディをもっと読む
大手デジタル広告サービスとの1年にわたるRPAの旅を垣間見る
大手デジタル広告サービス・ソリューションプロバイダーの1年にわたるRPAの旅と、NashTechがどのように彼らを支援したかをご紹介します。
デジタル棚の分析をサポートし、eコマースの成長を引き出す
NashTechがどのようにデジタル棚の分析を支援し、世界有数のデータ洞察とeコマースソリューションプロバイダーと成長を解き放つかをご覧ください。
あなたのプロジェクトについて話しましょう
- トピックス