アジャイル・インテグレーションに Red Hat を選ぶ理由

誤解しないでください。革新的な製品とサービスを継続的に提供することは、デジタル市場で競争力を維持するために重要です。しかし、他のレガシー・テクノロジーと適切につながれていなければ、新しいアプリケーションの良さが損なわれてしまいます。しかも、この新しいアプリケーションを既存のアーキテクチャと統合するのに数カ月から数年も要するようでは、ビジネスに実際の価値がもたらされるまで、途方もなく長い時間がかかります。

アジャイル手法、DevOps、CI/CD 自動化、またはその他のよく耳にする IT の流行語に代表される技術により、ウォーターフォール開発サイクルの時代は終わりを告げました。しかし、開発者の生産性が向上したら終了というわけではありません。イノベーションには統合が必要で、しかも現在の開発作業と速度を揃える必要があります。

Red Hat は、一元化やサイロ化アーキテクチャではなく、分散および反復統合アーキテクチャが、アプリケーション開発のみならずインフラストラクチャにも俊敏性をもたらすと考えています。正確には、コンテナ化されたマイクロサービス、ハイブリッドクラウド、アプリケーション・プログラミング・インタフェース (API) を、開発者がよく知っているアジャイルな DevOps 手法と連携した、アーキテクチャ上のフレームワークです。

Red Hat ではアジャイル・インテグレーションを、統合テクノロジー、アジャイル・デリバリー・テクニック、およびクラウドネイティブ・プラットフォームを組み合わせてソフトウェアを提供する際の速度とセキュリティを向上させるものであると考えています。具体的に言うと、アジャイル・インテグレーションでは、API のような統合テクノロジーを Linux コンテナにデプロイし、機能横断型チームが統合の役割を担うようになります。

このフレームワークでは、マイクロサービスの迅速な開発と迅速な統合が可能です。Red Hat® Fuse 上で統合し、API を Red Hat 3scale API Management で管理すると、マイクロサービスを実際的に既存のアーキテクチャにシームレスに「落とし込む」ことができます。このため、内外のユーザーへの価値提供をすぐに開始できます。データをインフラストラクチャ内で共有するため、Red Hat AMQ は高スループットで低レイテンシーのメッセージングを活用します。サービスをアップデートまたは削除したことでアプリケーション全体が破損するリスクはなくなります。アジャイル・インテグレーション・プロセスによる疎結合のアーキテクチャではフォールトトレランスが向上しているからです。

つまり、アジャイル・インテグレーションによってエンタープライズ統合は、解決すべき問題から、分散したサービスに対して柔軟に拡張できるプラットフォームへと変化したのです。

問題：物流の世界大手である UPS は、Center Inside Planning and Execution System (CIPE) と呼ばれる新しいアプリケーション・プラットフォームを使用して、梱包業務と配送を効率化したいと考えていました。さらに同社は、CIPE の新機能とこの新しい作業方法の両方をサポートする、より俊敏なコラボレーション方式の DevOps アプローチ/テクノロジーの採用を希望していました。UPS のアプリケーション開発担当シニアマネージャー、Rich West 氏は次のように語っています。「私たちは、従来のテクノロジーからクラウドに移行し、リアルタイムのビッグデータ分析を活用して、より効果的な意思決定を行う必要がありました」

ソリューション：UPS は、コンテナ・テクノロジーがクラウドベースの俊敏なワークフローへのニーズを満たすと判断し、さまざまなソリューションを評価しました。同社は新しいアプリケーション環境の構築に、Red Hat のエンタープライズ・オープンソース・テクノロジーを使用することに決めました。UPS はさらに、CIPE の計画とデプロイメントについて、Red Hat コンサルティングにサポートを求めました。UPS のアプリケーション開発担当シニアマネージャー、Stacie Morgan 氏は、次のように述べています。「Red Hat コンサルティングは、開発者を対象にコンテナ・プラットフォーム・テクノロジーのトレーニングを実施してくれました。3 カ月でサイトアプリケーションの最初の反復処理を開始できるようになりました。これほど迅速にプラットフォームを立ち上げられたのは初めてです」