> If your DevOps guy can deploy kubernetes into AWS managed with GitOps designed by GitHub copilot and ChatGPT in terraform in 40 minutes and manage without waking up in the middle of the night...that's fine.
So your bus factor is one ?
I think it's good to have articles like these. I see overzealous intelligent people over engineering things so often.
Just recently I saw a project where silly overgeneralization made development and testing way harder than it needed to be for MVP, it stretched development by a few months, by the time they launched they missed the investment window (last year with market contracting). If they launched garbage code that worked for MVP they would have had enough users and caught the next investment round to fund whatever refactoring they needed.
Bus factor doesn't really matter for a startup. Because literally everything early on is a bus of one, maybe two. Scaling is a good problem to have later on.
To your deeper point being that if you work at a startup to make your own life easier and those who eventually will work with you; write down what you're doing and get good at teaching/explaining process to people.
Fwiw, bus factor seems like an extremely good reason to use Kubernetes.
One can absolutely invite in a lot of complexity, but if you take a reasonably well integrated starting point/KISS (and you absolutely can with Kube), there shouldnt be a ton of additional complexity.
And given how self-describing via manifests-for-everything kubernetes is, someone spinning up who already is sort of familiar with Kubernetes ought be able to get a good picture of what pieces are in play & the shape of how things are setup extremely quickly. Unlike choice-making in most devops, there's still huge commonalities & massive shared base. If you & another startup make totally different choices about how you will Kube, the superstructure will still be the same. Porting people in is way easier.
So your bus factor is one ?
I think it's good to have articles like these. I see overzealous intelligent people over engineering things so often.
Just recently I saw a project where silly overgeneralization made development and testing way harder than it needed to be for MVP, it stretched development by a few months, by the time they launched they missed the investment window (last year with market contracting). If they launched garbage code that worked for MVP they would have had enough users and caught the next investment round to fund whatever refactoring they needed.