コンテナを宇宙の中心として扱わないでください。 Docker 10 周年: 従業員 #1 からの感想

サム・アルバ著

ノアが編集

この記事の著者である Sam Alba は現在、Dagger の共同設立者兼エンジニアリング担当副社長であり、以前は Docker のエンジニアリング担当副社長でした。彼は2010年にDockerの最初の従業員として入社しました。彼はエンジニアリング チームを率いて、メンバーを 3 人から 100 人に拡大しました。その後、彼はさまざまな主要な Docker 製品のサポートを担当するコア製品およびエンジニアリング チームを率いました。

Dockerは最近10周年を迎えました。私は、Docker が過去も現在も成し遂げてきたすべてのことに非常に誇りを持っています。コンテナがコンピューティング消費の新しい単位になっていなければ、私たちの周りで目にする多くのもの、たとえばマイクロサービス ベースのアーキテクチャや Kubernetes などは存在しなかったでしょう。

また、人生のターニングポイントを振り返ると、その過程で得たものと失ったものがより明確にわかるようになると思います。私にとってはまさにその通りです。では、これ以上前置きせずに、私たちが何を正しく行い、どこで失敗したかを見てみましょう。

1. 3つのことを正しくやった

1. コンテナは世界を変える

2010 年に Solomon Hykes に入社し、DotCloud (後に Docker に改名) を構築したとき、当時存在していたツールだけを使用していたのでは、私たちのビジョンは決して達成できないことにすぐに気付きました。

DotCloud は、あらゆる言語をサポートする最初の Platform as a Service (PaaS) ですが、Heroku やその他のサービスでは、依然として単一の言語スタックの実行に制限されています。 dotCloud を構築する際にすぐに直面した制限の 1 つは、主要なインフラストラクチャ構築ブロックとして仮想マシン (VM) に代わるものがないことでした。仮想マシンはインフラストラクチャの世界ではベアメタル サーバーからの大きな進歩でしたが、クラウド ネイティブ時代に入ると必要な俊敏性を提供できませんでした。

数百もの開発者アプリケーションを 1 台のマシンにパッケージ化しながら、各顧客を独自の名前空間 (コンピューティング、ネットワーク、ストレージ) に分離できるほど軽量なものが必要でした。これがマイクロサービス パターンの始まりです。当時、インフラストラクチャの再現性に関しては VM が依然として最先端であり、コンテナーはまだ少数の技術者しか使用できないあまり知られていないテクノロジーでした (実行中のコンテナーに LXC をアタッチするにはカーネル パッチが必要だったことを覚えていますか?)。解決策は VM をゼロ炭水化物ダイエットにすることだと考えた人もいました (JeOS を覚えていますか?)。

課題はあるものの、すべてをコンテナを中心に構築することには価値があることは明らかです。結局、我々の考えが正しかったことが証明されました。数年後、私たちは DotCloud プラットフォームのコアコンポーネントであるコンテナ ランタイムを抽出しました。私たちはそれを書き直し、オープンソース化しました。これは Docker の最初のバージョンです。最初の目標は、Docker を DotCloud から抽出された多くのオープン コンポーネントの最初のものにすることです。コンテナ オーケストレーター、ネットワーク層がそれに続きます。しかし、Docker が初期の頃にすぐに注目を集めたことを考えると、タイムラインは大きく変わりました。

2. 開発者が最優先

スティーブ・バルマーは正しかった。 VMware は主に IT の問題解決に重点を置いていますが、世界を変えるには世界中のソフトウェア開発者に重点を置く必要があることに早くから気付いていました。ソフトウェアは、運用方法だけでなく構築方法も変更する必要があり、それはまず開発者のニーズから始めることを意味します。

何千人もの開発者を管理してきた者として、私はソフトウェア開発者が日々直面している課題をよく理解しています。それは、挑戦的な問題と美しいものを創り出す満足感に満ちた、世界で最も素晴らしい仕事の 1 つですが、退屈で、イライラさせられることがあり、時には怒りを覚えることもあります。インフラストラクチャとツールは飛躍的に進歩しましたが、基準も向上しました。

Docker の目標は、混乱やコストを削減し、開発者が効率的に共同作業できるようにすることです。最も初期の買収（および成功した製品統合）の 1 つは、「Fig」と呼ばれる製品でした。これは後に Docker Compose となり、もともと Ben Firshman（現在の Replicate の創設者）と Anand Prasad によって構築されました。

興味深いことに、Fig によって実装された YAML モデル (composition.yml) は、数年前に構築した最初の DotCloud サービス構成 (DotCloud.yml) から直接インスピレーションを得たものです。私たちは大きな進歩を遂げてきましたが、特にコンテナを唯一のユニットとして超えて、コンテナ パイプラインをオーケストレーションするなど、やるべきことはまだたくさんあります。これが、コンテナー内でパイプラインを実行できるプログラム可能な CI/CD エンジンである Dagger を 2018 年にリリースした理由の 1 つです。

3. 活気あるコミュニティに投資する

私たちはまず素晴らしいコミュニティを構築することに重点を置いています。私たちは最初から、自分たちだけでは達成したいことは達成できないと信じていました。多くの人々の支持を得る必要があり、それを達成するための鍵は多くのものの所有権を放棄することです。 DockerCon は、私たちの業界で最も優秀で聡明な人々が集まる場所となり、物事がどのように進化すべきかについて共通のビジョンを共有し、その構築に積極的に取り組む人々の集まりとなりました。

Docker の初期の頃、独自の開発者会議を主催することを考えたとき、最初はそれは実現不可能な夢のように思えました。大企業向けでも、PyCon のような確立された開発者コミュニティ向けでも。しかし、2014 年 6 月にサンフランシスコで最初の DockerCon を開催し、最も才能ある開発者たちを一堂に集めることができたとき、これが企業や業界全体に混乱をもたらす何かの始まりであることが明らかになりました。

その伝統は、私たちの業界で見られる数十（あるいは数百？）のオープンソース プロジェクトやコミュニティの中で、今日でも強く残っています。現在、Cloud Native Computing Foundation はこれらのプロジェクトの多くをホストしており、毎日新しいプロジェクトが登場しています。

2. 3つの間違い

1. 選択と利益

「コミュニティ第一」の裏返しは、持続可能なビジネスを構築するのに時間がかかりすぎたことです。私たちはすべてをオープンに行い、コミュニティのニーズに注意深く耳を傾け、全力を尽くして貢献します。この戦略の元々の基盤は、オープンソース プロジェクトと商用の独自ソリューションがうまく共存し、同じ顧客体験の一部となることができるというものでした。

私は今でもこのモデルを信じていますが、バランスを取るのは難しいです。

まず、オープンソースの貢献者やユーザーの中には、決して顧客にならない人もいることを受け入れる必要があります。彼らが強力なコミュニティ、強力なブランドの構築に携わり、それが商業チャンネルの成長に貢献していることを考えると、それは問題ありません。 2 番目に、製品アーキテクチャは、コアとなるオープンソース基盤の上にエンタープライズ グレードの機能を構築できるようにする必要があります。これには多くの場合、複雑なサポートとリリースのプロセスが伴います。堅実なビジネスを構築するための道のりにおいて、私たちはもっと戦略的であるべきでした。結局、私たちはそこにたどり着きましたが、時間がかかりすぎたため、しばしば恐怖を感じました。

2. チーム文化

私たちはチームの文化やコアバリューを早い段階で定義していませんでした。それは、コミュニティや、後から会社に加わった人々によって後で定義されます。その結果、当初は明らかではなかったものの、私たちのチーム文化は初期から劇的に変化しました。私たちの文化は、最終的にはコミュニティの人々のスタイルや価値観を反映するものであり、その逆ではありません。

私たちが間違っていた具体的な例の 1 つは、社内に 2 つの別々のチームがあったことです。1 つはオープンソースとコミュニティに重点を置き、もう 1 つはビジネスに重点を置きました。これは私の最大の後悔の一つです。

社内のツール、製品およびプロジェクト管理、そして最も重要なチーム文化自体に関して、分裂状態に陥りました。各人がこれらの競合する利益のバランスを取るのは難しいですが、役割を分離すると、内部の争い、意見の不一致、そして決して解決されない公開討論（そして誰もが自分の観点からは正しい）が生じます。

最も優秀で聡明な人々の多くはコミュニティ側で働きたいと考えており、私たちのコラボレーションの多くでは、相手側についての微妙な（またはそれほど微妙ではない）判断がしばしばあります。時々、私たちは「オープンソース信者」と「企業の金儲け屋」を対立させているように感じます。これは生産的ではありません。活気のあるコミュニティと持続可能なビジネスの両方を実現するには、私たちのモデルから自然に生じる固有の緊張に全員が取り組む統合されたチームが必要です。これにより、より良いチーム文化も生まれます。会社内のどこで働いているかに関係なく、1 つの目標だけに注意を払う必要があります。

3. コンテナは宇宙の中心です

少し立ち止まって考えてみると、私たちはコンテナに依存しすぎていることに気づきました。私たちは、コンテナがほとんどの問題に対する中核的な解決策であると考え始めています。このため、サプライチェーンの開発における他のニーズが無視されるようになりました。

Docker は、コンテナが業界に必要な一連の変化をもたらすことがわかったために誕生しましたが、物事が進展するにつれて、その後のニーズに注意が払われなくなりました。私たちは多くのニーズに対処しないままにしているため、他の人たちが介入してこれらの分野を構築する余地をたくさん生み出しています。

これは一方では大きなチャンスをもたらしますが、他方ではコミュニティの分裂も意味します。 Docker で解決できなかった課題の 1 つは、ソフトウェア サプライ チェーンの全体的な自動化でした。サプライチェーンの末端で多くの価値が生み出されましたが、開発者がコードを書き、共同作業を行う際のニーズに十分に対応できておらず、今日の CI/CD は混乱したままになっています。しかし、これは解決可能な問題です。その時代の多くの人々と同様、ソロモン・ハイクス、アンドレア・ルッツァルディ、そして私が Docker での時間を振り返ったとき、私たちの革命はまだ終わっていないことに気づき、次の 10 年間の使命を見つけました。

参考リンク: https://thenewstack.io/docker-at-10-3-things-we-got-right-3-things-we-got-wrong/