Platform Engineeringは開発者の自由を奪うことにつながらないのか、HashiCorpダドガー氏の答えは：HashiCorp共同創業者兼CTOに聞く、Platform Engineeringのエッセンス（2）
「Platform Engineering」におけるプラットフォームとは具体的には何か。開発・運用の現場をどう変えるか。連載の第2回ではこれについて、アプリケーション開発／運用の現場をよく知るHashiCorpの共同創業者兼CTO、アーモン・ダドガー（Armon Dadgar）氏に詳しく聞いた。
[三木泉，＠IT]
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
「Platform Engineering」とは何か。＠ITでは、アプリケーション開発／運用の現場をよく知り、この動きを提唱する一人でもあるHashiCorpの共同創業者兼CTO、アーモン・ダドガー（Armon Dadgar）氏に、そのコンセプトから具体的な姿までを聞き、2回構成の連載にまとめた。前編では、概念あるいは考え方としてのPlatform Engineeringについて聞いた。今回は後編として、Platform Engineeringにおける「プラットフォーム」とは具体的には何か、開発・運用の現場をどう変えるかに関する部分をお届けする。（聞き手：三木泉）
――Platform Engineeringにおける「プラットフォーム」とは、具体的には何でしょう？
まず、プリプロダクション段階では「GitHub」などのバージョン管理システム、「Jenkins」のようなCIツール、「Artifactory」などのアーティファクト管理ツール、「Snyk」のような静的コード分析ツールなどが一般に使われています。一方、プロダクション段階では 「Terraform」などによるインフラのプロビジョニング、セキュリティではシークレット管理、ネットワーキングの自動化ではAPIゲートウェイなど、ランタイムではKubernetesや「Normad」などの基盤があります。
加えて、可観測性を確保しなければなりません。これには「Datadog」「Splunk」「Sumo Logic」などが使われています。
プロダクションアプリケーションを提供するにはこうした要素全てが必要です。どれか1つが欠けても開発・運用のプロセスは破綻（はたん）します。
プラットフォームチームは、開発者に対してこれをメニューとして提供します。組織によって、今挙げた要素の全てを提供することもあるし、一部を提供することもあるでしょう。
しかし何も提供しなければ、開発者は全てを自分たちでやらなくてはならないことになり、カオスが生まれます。ある開発チームはGitHubを使い、他のチームは「GitLab」を使うかもしれません。あるチームはJenkinsを使い、他は「Bamboo」を使うかもしれません。
ここで言うプラットフォームは、大きく2つのレイヤーに分けられます。
1つはプリプロダクションからプロビジョニングまでの一貫した「インフラストラクチャ・アズ・コード（IaC）」パイプラインです。図ではL字型に示した部分です。多くのプラットフォームチームやCCoE（Cloud Center of Excellence）はこのレイヤーから始め、プリプロダクションからデプロイまでを標準化します。
それでも、開発チームが残りの要素に対応しなければならないという課題が残ります。例えばランタイムです。100のアプリケーションチームがあったとしたら、そのうち99のチームはKubernetesクラスタをどう管理し、アップグレードすればいいかが分からないということがあり得ます。
そこで、プラットフォームチームは次に、図に描いた全要素を共通サービスとして提供します。 つまり、IaCから完全な「プラットフォーム・アズ・ア・サービス（PaaS）」へと移行します。
これによって、開発チームはアプリケーションロジックに集中できるようになります。パイプラインはプラットフォームチーム側で完全に面倒を見られるからです。
私が見たハイパフォーマンスな組織は、どこも全ての要素をプラットフォームチームが提供しています。ただし、どういった機能を標準化してプラットフォームチームが提供するか、 どういった機能をアプリケーションチームに任せるかは、個々の組織が判断すればいいと思います。
――では、既存の運用チームや SRE （Site Reliability Engineer）の仕事はどう変わるのでしょうか。
現在のSREは、アプリケーションごとのカスタマイズによって成り立っています。Platform Engineeringでは、これが大きくシフトします。
自家用車の販売を例にすると、顧客であるアプリケーションチームは自分の車を細かくカスタマイズしてもらうことはできなくなります。車種と色を選ぶ以外の選択肢は与えられません。こうすることで、標準化が進みます。
SREの仕事は、ツール利用の観点では変わりません。変わるのはマインドセットです。標準化された幾つかのテンプレートを提供し、顧客であるアプリケーションチームにはその中から選択してもらいます。「これからは、個々の要件に合わせて完全なカスタマイズを行うようなことはしませんよ」ということです。
「開発者は自由を欲するが、必要とはしていない」
――しかし、多くの開発者は自由を求めます。選択肢が狭められることに抵抗感を抱くのでは？
IT組織は樹木に例えられます。共通の標準化されたテクノロジーが幹を形成します。 そこから枝が分かれ、このレベルで多少の逸脱を許します。アプリケーションは枝の先にある、一つ一つの葉のようなものだと表現できます。 IT組織の方針によって、この木のあり方が変わってきます。
私が「Day 1」と呼ぶ 組織では幹が最小限しかなく、 葉に至るまでには多くの柔軟性があります。 標準の利用を強制されることはなく、アプリケーションチームは何でもできるという状態です。
たしかに、開発者の多くはこの世界にいたいと考えています。 例えばAmazon Web Services（AWS）が新しいサービスを出したら、すぐに使うかもしれません。
こうしたDay 1の組織のあり方は、例えば100日目くらいまではうまく行っていると思えるでしょう。ですが、100のアプリケーションチームが100の違ったやり方をしていると、保守やセキュリティの問題が生まれます。実際に問題が起こって修復しようとすると、100回直さなければならなくなります。
開発者は自分のいる組織がDay 1にとどまってほしいと考えます。 しかしそれでは大きな複雑性につながり、保守、セキュリティ、コンプライアンス、コストなど、あらゆる点で混乱を生み出すことになります。
「どんなやり方でアプリケーションを構築してもいい」と開発チームに白紙委任する組織を、私は幾つも見てきました。2年後に再び訪れてみると、こうした組織は完全な混乱状態に陥っています。それもそのはずです。開発者が入社し、いろいろなアプリケーションを構築して、 2年ぐらいたったら退社してしまいます。後に残されるのは、それぞれが全く異なる構成のアプリケーション群です。
組織は、こういった状態のアプリケーションを今後20年にわたって管理していかなければならないかもしれません。それが現実です。
一方、Day 1で痛い目に遭い、何が重要かを理解した組織はDay 2に移行します。Day 2では標準化を徹底し、柔軟性は非常に低い状態になります。100のアプリケーションが同じやり方で動きます。デプロイも構成も全く同じです。ハイパフォーマンスな組織は、どこもDay 2のやり方を採用しています。一方で、Day 1の教訓を生かせず、Day 2に移行できない組織が多いのも事実です。
HashiCorpの例で説明しましょう。うちでは社内の開発言語をほぼGoに統一しています。最近、あるチームが私のところにやってきて、興奮した様子でRustを使いたいと言い出しました。
「社内で何人がRustを知っているんだ」「2人です」「Goが分かっているのは？」「1000人です」
そこで私は、「Rustが分かる2人が退社したら、Rustで書かれたアプリケーションを管理できる人は誰もいなくなる。HashiCorp社内では、全てのツールがGoのアプリケーションをデプロイするために設計されている。全く違ったアプリケーションが1つでも紛れ込んだら、チームにとって大きな作業負担になる。答えはノーだ。Goで開発してくれ」と言いました。
この場合、私はある意味で開発者の自由を奪ったことになります。でも、開発者は自由を欲するものの、必要とはしていないのです。
開発者に「ノー」と言うには、リーダーシップが求められます。「イエス」というのは簡単です。でも、結果は混乱しかありません。
Copyright © ITmedia, Inc. All Rights Reserved.
HashiCorp共同創業者兼CTOに聞く、Platform Engneeringのエッセンス 連載一覧
次回の掲載をメールで受け取る
2
Platform Engineeringは開発者の自由を奪うことにつながらないのか、HashiCorpダドガー氏の答えは
1
「Platform Engineering」という言葉はなぜ生まれた？ HashiCorpのダドガー氏に聞いた