前の会社は僕が入ったときにkubernetesでクラスタ組んでて問題頻発かつ構築した人が退職済みで誰も管理できる人がいない状態だった。だから僕もそのときk8sさっぱりだったので提案してECSへ移行したんだけど今kubernetes触っていてわかる、これをスタートアップでいい感じに維持・管理するのは無理だ。
4:00 PM · Jan 18, 2020Hootsuite Inc.
Conversation
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="73" height="73"><rect fill-opacity="0"/></svg>)
Replying to
k8sそのものに関連するサービスや本当によっぽどの理由がない限りエンジニア5人以下の組織では 99.99% ROIに見合わない。少なくとも2020/01の時点ではk8sの運用には深い知識と何より常なるキャッチアップが必要で、サービスファーストの小さな組織では時間の無駄。
1
53
165
もし仮に担当者がk8sのエキスパートならその人による構築・運用はもしかしたらECSやBeanstalk, EC2直デプロイとコストが変わらないかもしれないけど周りの人間や引き継ぎ先、同じインフラ担当が業務範囲内でk8sへキャッチアップするのは2020/01時点ではきつい。
1
20
63
現状中規模以上の組織ならk8sはありだと思うけど、どちらかというと将来来るであろうk8sデファクトスタンダード時代に対する先行投資や企業PRの面でのみリターンがあると思う。
1
21
70
あと現実的なコスト感覚を持たない人間がポータビリティの点(特定のクラウドサービスに依存しない)のみ注視してk8sを推し進めるケースがあるけど、前述の通り現状はk8sにかかる学習・構築・運用コストが大きすぎてポータビリティという利点とまったく釣り合ってない。
1
24
82
あとk8s使ったとしても結局alb-ingress-controller, external-secretsなどでクラウドサービスが提供するマネージドサービスは使う。だからポータビリティもひどく限定的になる。
1
12
43
以上を踏まえて、今aws系でk8sの導入を検討している企業にはECSを激しく推奨したい。codepipelineやcodedeploy、parameter storeなどとの連携が公式に提供されているので自分でargo cdやCICD、external-secretsなどをセットアップ・設定する手間がなしか少なくて済む。
1
18
76
一方すでに導入しているケースは微妙で、最初に書いたとおりエンジニアが5人以下のようなごく少数の組織ではさっくりECSにしたほうがよい。一方で10~20人以上で一応k8sが賄えそうな場合は、徐々にメリットが増えてくることを見越して先行投資しておくのはありではある。
1
10
38
ただし、ひどくコストがかかることは先述の通り。
またk8sではないもっと別のソリューションがk8sを早期に置き換える場合は投資がパーになるのでその点でもリスクは大きい。
rkt, swarmなどまだコンテナ関連技術と標準が未発達な今、この可能性は決して低くない。
1
12
39
みんな忘れているかもしれないが、Docker社公式のコンテナクラスタは数年前までSwarmだったのだ。
たしかにGoogleの後ろ盾は強力だがそれでも完璧ではない。
1
13
48
Replying to
おっしゃるとおりで、すごく共感して拝読しました。
ウチのエンジニア組織でk8sの採用を見送ったのはまさにこれで、身の丈にあった技術選定というのも大事と思ってます。もちろん、スキルや組織の弱さが一員ではあるので、悔しさも含んでます。
9
New to Twitter?
Sign up now to get your own personalized timeline!
Sign up