マルチクラウド クラスターを使用してアプリの展開にかかる時間を毎月数百時間節約する方法

最新のapplicationsの概要

マイクロサービスは、今日のソフトウェア展開の世界では標準となっています。 アプリケーションがさまざまなサービスに分解されるにつれて、組織が展開する必要があるアプリケーションの数が増加します。 多くの場合、サービスの数は数百倍、数千倍に増加します。 現在 100 個のアプリケーションがある場合、これは多くの場合、数千個のマイクロサービスになります。

最終的な目標は、applicationsと新機能をより早くエンドユーザーと顧客に提供することです。

課題は、展開速度を犠牲にすることなく、何千ものサービスを継続的に展開する方法です。

現在、その答えの一部は、デプロイメントに Kubernetes を使用することです。 Kubernetes は、マイクロサービス ベースのapplicationsを大規模にデプロイするための事実上の標準です。 これにより、繰り返し性、拡張性、そして重要な展開速度が得られ、エンドユーザーに機能をより早く提供できるようになります。

マイクロサービスの導入を拡大する組織は、複数の Kubernetes クラスターを実行することを検討します。 多くの場合、これらの複数のクラスターは異なる場所で実行されます。 これらの場所は、支店や小売店、さまざまなクラウド プロバイダー、または多くの場合、その両方の組み合わせである可能性があります。

大きくなればなるほど難しくなる

複数の Kubernetes クラスターにわたってapplicationのデプロイメントを高速かつ大規模に管理するのは困難です。 各applicationは複数のサービスで構成されるようになりました。 対処すべきapplications、サービス、サイト、Kubernetes クラスターが複数あります。

アーキテクチャ的には、これは単一のクラウド プロバイダまたは単一のapplicationに合わせてカスタマイズされた複雑なビルドおよびデプロイメント パイプラインにつながります。 また、特注品は、脆く、壊れやすく、通常はapplicationの展開の途中で壊れやすいことも意味します。

大規模な導入

分散した場所に複数のapplicationsとサービスを展開する機能が実現しました。 つまり、複数の Kubernetes クラスターにわたってapplicationsを高速にデプロイする機能が現在存在するということです。 この機能により、展開時間が短縮され、複雑さが軽減されます。 最終的には、新機能をより早く利用できるようになることで、エンドユーザーの満足度が高まります。

アプリケーション開発者として、複数の Kubernetes クラスターを単一のエンティティとして扱うことができます。 つまり、単一の「仮想」Kubernetes クラスターにapplicationをデプロイすると、実際には複数のクラスターにapplicationがデプロイされることになります。 これらの複数のクラスターは、互いに隣接している場合もあれば、世界の反対側にある場合もあります。

複数の場所にapplicationsを展開する機能は、展開の管理と速度に大きな影響を与えます。 もはや、特注で脆弱なデプロイメント パイプラインを扱ったり、各クラウド プロバイダの微妙な違いを心配したりする必要がなくなりました。

標準的な展開アプローチを使用することで、applicationsを展開し、エンド ユーザーや顧客に機能をより早く提供できるようになりました。

ネイティブのすべて

最も優れている点は、開発者としてネイティブ ツールを使用してapplicationをKubernetes にデプロイできることです。 使い慣れたデプロイメント方法とツールを使用して、複数のクラスターにデプロイできます。 開発者側では特別なものは必要ありません。

より深い技術的観点から見ると、これにより、Kubernetes ネイティブ構造の両方のラベルを使用してデプロイし、デプロイ先の 1 つ以上のサイトを選択できるようになります。 また、 kubectlコマンドなどの Kubernetes ネイティブ ツールや、標準化された Kubernetes デプロイメント ファイルまたはマニフェストを使用することもできます。 これは Kubernetes と対話するための標準的な方法です。 これにより、使い慣れたツールを使用できるため、デプロイが容易になり、複数のクラスターと場所に高速にデプロイできるという利点も加わります。

しかし、重要なのは、Kubernetes ラベルを使用して、単一のクラスターにデプロイするか、複数のクラスターにデプロイするかを簡単に選択できることです。 ラベルは、applicationに「タグ」を付けることができる Kubernetes ネイティブ構造です。 applicationに場所（1 つまたは複数の Kubernetes クラスター）を「タグ付け」またはラベル付けできます。

結論

F5 の Volterra プラットフォームを使用して、複数の場所に大規模にapplicationsを展開すると、開発者が日々感じる苦労が軽減されます。 Kubernetes ネイティブ構造を使用してapplicationsをデプロイする機能により、時間が節約され、applicationをより早く必要とする人々の手に届けることができます。

集中化された監視とポリシー、および容易な分散展開により、開発者のオーバーヘッドが削減されます。

継続的な導入のスピードと速度は、applicationsと機能をより早く顧客に届けることを意味します。