I like Docker, I like microservices, but I feel like I'm just not excited about Kubernetes itself. There seems to be a "bullshit complexity" that people add to it that I really don't think is going to stick. But, I really do like the "GitOps" experience. A merge to a master branch is a deploy. Should I just get over this perception and learn Kubernetes, or could I find joy and professional usefulness out of another tool?

Don't get why you got downvoted.

Kubernetes is the right tool for some type of issues. If you want to host low complexity infrastructure like a simple website but still want to use containers go with nomad / docker swarm.

Its over used right now. Probably why the downvotes were given.

You can get the same GitOps approach with something like Dokku, which is just one container I believe. It acts like a self hosted Heroku.

Do NOT use Kubernetes unless you really, really need a lot of flexibility in rapidly scaling up, and occasionally scaling down your services.

If you do need that capability, Kubernetes is invaluable.

If you don't, plain old Docker and Ansible is a much better combination. Kubernetes adds a lot of complexity that doesn't pay for itself if you don't really need that much flexibility.

Do you really mean plain old Docker or do you mean Docker Swarm as well?

I think Docker Swarm is necessary in the absence of Kubernetes to ensure that the correct number of replicas are running on your cluster. It would help with automatically spinning up new replicas when a few nodes go down, changing the number of replicas on the fly, etc.

"It would help with automatically spinning up new replicas when a few nodes go down, changing the number of replicas on the fly, etc."

I'm saying for small deployments even this isn't really needed. If one container dies, have monitoring to alert you and then spin up a new one manually when you get around to it. Obviously, your system needs to have enough redundancy with each kind of container that you can still handle the load after losing one.

It's only if you are changing the number of containers a lot that something like Kubernetes is needed. And I think at that point go straight to Kubernetes, I don't know if there is a scenario where adopting Swarm but not full blown Kubernetes is the right answer, because then you likely have to migrate twice. Once to Swarm, and then to Kubernetes.

Kubernetes has some complexity but with some time investment it becomes clear.

You should learn this. Almost every company moving to the cloud with containers is leveraging it. I'd start with something simple like a GKE cluster on Google Cloud. Deploy a website using nginx and go from there!

Even after kubernetes is gone, the mindset and principles will still be valuable to you. Understanding its not-off-the-shelf architecture can also help you in your career.

None of this will be as valuable as porting an actual production application over and running into all the quirks though.

Don't worry, it will pass, just like 2 years ago all the rage was blockchain.

For developers I would phrase this as - learn about deploying workloads on k8s, using tools such as Kustomize, Tilt/Skaffold, Knative, service mesh, Ingresses and cert-manager. It is not simple for developers to use Kubernetes effectively in production without learning a few tools and concepts. There is a lot of demand for training of developers to use k8s and plenty of opportunities out there for those with the know how.

The other useful skill is using k8s as a platform to build platforms, even for internal workloads there can be a lot of value developing custom resources, controllers and webhooks

Once you have the right tools and tactics using k8s is a breeze and very productive

If everybody knows kubernetes what is the point to learn it? You can't stand out with this skill if you wouldn't do it professionally. Just to get familiar is enough.

I would go with bash, sed, awk.

But not everyone knows Kubernetes.

"You can't stand out with this skill if you wouldn't do it professionally."

But there are an increasing number of opportunities to do it professionally?

And every developer should have bash, sed, awk in their toolbox, anyways, So yes, at least get familiar with those tools and learn to recognize when they are a good fit for a problem you're trying to solve.

But after that it can still be good to learn Kubernetes, too, if you want to work at companies that have large scale back end systems.

Most likely in such companies you would have a separate devops team, separate sre team and so on. How can you use the skill if it's completely separate set of responsibilities managed by other teams?

The only way to give impact in this area is to pivot from writing code to managing infrastructure (i.e. writing code in yaml, pun intended). So, back to the question, what is the point to learn kubernetes above basic acquaintance?

You can use this time to pursue other endeavours like prepare talk to the conference, learn the tools better which you use every day, automate some of your daily workflow (i.e. explore your code editor, write extension to your code editor to automate some actions and so on). This activities will yield better results in my opinion and you'll use this knowledge everyday instead of deep diving into kubernetes without actual opportunity to keep your skill up to date on long distance without going full into devops and becoming less competitive in your main trade.

Knowing how to use a car instead of a horse is useful regardless of whether other people are using cars or horses.

It is just a much more powerful tool, despite the complexity arguments you see people throw around online.