分散型マルチクラウドの世界で成功する方法

※この投稿は米国時間 2020 年 11 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

特定のニーズを解決するために複数のものを使用するのはなぜでしょうか。まず、そうせざるを得ない場合があります。雇用主提供の退職金口座が自分の個人口座とは異なる金融機関にあれば、金融資産を 1 か所に置くことはできません。あるいは、意図的に分散させることもあります。すべての服を 1 つのショップで購入することもできますが、個人的な好みや都合、あるいは単に状況によって、あるショップで靴を購入し（靴の種類によってショップを変えることも）、別のショップでシャツを、また別のショップでアウターを購入することもあります。

IT 部門も同じ状況ではないでしょうか。組織の動きや、テクノロジーへの過去の投資、現在の顧客の需要に基づいて、どのような問題についても解決策は複数あるでしょう。パブリック クラウドでも同じことが起きています。統計によると、ほとんどのユーザーが複数のプロバイダを使用しています。

しかし、どのパブリック クラウドも同じではありません。確かに、共通点もあります。どのパブリック クラウド プロバイダも、仮想コンピューティング、ストレージ、ネットワーキングに加えて、メッセージングなどのミドルウェア サービスを提供しています。しかし、どのクラウドも他にはない新しいサービスを提供しています。そして、それぞれが異なる地理的リージョンで運営されています。一部のクラウドは他とは異なるセキュリティ、データ主権、ハイブリッド機能を提供しています。また、ユーザー エクスペリエンス（開発ツール、ポータルサイト、自動化機能）は一様ではなく、社内のどのチームに対して訴求力があるかわかりません。

複数のクラウドを使用することは一般的になりつつあるかもしれませんが、簡単にできることではありません。異なるツールやスキル、パラダイムを吸収する必要があるからです。でも心配はいりません。クラウド間の微妙な違いについてデベロッパーに学習させたり、顧客価値の提供から注意をそらしたりする必要はないのです。ただし、マルチクラウドを最大限に活用できるよう、技術チームの用意は必要です。では、技術チームのリーダーとして何をすべきでしょうか。アドバイスとして、マルチクラウドへの取り組み方について考慮すべき点を以下にまとめました。なお、普遍的な解決策は存在しないことを覚えておいてください。存在するのは、現在の組織に対する正しい解決策のみです。

ポータブルなスキルを重視する

ソフトウェアはクラウドの選択によって定義されるものではありません。パブリック クラウド プロバイダで働きながらこんなことを言うのは礼を欠いているかもしれませんが、本当のことです。優れたソフトウェアの構築に必要なものの大半は、特定のデプロイ ターゲットを超えた領域にあります。

本当に重要になるのは、どのようなソフトウェア開発スキルでしょうか。

• 1 つ以上のプログラミング言語を習得する。効率的で変更とテストが可能なコードの書き方を理解する。

• 開発環境（IDE、テスト用サンドボックス、ソース管理フローなど）を最適化する。

• Angular や Flutter などのフロントエンド フレームワークについて学習する。

• リレーショナル データベースとスキーマレス データベースのユースケースについて理解する。

• アプリケーションのパッケージングの正しい方法（コンテナの使い方など）を把握する。

• マイクロサービス、マイクロ フロントエンド、イベント ストリーム処理、JAMstack、API、サービス メッシュに関する最新のアーキテクチャの知識に投資する。

• チームに迅速なフィードバックを提供する、完全な継続的インテグレーション パイプラインの構築方法を理解する。

これは、最終的に使用するクラウドとはほとんど関係ない、広く適用できる有益な知識です。

誤解のないように言うと、新しいクラウド サービスに関連するスキルを伸ばすことは大事です。[誤解を招く表現] パブリック クラウドに同じものはなく、認証やプロビジョニング、そうした有益なサービスの利用においては基本的な違いがあります。あるクラウドで問題なく動作するよう設計されたアプリを別のクラウドで実行するのは簡単ではありません。自分が必要とするソフトウェアと顧客が重要であるということを忘れないでください。パブリック クラウドはサービスを提供するために存在しているのであって、その逆ではないのです。

環境をまたいで Thinnest Viable Platform を使用する

組織が重々しく、わかりにくいプラットフォームを導入し、デベロッパーにそれを使うよう求めることがよくあります。これはアンチパターンであり、企業はより良い方法に気付きつつあります。

Team Topologies の著者は、開発を加速する Thinnest Viable Platform（TVP）という考え方を推奨しています。多くの組織では、Kubernetes が TVP の出発点になります。これは、コンテナ化されたワークロードに対して、リッチで一貫した API を提供します。TVP の上に Knative レイヤを置いて、Kubernetes の根底にある複雑さを隠す、アプリ中心のインターフェースをデベロッパーに提供することは理にかなっているでしょう。こうすると、デベロッパーがインフラストラクチャ中心のコード（クライアント側の負荷分散、サービス ディスカバリ、再試行、サーキット ブレークなど）を書かなくても済むように、埋め込みサービス メッシュをクラスタに導入することができます（これらを組み合わせて、他にも若干併用すると、Anthos が手に入ります）。

しかし、ここで本当に重要なのは、業界標準のオープンソースによるベース プラットフォームが手に入ることです。単なるオープンソースではなく、業界標準のオープンソースです。巨大なエコシステムがサポートするプロジェクトであり、Kubernetes、Istio、Envoy、Tekton、Cloud Native Buildpack との統合も検討できます。これにより、デプロイ ターゲット全体で同一のプラットフォームを実行し、最善のインフラストラクチャやサービスと統合することができます。デベロッパーは基本的な実装作業に負担を感じることなく、各環境で利用可能な付加価値機能に集中できます。

アプリのニーズに基づいて最適なクラウド（とサービス）を選択する

ここまでの内容をまとめましょう。広く適用できるスキルに注目しました。また、どの環境でも一貫したソフトウェアの実行に役立つ、基盤となるプラットフォームについて確認しました。次に、実際にソフトウェアを実行する場所を選択する必要があります。

デベロッパーは、まったくクラウドに依存せずにあらゆる場所で動作するソフトウェアを作成することができます。簡単なことではありませんが、これに成功すれば、デベロッパーが前もって困難な選択をする必要もありません。移行先の環境について事前に知識が必要となるのはどのような場合でしょうか。以下に例を示します。

• アプリが AI、データ処理、IoT、業種固有の API（メディアや医療など）といった独自の機能に依存している場合。

• 特定の地域でアプリをホストする必要があるため、特定のクラウド、データセンター、パートナーの施設を選択する場合。

• アプリに特定のデータソース（SaaS システム、パートナー データセンター、モバイル ユーザーなど）が必要なため、最も近いホストを使用する場合。

検証済みのディシジョン ツリーを用意して、代替が利くサービスではなく新しいサービスの利用を検討する場合や、ワークロードに最適なクラウドを選択する場合の意思決定に役立ててください。利用するクラウドやサービスの選択には、エキスパートのサポートが必要になることもあります。サポートが必要な場合は、Google のエキスパートまでお問い合わせください。あるいは、実績に基づくガイダンスを提供する優秀なパートナーのグローバル ネットワークをご利用いただくことも可能です。必要に応じてお選びください。

-アウトバウンド プロダクト管理担当ディレクター Richard Seroter