У вашій команді п’ятеро розробників. Ви крутите Kubernetes-кластер на трьох нодах. У вас три мікросервіси. На вас 200 активних користувачів на день. Якщо ці чотири речення описують вашу ситуацію — у вас Kubernetes-овер-інженерія, і вона коштує вам більше, ніж ви усвідомлюєте.
Я знаю це, бо побачила це у 12 з 18 українських стартапів, що мене запросили на консультацію за останні 18 місяців з питанням «чому ми так повільно поставляємо». У 7 з тих 12 проблема — Kubernetes.
Симптом 1: один DevOps на фул-тайм
У вас команда з 5-8 розробників і один з них займається тільки інфраструктурою. Якщо це ваш випадок — у вас не Kubernetes-проблема, у вас Kubernetes-наслідки. Один інженер у нашому ринку коштує $5-7K/міс. За рік це $60-84K, який ви платите за «оркестрацію контейнерів», що вашому продукту не потрібна.
Чесна правда: для команди з 5-8 розробників і трафіком до 5-10K активних користувачів на день — Heroku, Railway, Render або Vercel + AWS Lambda покривають усі ваші потреби. Інфраструктурою займається півгодини на тиждень будь-який backend-розробник.
Симптом 2: deploy займає більше 5 хвилин
Якщо ваш CI/CD pipeline збирає Docker-образи, push-ить у registry, оновлює Helm chart, чекає rolling update і smoke-tests — і це займає 10-15 хвилин на кожен deploy — у вас Kubernetes-проблема. Це не «нормально». На Heroku ваш deploy займає 90 секунд.
Команди, що мігрували з Kubernetes на Heroku/Railway, повідомляють про збільшення швидкості deploy на 4-8 разів. Це означає, що ваші розробники роблять не 3-4 deploy на день, а 15-20. Це різниця у швидкості поставки фіч.
Симптом 3: відсутній один експерт
Якщо у вашій команді тільки одна людина знає, як працює ваша Kubernetes-інфраструктура, і коли вона у відпустці — інші не можуть оновити image-tag — у вас bus-factor-проблема. Це окремий вид ризику, що дорого вартує, коли вибухне.
На стандартних PaaS-системах (Heroku, Railway) розгортання — це команда `git push heroku main`. Будь-який junior-developer може зробити це о другій ночі. Kubernetes — це інший рівень знань.
Коли Kubernetes виправданий
Сценарії, де варто. По-перше, якщо ваша команда — це 20+ розробників. Тоді складність Kubernetes виправдана можливостями стандартизації середовища. По-друге, якщо ваш продукт має 100K+ активних користувачів і вам потрібен горизонтальний масштаб. По-третє, якщо ви будуєте multi-tenant платформу, де ізоляція tenants на рівні pod-ів критична.
Для більшості українських SaaS у перші 24-36 місяців жоден з цих сценаріїв не актуальний. Kubernetes — це інструмент для масштабу. Якщо у вас немає масштабу, у вас немає проблеми, яку Kubernetes вирішує.
Це та сама закономірність, що з cloud-перевитратами — наслідування «правильних» технологій без розуміння власних потреб коштує грошей і часу. Часто простіша інфраструктура — це не примітивізм. Це здоровий глузд.
