I think that the contradiction here comes from the fact that these tools that are suited for large scale operations, like Kubernetes, end up getting standartized and adopted even by smaller corporations, which have neither the specialists, nor the resources to utilize them properly. Be it because of FOMO (fear of missing out), CV driven development or something else entirely, but i've seen this a number of times in the industry and it's always gone poorly. Instead of relatively quick deployments with Docker Swarm, Hashicorp Nomad, Docker Compose or anything of the sort, it suddenly becomes an uphill battle of trying to administer the darn cluster, as opposed to just being able to develop software, even with turnkey solutions like Rancher ( https://rancher.com/ which is great, by the way), especially if the company has only recently adopted Kubernetes.
In contrast, i think that Docker Swarm does a much better job at smaller scales, because:
- it uses way less resources than Kubernetes (which matters on smaller nodes)
- it is included in the install of Docker and therefore is easy to launch
- it supports the Compose format, which is often used for development with Docker Compose
- it is relatively simple, yet handles most of the concerns of smaller scale projects (i.e. excluding things like autoscaling or CRDs)
- there are solutions to manage it with web interfaces as well, like Portainer, if necessary ( https://www.portainer.io/ )
Or, if you need Kubernetes in a non-managed format, i'd suggest that anyone take a look at projects like K3s ( https://k3s.io/ ), which attempt to cut out all of the unnecessary components and features of Kubernetes, that most people won't use.
In my opinion, going with Kubernetes as a whole or even full Kubernetes distros (or building your own clusters for prod) is akin to choosing Apache Kafka because you want to build an event driven system, and then needing to throw a team at the thing to actually keep it running smoothly, instead of just choosing something simpler, like RabbitMQ or ZeroMQ.
I'd argue that most companies out there don't even have "SRE jobs", but instead it's a duty that gets thrown upon regular devs who also need to deliver features. It's probably easy to overestimate how capable most companies out there are in regards to throwing resources at problems to make them disappear, mostly due to a lack of said resources.
Startups are insisting on K8s experience despite targeting a market that will never need more than a single server if they write the application properly.
I look at "if you've got 100K servers..." and ask "why does anyone needs 100K servers?", rather than "how would I manage that?".
Each layer adds complexity and reduces performance. Less layers are better. Write Unikernel applications
In contrast, i think that Docker Swarm does a much better job at smaller scales, because:
Or, if you need Kubernetes in a non-managed format, i'd suggest that anyone take a look at projects like K3s ( https://k3s.io/ ), which attempt to cut out all of the unnecessary components and features of Kubernetes, that most people won't use.In my opinion, going with Kubernetes as a whole or even full Kubernetes distros (or building your own clusters for prod) is akin to choosing Apache Kafka because you want to build an event driven system, and then needing to throw a team at the thing to actually keep it running smoothly, instead of just choosing something simpler, like RabbitMQ or ZeroMQ.
I'd argue that most companies out there don't even have "SRE jobs", but instead it's a duty that gets thrown upon regular devs who also need to deliver features. It's probably easy to overestimate how capable most companies out there are in regards to throwing resources at problems to make them disappear, mostly due to a lack of said resources.