まだ Kubernetes を使うな
(matt-rickard.com)アーリーステージのスタートアップは、Kubernetes を早まって導入しないほうがいい。
多くの場合、まだ時期尚早だ。
小規模なチーム（1〜10人）なら、Serverless container service を使うのがよい。
（AWS ECS - Fargate、GCP の Google Cloud Run）
アーリーステージのスタートアップは、Kubernetes を早まって導入しないほうがいい。
多くの場合、まだ時期尚早だ。
小規模なチーム（1〜10人）なら、Serverless container service を使うのがよい。
（AWS ECS - Fargate、GCP の Google Cloud Run）
13件のコメント
k8sは、もはや好き嫌いの問題ではなく、生き残りの問題ではないでしょうか?
AWSはともかく、k8sは知っておかなければならない状況になったと思います。
私はこの意見に反対です。
k8sの唯一の欠点は、学習コストその一点だけだと思います。
チームメンバーが5人程度の規模であっても、最初は難しいでしょうが、k8sに対する理解が一定水準を超えると、決して以前には戻れません。そこから得られる生産性向上は比べものになりません。
ci/cd、GitOps、カナリアリリースなどはk8sなしでもできますが、k8sの上で一緒に運用するほうが理解しやすく、管理も簡単です。
実際に移行期を経験した私としては、まだ時期尚早だと言うのは、
AWS Cloudになじみがないという理由で導入をためらっていたオンプレミス時代を思い出させます。
「ビジネスに集中しろ」というような原論的な次元の話ではなく、何か特殊な技術にロックインされる決定には賛成しにくいですね。
beanstalk/app engine/heroku のような PaaS を積極的に活用しろという文章だったなら強く同意したでしょうが、小さなチームで ECS/cloud run/docker swarm を選んで得られる利点は、最近ではほとんどないに等しいです。4〜5年前ならまだしも。
コスト面で見ると、serverless が圧倒的に有利です
私も同感です。ほとんどの場合、docker-swarm あるいは docker-compose で十分すぎるほどです
Hacker Newsのコメントでもかなり多く付いていた意見ですが..... [1]
この記事は「Kubernetesは難しい」という前提が置かれているので、少し混乱します。
最近はKubernetesエコシステムがかなり発展していて、オンプレでKubernetesを直接インストールしない限り、そこまで難しいものではありません。
また、Kubernetes運用は複雑さをある程度自分で決められますが、基本的な構成を作るだけなら大変ではありません。後からあれこれアドオンを付ければ、当然大変になります。
私のように、新人のときからEKSを起点にデプロイ環境を経験した人も多くなっています。
要点をはっきり言うと、基本的なk8s Deployment、Ingress（もちろんDBは別のマネージドサービス）を構成するのが、あの記事で言っているAWS ECS Fargateを直接構成するより特別に難しいのかは理解できません。
どちらも同じようにVPC、クラスター、CDN、ロードバランサーの構成が必要なわけですし……コメントではむしろECSのほうが不便だったという話も多いです。
[1] https://news.ycombinator.com/item?id=31795160
同感です。基本的なセットアップはそれほど難しくありませんし、保守運用の難易度もそこまで高くないと思います。クラウドで複雑なセットアップを1つ行うのと、それを Kubernetes の yml セットアップに置き換えるのとで、何がそこまで良いのかは正直あまり言えませんね。
私の会社では開発者が100人を超え、必要性を感じてECS -> EKSへの移行を進めていますが、少し後悔することもあります。
「Kubernetesの運用は複雑さをある程度自分で決められる」とおっしゃいますが、よく分からない立場からすると、Kubernetesエコシステムで話題に上るものは全部必要なのだろうと考えて、つい全部入れてしまう側面があります。
ロードバランサーの構成が必要なのは同じだとおっしゃっていましたが、ALBだけ分かっていればいいのと、ALB + Ingressを理解しなければならないのとでは差があると思います。
小規模でMSAが必要ないのと同じように、Kubernetesは思ったよりも学ぶべきことが多いので、「アプリケーションに集中すべき規模」ではオーバースペックなのはその通りだと思います。
ただ、誰かがKubernetes環境をうまく構築してくれているのであれば、その上でアプリケーションをデプロイすること自体はクラウドに依存しない表現で定義されるぶん、ロックイン効果は小さそうだとも感じました.
お話を伺うと、確かにそういう側面はありそうですね。私が Kubernetes を使いながら学んだことを、少し当たり前のこととして考えすぎていた気がします。
それに、最近は Kubernetes で出てくるアドオンが多すぎて、取捨選択の判断が難しいという点も認めます。
私には ECS -> EKS のような移行経験がないので……もしロックイン効果のようなこと以外で、移行後に少し良くなった点があるのか気になります。
ちなみに、私の経験はEKS基準で話しています。オンプレミスで直接k8sをインストールして、etcdやControl Planeを自前で運用するのとはかなり違いますね（笑）。
k8sから始めた人の立場としては、この記事を読みながら逆に、わざわざ時間をかけてECSを勉強する必要があるのかな……という気持ちになりました。
とにかく、必ずしもああいうふうに公式に決め打ちする必要はなく、まずはチームが使いやすいと感じるやり方で使うのが正しいのではないかと思います。
k8s導入の立場に同意します。
とても共感します。
10人規模だけでなく、そこそこの規模の会社でk8sを導入することにも私は否定的です。
クラウドベンダーロックインがクリティカルなレベルになるか、オンプレミスなどのインフラが併用されるようなレベルになってこそ意味があるのではないかと思います。
エンタープライズ級の企業の技術スタックを惰性的に追いかけてしまう面が少なからずあると思っていましたが、
ちょうどそれを文章にまとめたものが Hacker News に上がっていたので共有します