インナーループとアウターループによる生産性と安全性の両立
機能要件と非機能要件の分離の背景として重要なポイントが、開発者と運用者の立場の違いです。開発者は自由な環境で素早くコードを形にすることを目指しています。一方運用者は、セキュリティやガバナンスの実現を通して、秩序あるインフラ運用を目指しています。この立場の違いが、時には開発者と運用者の対立を招き、俊敏性・生産性・スケーラビリティを実現する妨げになってきました。そこでTanzu Application Platformが取ったアプローチは、両者を2つの空間に分離することで、開発者が求める自由と、運用者が求める秩序を両立することです。それがインナーループとアウターループという考え方です。
インナーループは開発者のための空間です。個人の開発環境と、開発用のKubernetesクラスタが直結し、アプリケーション開発のサイクルを高速に回していくことができます。そこでは、セキュリティ、ガバナンス、大量の宣言ファイル作成といった非機能要件に手を煩わせることはありません。アウターループは本番環境に向かうループであり、運用者が管理する空間です。セキュリティとガバナンスを集中管理しながら、インナーループから上がってきたアプリケーションを迅速かつ安全に本番環境にデプロイします。
上記の図は、インナーループとアウターループをより具体的にした構成図です。開発、ビルド、ステージング、本番環境それぞれにKubernetesクラスタが展開されています。それぞれのクラスタには、役割に応じて必要なTanzu Application Platformのコンポーネントがインストールされています。
開発チームは、インナーループ側のKubernetesクラスタで、アプリケーション開発を進めます。そこではIDEから直接開発クラスタにコンテナをデプロイし、コードの更新を即座に反映することができます。開発が進んだコードをコミットすると、今度はビルド用のクラスタが脆弱性スキャンを行い、問題がなければ決められたパイプラインに基づき、コンテナイメージやYAMLファイルを自動生成します。これがインナーループにおける典型的な開発の流れです。
運用チームが担うアウターループは、インナーループからはネットワーク的に分断され、開発チームが直接アクセスすることはできません。本番環境があるアウターループのクラスタと、インナーループをつなぐのは、Gitとコンテナレジストリだけです。インナーループからのコミットによりコンテナレジストリの更新を検知すると、ステージングクラスタのパイプラインが起動し、データベースなどのバックエンドサービスの設定と連動しながら、ステージング環境にデプロイします。そして運用チームが問題ないと判断すれば、アプリケーションを本番用ブランチにコミットします。すると、ステージング環境と同様の流れで、本番環境用のクラスタへのデプロイが自動的に行われます。
このようにインナーループからアウターループ、すなわち開発環境から本番環境への移行は、GitOpsの枠組みの下で極めてスムーズに行われます。このような高度なCI/CD（継続的インテグレーション・継続的デプロイ）を実現するためには、コンテナの仕組みが欠かせません。コンテナの可搬性の高さを生かし、仮に失敗してもすぐにフェイルバックしながら、効率的な開発を実現していくことが、Tanzu Application Platformの目指す世界です。
次の記事では、開発者（インナーループ）が抱える課題と、運用者（アウターループ）が抱える課題、それぞれにフォーカスを当てながら、Tanzu Application Platformの構成要素を深掘りします。
VMware Tanzu Application Platformについて、詳しくは、次のダウンロード資料をご覧ください
Tanzu Application Platform
– VMware Tanzu が魅せる新世界 –
本資料では、生産性と安全性を両立しながらモダンアプリケーション開発の促進を目指す、VMware Tanzu Application Platformについてご紹介します。