You may regret that in a few years
Disagree. It will solve a problem, but not for everyone. If you are „small“ and not like Google, Uber or Whatever, Kubernetes brings more work to you as you might ever gain advantage.
It is a great tool, but it is not a one-size-fits-all.
If you are working with containers on production sooner or later you will find yourself wanting features that Kubernetes offers out of the box.And what’s even better than being available for everyone and not just Uber or Google, so why not
It’s not obvious to me and my clients how we can benefit from these features.
Our cloud providers already deal with orchestration, scaling and management. Docker and docker compose already deal with the basic containerisation needs of our internal build servers.
Instead of learning the guts of kubernetes, it’s cheaper and faster to outsource that to cloud providers.
UI frameworks/libraries are a different question, because the user interfaces we build are, by nature, highly specific and customised to our users. So it’s not so easy to outsource that work, and it’s worthwhile for developers to pick up that work.
But you may be in a different business setting and tech setup, which requires you to use Kubernetes and do all that management and scaling yourself.
Actually Cloud providers promote the use of managed Kubernetes for example,
Amazon's EKS, or Microsoft AKS or Digital Ocean. Nowadays you can have a turnkey Kubernetes cluster in a few minutes that it's also tailored for Enterprises.
There is clearly a great need for managing containers in the cloud as there are important considerations such as scalability and security that need to be handled efficiently. I think it's currently the best tool for that job and unfortunate not to invest on it.
EKS costs about $144 / mo currently, just for the part AWS manages. To startups that are trying to become the next big thing, that's a single droplet falling in the ocean of burning cash. But not every place operates that way. And bringing in Kubernetes requires a learning effort for all the extra bells and whistles (and all the new ways they can fail). For smaller shops like ours, it can make more sense to start on the zero-cost ECS or even Elastic BeanStalk until and unless we need more than it provides.
Unless you're trying to be some kind of AWS/Azure/Google cloud competitor, why would you devote precious time and energy to things like container orchestration, which they can already do for you? Why wouldn't you simply outsource anything at that layer (and maybe one or two layers above it)? For all you care, as long as your code runs cheaply, reliably and at scale, why does it matter which pieces of infrastructure run which parts of your code?
You should be focussing on the core of whatever it is that you actually do as a company. I would have thought comparative advantage is such an obvious and basic principle of business that anyone doing a startup would recognise it almost instinctually.
Am I missing context here? (Apologies if so.)
Yeah, you are spot on with using the services so that you can focus on the business aspects. That just makes sense.
Correct me if I'm wrong, but I think there is an underlying assumption that microservices are in use. Kubernetes solves a lot of orchestration problems for you in that case. But when you're not a large org with multiple dev teams per product, you don't have to do microservices. Obligatory reference to Conway's Law. And when you're not doing that, you don't have a lot of the problems Kubernetes tackles.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.