AmbassadorのKubernetesネイティブAPIゲートウェイのプロバイダであるDatawireは、内部開発ループを加速するように設計された新しいバージョンのAmbassador Edge Stackをリリースした。新しいService Preview機能は、レイヤ7 (L7) コントロールを使用して、複数の開発者がローカルでコーディングし、変更がライブクラスタの一部であるかのようにリモートでプレビューできるようにする。
Service Previewは、開発者がローカルコンピュータ上でアプリケーションをクラスタ内にあるかのようにデバッグできるようにすることで、デプロイメントと分離の問題に対処する。Ambassador Edge StackのL7ルーティングを使用して、ユーザがテストトラフィックリクエストをエッジ経由で開発クラスタに送信し、それらのリクエストをローカル開発マシンとの間でルーティングできるようにする。これにより、開発者はテストしているマイクロサービスのローカルバージョンを共有クラスタ内にあるかのように扱い、隣接するマイクロサービスとデータストアへの相互接続をテストできる。さらに、チームの開発者は、他の人の作業に影響を与えることなく、作業中のマイクロサービスの変更をテストするために、個別に識別可能なテストトラフィックを送信できる。
マイクロサービスをローカルでテストすることにより、開発者はソリューションのコーディングと反復を行うことができ、サイクルの度の、時間のかかるビルド、プッシュ、リモートKubernetesクラスタへのデプロイを回避できる。ライブトラフィックリクエストのテストバージョンをテスト対象のマイクロサービスのローカルコピーにルーティングし、マイクロサービスをライブクラスタの一部として扱うことで、開発者はマイクロサービスとそのすべての接続をより効率的にテストできる。
Ambassador Edge StackのService Preview機能は、Datawireによって作成されたオープンソースプロジェクトであり、現在はCloud Native Computing Foundation (CNCF) サンドボックスプロジェクトであるTelepresenceの一部を活用している。
InfoQは、DatawireのCEOであるRichard Li氏に、新しいリリースに関するいくつかの質問をした:
InfoQ: Ambassador Edge Stackは、アプリケーションをマイクロサービスに再設計するチームをどのようにサポートできるのでしょうか ?
Richard Li氏: モノリシックアプリケーションからマイクロサービスへの移行は、システム全体がより多くのコンポーネントで構成されるようになったことを意味します。多くの場合、各サービスは他の多くのサービスに依存しています。つまり、より多くの依存関係があります。各サービスの変更をテストするプロセスと、それが依存関係に与える影響は、サービスをプロダクション環境にデプロイする前には非常に困難です。
したがって、マイクロサービスの開発では、テスト用に一元化されたステージング環境が導入されることがよくあります。これには多くの利点もありますが、内部の開発ループが長くなり、分離された確認と変更のテストができなくなります。これを克服するために、ほとんどの組織は、クラスタをクラウドに複製するか、ローカルで冗長バージョンを作成して、開発者がマイクロサービスを個別にテストできるようにします。組織がクラウドで複製を作成すると、コストが指数関数的に増加するリスクがあります。
Ambassador Edge Stackは、これらの環境を複製するために必要なオーバーヘッドとメンテナンスを排除することにより、コストを削減することを目的としています。
InfoQ: Ambassador Edge Stackを使用している開発者とブランチ機能を使用している開発者とを比較するとどうでしょうか ?
Li氏: Ambassador Edge StackおよびService Preview機能の使用は、チームが機能の構築、コードのマージ、およびリリースに好みのアプローチを使用できるという点で、開発ブランチ戦略にやや不可知論的です。そうは言っても、Service Preview機能は、トランクベースの開発などの最新のブランチのベストプラクティスの採用を支援します。開発者は同じブランチで作業できますが、プロダクション環境のような環境内で変更を個別にプレビューできます。
InfoQ: コンテナが内部ループとマイクロサービスの外部ループの開発者エクスペリエンスを最適化するのはなぜでしょうか ?
Li氏: 外側の開発ループには、エンドユーザに影響を与えるプロダクション環境に対応した変更のコーディングとリリースが含まれます。モノリシックアプリケーションからマイクロサービスに移行することで、小規模なチームがサービス/製品を所有し、より頻繁にイテレーションを個別にリリースできるようになります。マイクロサービスチームは、数週間または数か月にわたる組織化されたリリースサイクルに悩まされるのではなく、ユーザーのニーズに迅速に対応するために必要な敏捷性とスピードを備えています。
内部開発ループは、1人の開発者がチームとコードを共有する前に実行するコードの記述、構築、およびデバッグの反復プロセスです。これらの内部開発ループは、外部開発ループよりもはるかに頻繁に完了します。
クラウドシステムでのデプロイの事実上の単位となったコンテナは、コンテナイメージの構築、アップロード、および各開発ループ内でのデプロイ税を導入します。これは、内部開発ループにとってより大きな問題です。これは、たとえば、外部ループのビルドとリリースで1日1回実行するのと比較して、すべての開発者が1日に複数回これらを実行するためです。
InfoQ: ローカルマシンでよりもクラウドで開発する方がよい場合はありますか ?
Li氏: それは本当に組織の好みとコストの両方の問題です。大規模なアプリケーションは大きすぎて誰かのデスクトップに複製できないため、ほとんどの場合、クラウドに配置されます。それがまさに私たちが解決を支援している問題です。開発が必要で、アプリをデスクトップに収めることができないため、「64コア」デスクトップを求める人々と話をします。運用チームは、クラウドの請求額を増やすだけの独自のクラウドコピーを全員に提供することを余儀なくされています。クラウドプロバイダにとっては良いことですが、開発チームにとっては悪いことです。
さらに、個々のクラウド環境を維持するためのオーバーヘッドは、特にアプリケーションとチームの複雑さとサイズが大きくなるにつれて、多くのチームに頭痛の種をもたらします。Service Previewを使用すると、チームは共有開発クラスタをクラウドに保持できますが、開発用にマイクロサービスのローカルコピーを作成してから、識別可能なテストトラフィックをローカルコピーにルーティングします。これにより、開発者は、ピアの作業に影響を与えることなく、共有開発クラスタ内にあるかのようにローカルで変更をテストできます。
さらに、Service Previewを使用すると、開発者は好みのツールとワークフローを使用できます。多くのデバッガとIDEはクラウド用に作成されていますが、開発マシンにローカルにインストールできる実証済みのツールと比べて遜色はありません。
Ambassador Edge Stack Service Previewのデモの表示には、こちらにアクセスしてください。