ソフトウェア スタックのコモディティ化: アプリケーション ファーストのクラウド サービスがゲームをどう変えるか

今日この記事を読んで、いいなと思ったので翻訳してみました。この記事は、Steef-Jan Wiggers著「ソフトウェアスタックのコモディティ化：アプリケーションファーストのクラウドサービスがゲームを変える方法」[1]から翻訳されたもので、内容はQCon LondonでのBilgin Ibryamの講演から抜粋したものです。 Ibryam 氏は、アプリケーション開発と運用・保守、つまり内部アーキテクチャと外部アーキテクチャという 2 つの異なる側面からアーキテクチャの進化について説明しました。両者の境界は、単一出願の時代には明確でしたが、今日ではますます曖昧になってきています。

アーキテクチャが進化するにつれて、アプリケーションは大きな変化を遂げ、機能がアプリケーションから分離されてインフラストラクチャに組み込まれたり、新しいインフラストラクチャになったりすると思います。インフラストラクチャも、狭義の物理的な施設やコンピューティング リソースから、継続的に製品化およびコモディティ化されているソフトウェア定義の機能へと進化しています。新世代のインフラストラクチャは、さまざまなランタイム方法でアプリケーションから独立していますが、両者は依然として特定の接続、つまり API を維持しています。

以下は原文の翻訳です。

クラウド サービスは絶えず進化しており、開発者が分散アプリケーションを構築する方法に影響を与えています。 QCon Londonでは、Diagrid[2]のプロダクトマネージャーであるBilgin Ibryam[3]が、Dapr[4]のようなクラウドネイティブ技術と開発者向けクラウドサービスの交差点について議論しました。

Ibryam氏はまず、モノリシックアプリケーション[5]からマイクロサービス[6]への移行をどのように考えるべきか、そして次に何が起こるのかについて説明します。さらに、クラウド サービスとそれがアーキテクチャの進化にどのように影響するかについても話しました。

講演の中で、Ibryam 氏はクラウド以前またはクラウド初期のアプリケーション構築のさまざまな段階 (タイムライン) について話し、インフラストラクチャとアプリケーションのトレンドの観点から、コンピューティング ファースト クラウドとアプリケーション ファースト クラウドの時代について考察しました。

Ibryam 氏は、アプリケーションがモノリシックであったことを意味していたクラウド以前、または初期のクラウドから議論を始めました。この時代はクラウド コンピューティングが主流になる前であり、マイクロサービスは存在しませんでした。代わりに、開発者は、非同期のやり取り (メッセージングなど) からパッケージ化やキャッシュまで、ビジネス ロジックに関するすべてを使用する必要があります。さらに、アプリケーション層とインフラストラクチャは、開発者チームと運用チームという 2 つのチームによって管理されます。

次に、Ibryam 氏はクラウド コンピューティングの初期の内部アーキテクチャについて説明しました。 2010 年以降、アプリケーション開発への関心が再び高まり、今日でも影響力のある重要なソフトウェア開発のトレンドがいくつか生まれました。 C4モデル[7]や4+1アーキテクチャモデルビュー[8]を使用してアーキテクチャを視覚化して記述することで、アーキテクチャをさまざまな視点から見ることができます。 Ibryam はより直接的なアプローチを採用し、内部アーキテクチャと外部アーキテクチャの 2 つのレベルに分割します。内部アプリケーション アーキテクチャとは、アプリケーション内のさまざまなレイヤーなど、開発者が作成して完全に制御できるすべてのもの、つまり、彼の言葉を借りれば、コンテナ イメージに含まれるすべてのものです。運用 (Ops) の観点から見ると、これはブラック ボックスです。外部アプリケーション アーキテクチャは、メッセージ ブローカー、データベース、さらにはクラウド サービスなど、アプリケーションが対話するすべてのものの集合です。 Ops は信頼性や観測性などを高めます。これに基づいて、彼はドメイン駆動設計[9]、[六角形アーキテクチャ](https://en.wikipedia.org/wiki/Hexagonal_architecture_(ソフトウェア「六角形アーキテクチャ」))、オニオンアーキテクチャ[10]、クリーンアーキテクチャ[11]など、モノリシックアプリケーションの開発に影響を与えたいくつかのアーキテクチャ設計方法論について説明しました。 12ファクターアプリケーション[12]とマイクロサービス[13]の原則はこれらのアプローチに従っており、モノリシックアプリケーションはほぼアンチパターンになっています。

クラウド以前、そしてクラウドの初期の頃には、コンピューティングファーストのクラウドが登場し、モノリシックなアプリケーションからマイクロサービスへと移行しました。オンプレミスのアプリケーション アーキテクチャの変更とクラウドの登場により、アプリケーションとそのインフラストラクチャ間の統合が分離されました。

コンピューティングファーストについて言えば、Ibryam 氏はアプリケーションの内部アーキテクチャとクラウドによって提供されるコンピューティングについて詳細に説明しました。コンテナ、関数、サーバーレス アプリケーションなど、アプリケーションとコンピューター間のプロトコル (統合バインディング) です。これは、両端の API 間で発生します (リソース要件、デプロイメント、構成、メトリックなどの操作呼び出し)。通常は運用チームの責任です。

次に、Ibryam 氏は、クラウドの登場によりアプリケーションの外部アーキテクチャがどのように変化したかについて説明しました。アプリケーションバンドルの概念が再度議論されました。しかし、今では、開発者の責任となるのは、その下にあるインフラストラクチャではなく、アプリケーション上のクラウド サービスに関するものになりました。

クラウドサービスへの統合バインディングは、分散アプリケーションランタイム（Dapr）[14]などの別のレベルに移動できます。この点に関してDaprを比較するために、Ibryam氏はクラウド特有のサービスとしてGoogle Cloud Event Arc[15]、AWS EventBridge[16]、Azure Event Grid[17]を挙げ、言語に依存しないサービスとしてCamel[18]を挙げた。 Dapr は両方の組み合わせです。

最後に、Ibryam 氏は、アプリケーション ファースト クラウドについて語りました。アプリケーション ファースト クラウドでは、たとえば、ネットワーク サービスがよりアプリケーション中心になり、統合クラウドが誕生しました。統合クラウドとは、何よりもまず、開発者向けに作成された一連のマネージド サービスです。

アプリケーションファーストのエコシステムには、Azure Eventgridなどのイベント処理サービスへの非同期バインディング、AWS Step Functions[19]などのサービスへの状態バインディング、Vercel Edge Middleware[20]などのサービスへの同期バインディング、AWS ECS[21]、Azure Container Apps[22]、Google Cloud Run[23]などのコンピューティングサービスへのコンピューティングバインディングが含まれます。通信はOpenAPI仕様[24]に準拠したAPIを通じて行われます。最後に、イブリアム氏はスピーチから以下の重要な点を指摘しました。

• ビジネス ロジックの差別化と、差別化されていないコモディティ化された機能の再利用に重点を置きます。
• 移植性のために、事実上の標準に基づいたオープン コンピューティングとオープン統合バインディングを使用します。
• 移植性はアプリケーションに関するものではなく、パターン、プラクティス、ツール、および人材に関するものです。

著者について

Steef-Jan Wiggers 氏は InfoQ のシニア クラウド エディターの 1 人で、現在はオランダの HSO でテクニカル統合アーキテクトとして働いています。彼の現在の技術的専門知識は、統合プラットフォームの実装、Azure DevOps、および Azure プラットフォーム ソリューション アーキテクチャに重点を置いています。 Steef-Jan 氏は、オランダの Azure ユーザー グループの理事であり、カンファレンスやユーザー グループで定期的に講演し、InfoQ や Serverless Notes に記事を寄稿しています。さらに、マイクロソフトは彼を 11 年連続で Microsoft Azure MVP として認定しています。

参考文献

[1] ソフトウェアスタックのコモディティ化：アプリケーションファーストのクラウドサービスがゲームを変える：https://www.infoq.com/news/2023/03/application-first-cloud-services/​​

[2] ディアグリッド: https://www.diagrid.io/​​

[3] ビルギン・イブリャム: https://qconlondon.com/speakers/bilginibryam

[4] Dapr: https://dapr.io/

[5] モノリシックアプリケーション: https://en.wikipedia.org/wiki/Monolithic_application

[6] マイクロサービス: https://en.wikipedia.org/wiki/Microservices

[7] C4モデル: https://en.wikipedia.org/wiki/C4_model

[8] 4+1建築ビューモデル: https://en.wikipedia.org/wiki/4%2B1_architectural_view_model

[9] ドメイン駆動設計: https://en.wikipedia.org/wiki/Domain-driven_design

[10] オニオンアーキテクチャ: https://www.codeguru.com/csharp/understanding-onion-architecture/

[11] クリーンアーキテクチャ: https://betterprogramming.pub/the-clean-architecture-beginners-guide-e4b7058c1165

[12] 12ファクターアプリ: https://en.wikipedia.org/wiki/Twelve-Factor_App_methodology https://en.wikipedia.org/wiki/Twelve-Factor_App_methodology

[13] マイクロサービス: https://en.wikipedia.org/wiki/Microservices

[14] 分散アプリケーションランタイム（Dapr）: https://dapr.io/

[15] Google Cloud イベントアーク: https://cloud.google.com/eventarc/docs/

[16] AWS イベントブリッジ: https://docs.aws.amazon.com/eventbridge/index.html​​

[17] Azureイベントグリッド: https://learn.microsoft.com/en-us/azure/event-grid/​​

[18] キャメル: https://camel.apache.org/manual/faq/what-is-camel.html

[19] AWSステップ関数: https://aws.amazon.com/step-functions/​​

[20] Vercel Edgeミドルウェア: https://vercel.com/docs/concepts/functions/edge-middleware​​

[21] AWS ECS: https://aws.amazon.com/ecs/​​

[22] Azure コンテナー アプリ: https://learn.microsoft.com/en-us/azure/container-apps/overview​​

[23] Google Cloud Run: https://cloud.google.com/run/​​

[24] OpenAPI仕様: https://swagger.io/specification/