Kubernetesを早期に導入しない

会社が Kubernetes を導入する場合、メインラインから外れた部分にエネルギーを費やす可能性が高くなります。

最初は奇妙に聞こえるかもしれませんが、結局のところ、私たちは Kubernetes ディストリビューションの宣伝と販売、そして人々が Kubernetes をさらに活用できるようにするためのコンサルティング サービスに多くの時間を費やしてきました。しかし、それが現実なのです。おそらく、Kubernetes やその他の「クールな」ものを製品に使用するべきではありません。

スタートアップ企業や成長中の企業の大多数は、ソフトウェアを構築するときに Kubernetes やその他の時期尚早な最適化を避ける必要があります。会社で Kubernetes を使用している場合、メインラインから外れた部分にエネルギーを費やす可能性が高くなります。早すぎる最適化の罠に陥っている可能性があります。

この投稿は Kubernetes だけに関するものだとは思わないでください。いいえ。この投稿は、エンジニアがソフトウェアの構築中に行う可能性のある、時期尚早な最適化すべてを対象としています。

私が見た例をいくつか挙げます:

• 1 つのアプリケーション (Web アプリケーション) に Kubernetes を使用している企業。
• アプリケーションは複数の言語で書かれています。たとえば、バックエンドでは Golang、Ruby、PHP などの言語を使用し、フロントエンドの Web では React や Vue などのフレームワークを使用します。
• アプリケーションのホストにクラウド サービスは使用されません。たとえば、Heroku、Vercel、Netlify、Fly.io を使用できます。ほとんどの製品チームでは、運用チームまたはインフラストラクチャ チームを編成する必要がある場合、ソリューションは過剰に設計されます。

実際に遊び始める前に、趣味に最適な道具を選ぶのに多くの時間とお金を費やす人を想像してみてください。

もちろん、ここでの意見のいくつかはより主観的です。おそらく、あなたは新しい趣味を長い間続けるつもりで、適切な道具を選ぶのを手伝ってくれるその分野の専門家である友人がいるでしょう。認めざるを得ませんが、私自身は、違いに気づくことはおそらくないだろうにもかかわらず、なぜエリート ギアを選ぶのかを正当化するのは得意です。

1. 刃には最高の鋼を使用する

組織が Kubernetes が必要だと考えている場合、将来に向けて最適化を試みるのが早すぎる可能性があります。決して来ないかもしれない未来。何らかのテクノロジーを採用すると、組織に対して複数年にわたるコミットメントを行うことになり、製品の表面積が拡大し、開発者に精神的な負担がかかります。

最終的には、それを維持するための専任チームを構築する必要があります。これらすべてにより、コアミッションからリソースが奪われてしまいます。

エンジニアがこの罠に陥るのは簡単です。新しいクールなテクノロジーに気を取られてしまうのは簡単です。私たちは学び、成長したいと考えています。そのための最善の方法は、最新のテクノロジーを製品に取り入れることです。そして、私たちは自分の決定を正当化するために、さまざまな理由を考え出します。

私がどのようにしてこの罠に陥ったかについて、いくつかお話ししましょう。

私が初めて OCUS に入社したときの議論で、私たちが Kubernetes を使用していることを知ったのを覚えています。私はこう言いました。「それは素晴らしいですね。AWS から移行したいと思ったら、Kubernetes がその問題を解決する素晴らしい方法になるでしょう。」私がどれだけ狂っていたか分かりますか？

別の機会に、データ サイエンス チームから、データ パイプライン用のオーケストレーション ツールが必要だと言われたことがあります。私は、すでに PoC が行われている Perfect (SaaS 製品) よりも、Argo Workflow (Kubernetes 上で実行) を好みます。この決定にはさまざまな理由が考えられます。

残念ながら、それらはすべて時期尚早な最適化を前提としています。結局のところ、私たちのチームは、Argo Workflow のデプロイメントを自動化し、それを SSO と統合するなど、新しい Terraform と Helm Charts のセットを構築する必要がありました。私はこの決定を後悔しています。この決定により、エンドユーザーへの機能の提供が数週間、あるいは数か月遅れることになったと考えています。これは時期尚早の最適化です。

時期尚早な最適化を避けることができれば、競合他社よりも迅速に行動し、ユーザーを満足させ、持続可能で実行可能な製品を構築できる可能性が高まります。

では、どうすればこの考え方を打破できるのでしょうか?

2. ユーザーはこのリクエストを行いましたか?

事前に考えなくても、途中で発生する問題を解決します。私たちが行うことはすべて、実際にユーザーの問題を解決するものでなければなりません。自分の仕事を通じて、どのような人間の行動に影響を与えようとしているのか、自問してみてください。

ユーザーの行動に焦点を合わせ、実際の問題が発生したときにのみそれを解決できれば、その影響の大きさに驚くことでしょう。また、しばらくユーザーについて話していなかったために、ユーザーについて自分が立てた多くの憶測に驚くこともあるかもしれません。

このアプローチを厳格に遵守する企業は、より大きな影響を生み出し、顧客と株主にとってより大きな価値を生み出すと信じています。

機器を研究するのではなく、新しい趣味に全力を注げば、自分が何を望んでいるのかが自然とわかるはずです。私が始めた頃は、最も「グッチ」なギアは必要ありませんでしたし、たとえ最高のギアを持っていたとしても、使い方を知らなければ場違いに見えてしまうでしょう。私のエネルギーはすべて新しい趣味を学ぶことに費やされているので、初心者レベルの装備で他の人を圧倒する方が良いでしょう。そして、私が「グッチ」の服にアップグレードしたいと思ったとき、それは本当に特別なものになります。

3. 少ないリソースでより多くの成果を上げる

ありがたいことに、テクノロジーの世界は大規模な軌道修正を遂げつつあります。金利が上昇すると、安価な負債とリスク資本が枯渇し始めます。今日のスタートアップ企業は、もはや莫大な資金を調達することができず、自社の使命にもっと集中する必要があります。生き残るのは、基礎がしっかりしている企業です。

製品は、より速いペースでビジネス成果を提供できる小規模なチームによって構築される必要があります。

Kubernetes が完全に普及するまでは、スリムな組織に Kubernetes が入り込む余地はないと予想しています。それでも、Kubernetes は拡張機能として導入できると思います。ほとんどの組織は、クラウド ベンダーが提供するより高レベルのビルディング ブロックを通じてこれを導入することを検討できます。

忘れないでください、Facebook が WhatsApp を 190 億ドルで買収したとき、4 億 5000 万人のユーザーにサービスを提供していた開発者はわずか 35 人でした。

この記事からどんなアドバイスが得られるか読者に尋ねるとしたら、それは「組織の使命を達成するために必要なことに集中してください」というアドバイスになるでしょう。学習したい内容（Kubernetes や Golang など）に気を取られず、ホームラボのために取っておきましょう。