MicrosoftのAzureインキュベータチームは最近、「Radius」と呼ばれる新しいアプリケーションプラットフォームをリリースしました。Radiusプラットフォームは、Kubernetes、パブリッククラウド、エッジ環境でさまざまな最新アプリケーションを実行するために使用できます。

Radius はオープンソース プロジェクトであり、当初は Kubernetes、Azure、AWS などのアプリケーション ランタイムをサポートし、後に Google Cloud Platform などのクラウド環境もサポートする予定です。

マーク・ルシノビッチは、Microsoft Azureクラウドプラットフォームの最高技術責任者（CTO）であり、Radiusのアーキテクトでもあります。ルシノビッチは、Microsoftのエグゼクティブバイスプレジデントであるスコット・ガスリーと共に、オリジナルのWindows Azureを再構築し、Amazon Web Servicesに匹敵する魅力的なパブリッククラウドプラットフォームへと進化させました。

Windows Azureの当初のビジョンは、Microsoft .NET開発者向けのPaaS（Platform as a Service）製品を作成することでした。しかし、オープンソースの台頭とAmazon EC2の急速な発展により、MicrosoftはインフラストラクチャとプラットフォームサービスをサポートするためにWindows Azureをゼロから再構築せざるを得なくなりました。Russinovich氏と彼のチームは、将来クラウドサービスポートフォリオに追加される可能性のある様々なサービスをサポートできるスケーラブルなフレームワークとしてAzureを構築しました。

Azureのスケーラビリティは、多機能なコントロールプレーンに体現されています。Azureコントロールプレーンは、Microsoftのパブリッククラウドにデプロイされた仮想マシンや機械学習モデルの実行を含む、あらゆる機能を処理します。また、Azureコントロールプレーンにより、MicrosoftはAzure Stackを活用したプライベートクラウドやエッジ環境にもスケーラビリティ機能を拡張できます。

AzureコントロールプレーンはRadiusに大きな影響を与えます。どちらも非常にスケーラブルで拡張性に優れています。主な違いは、Radiusはオープンソースプロジェクトであり、主にコンテナまたはプロセスのセットとして実行され、オプションでKubernetesにデプロイされる点です。Azureコントロールプレーンと同様に、RadiusはAzureやAWSなどのリソースライフサイクル管理を担う独立したリソースプロバイダーと連携するように設計されています。

Radiusには、コンテナ化されたアプリケーションを管理するためのリソースプロバイダースイートが付属しています。Radiusの初期バージョンには、AzureとAWSのリソースプロバイダーが含まれています。他のクラウドプロバイダー（GCPなど）を追加するのは、Radiusで新しいリソースプロバイダーを作成して登録するだけです。

Radius プラットフォームのスケーラブルレイヤーは、UCP（Universal Control Plane）と呼ばれています。まさにその名の通りです。Azure と同様に、UCP は API リクエストを受け付け、Kubernetes、Azure、AWS などの適切なリソースプロバイダーに委任します。

ここで重要な点は、Radius が Azure のスケーラブルで信頼性の高いリソース管理方法を大幅に借用していることです。

インフラストラクチャをコードとしてアプリケーションに拡張する

Radius を使用すると、開発者はアプリケーションのデプロイ場所に関係なくアプリケーションを定義できます。Radius は、Azure Bicep と Terraform という 2 つの一般的なドメイン固有言語 (DSL) を使用して、アプリケーションとその依存関係を宣言することをサポートしています。

Azure Bicep と Terraform を使用してアプリケーションを宣言することは、Radius の優れた設計上の決定の一つでした。アプリケーションとその依存関係の定義に新しい形式が導入されることはなく、新しいマークアップ言語の習得に伴う学習曲線を排除しました。

Radius プラットフォーム (画像: Microsoft)

Microsoftコミュニティでは、Azure Bicepは既に広く知られています。Azure Bicepは、宣言型の構文を用いてAzureリソースをデプロイするためのドメイン固有言語です。ユーザーは、AzureにデプロイするインフラストラクチャをBicepファイルに定義し、そのファイルを使用して開発ライフサイクル全体を通してインフラストラクチャを繰り返しデプロイできます。

Terraformは、人気のInfrastructure as Codeツールです。クラウドサービスのライフサイクルを宣言的に管理するための事実上の標準となっています。ほぼすべてのクラウドプロバイダーとインフラストラクチャリソースプロバイダーがTerraformモジュールを提供しています。

Radiusチームは、車輪の再発明をする代わりに、アプリケーションを定義するためのDSLとしてBicepとTerraformを採用しました。Terraformプロバイダーのサポートはまだ実装されていませんが、Radiusのロードマップに含まれています。

Radius は開発者とオペレーターの役割を分離します。

Radiusのコア機能の一つはレシピ作成です。これは、企業の中央ITチームによって定義・管理されるサービスのカタログと見なすことができます。Radiusのレシピは、データベース、メッセージキュー、ストレージサービス、キャッシュサービスといった基盤となるサービスの実装を隠蔽します。

一方、運用チームは、抽象的な実装の詳細に関するレシピを定義し、公開する必要があります。開発者がSQLデータベースを使用する場合、サービスが実際にどこにデプロイされているかを知る必要はありません。既存のサービスを参照し、BicepまたはTerraformの定義で宣言的にアプリケーションにバインドすることができます。これは、開発者がサードパーティ製モジュールの詳細を知らなくても、ライブラリをコードにインポートするのと似ています。

Radius レシピ (画像: Microsoft)

開発者はレシピコンセプトを活用することで、アプリケーションに変更を加えることなく、依存関係を簡単に切り替えたり削除したりできます。例えば、開発環境やテスト環境ではコンテナ化されたデータベースを使用し、本番環境ではスケーラビリティが高くSLAベースのDB-as-a-Serviceに切り替えるといったことが可能です。

最初から包括的かつ拡張性に優れています。

MicrosoftによるRadiusへの投資により、リリース当初から包括的なサポートが提供されます。UCPは、Kubernetes、Azure、AWSクラウドサービス上で実行されるコンテナ化されたアプリケーションをサポートします。開発者は、AzureまたはAWSの幅広いクラウドサービスを直接利用できます。GCPやAlibaba Cloudなどの他のクラウドプラットフォームへの追加も時間の問題です。

Radiusは、マルチクラウド開発を促進するMicrosoftのオープンソースプロジェクトであるDaprとシームレスに統合されます。開発者はDaprを自社のアプリケーションに統合でき、運用担当者はRadiusテンプレート内でDaprの機能を定義できます。

運用担当者はワークスペースの概念を活用し、ローカル設定ファイルを使用して複数のRadiusプラットフォームと環境を管理できます。これはRadiusの優れた機能の一つです。開発者はワークスペースを簡単に定義・切り替え、複数の環境にアプリケーションを展開・管理できます。この機能とレシピを組み合わせることで、Radiusは開発者と運用担当者の両方が利用できる強力なプラットフォームとなっています。

要点

Kubernetesの複雑さの増大と、クラウドネイティブアプリケーションとクラウドサービス間のギャップの拡大により、新しいプラットフォームの継続的な開発が求められています。MicrosoftのRadiusは、これら2つの課題に対処するための試みです。

RadiusはKubernetesのインフラストラクチャを抽象化し、開発者がアプリケーション開発に集中できるようにします。Radiusのおかげで、Kubernetesクラスターでアプリケーションを実行することと、パブリッククラウド環境でマネージドクラウドサービスを実行することの境界線が曖昧になります。開発者は、異なるAPI、SDK、リソース管理ツールを扱うことなく、コンテナ化されたアプリケーションの機能とクラウドベースのマネージドサービスを組み合わせることができます。

Radiusは、堅牢なKubernetesとマネージドクラウドサービスを最大限に活用し、最新のアプリケーションをデプロイできる強力なプラットフォームとなる可能性を秘めています。RadiusがCloud Native Computing Foundation（CNCF）に提出され、承認されれば、CNCFエコシステム内で広く採用されるオープンソースプロジェクトとなることは間違いありません。