As a Xoogler I'd say that Kubernetes is harder to use than Google's internal equivalents. It may not be harder to run, but that doesn't matter inside of Google unless you're on the teams responsible for the base layers.

My point is, Kubernetes isn't really "made for Google level complexity" - Google only uses it for a handful of cloud products, internal research stuff and not much else.

Why did Google then release the complex Kubernetes to the world than their simpler internal tools?

To loosen up AWS-entrenched customers and their much more varied use-cases, probably.

I've long wondered if K8s is really a dastardly scheme to hold back the industry …

It's basically impossible to release this kind of internal tooling due to the way Google works. You'd have to rewrite it, or open-source essentially the entire foundation, and Google probably doesn't want to do either.

It's a ninja smoke bomb to distract the tech world into thinking we are cool like Google.

Where do I go for my 3-5 node cluster which I want to schedule containers to, run dynamic workloads etc?

How do I build a container based DAG in a small cluster today without k8s? Solutions that are not k8s tend to be single programming language/sdk based or not easier to set up.

I get the feeling the alternatives are dying off unnaturally fast.

Docker Swarm?

Ideally it would be a hub and spoke model. I don't know how much swarm hammers etcd but k8s in my cluster produces >1kIOps on my SSDs doing nothing at all. Just health checks and cascading effects

What exactly are you making that requires the use of multiple languages?

It would seem that the requirement for multiple languages often has nothing to do with making something or the customer requirements. It's often a developer requirement. Developers want to work in their favorite language. In the 90s you just wrote in whatever the company or ecosystem had mandated. Now that developers are in high demand they can specify what they want to use.

It started with books like "Beyond java" (and java was beyond C++) and disparaging articles by the likes of Paul Graham. They made some good points but if you have ever worked on a single system with multiple languages and are honest about it you would have to say that it wastes an enormous amount of time and generates unnecessary complexity. When a developer has to make a microservice just to write part of the system in another language you have wonder if they have the ability to evaluate technical trade-offs. Just pick one language and get on with it.

Kinda what I expect as well. I could understand it if a company was bringing in whole teams to scale up development of a large project quickly. Even then support would could be a nightmare. Doing it just because sounds painful.

My problem needing multiple machines is less weird than needing more than python for my dag?

No, I honestly just don't know what you're talking about lol. What exactly are you building?

I'm building several things, some of them need puppeteer with plugins so have to use a lot of node.js there. Which I have no interest in otherwise. Some of it is built in higher performance languages. Some of it is off the shelf solutions

And most of all by having every node in the dag a container I don't have versioning issues.

Yes everything can be wrapped in python, doesn't make it a good idea however.

I don't think that is true. Kubernetes brings a lot of advantages to people who have to manage infrastructure (like me). It gives me a single interface that I can apply across multiple teams. They all only need to provide me with a docker image and that's mostly it.

Also what is the alternative? Self-written unmaintainable bash-scripts? That's what they had before. Every team had their own way of deployment, creating packages,.... It was quite the nightmare.

To be fair, we use EKS, so a lot of the annoying work is done by AWS.

The first thing with bash scripts is you need to use a type system. Enforce json as your configuration language. Then have error handling as part of a default shell function library that emits json. All you are doing then is passing bad returns to a function that can emit json and reviewing json configurations for shell script variable definitions. Don't do in shell scripts what you can do in terraform. Don't use ansible/salt/puppet for what can be done in shell scripts. Shell scripts and makefiles go to CI/CD agencies (Jenkins). Ansible, terraform, etc...go to services that specialize in these.

>Also what is the alternative?

Docker compose.

Or if we're getting wild pick a technology, use it across the company, and rely on language tools to establish the APIs between modules. Then deploy the application however the language provides.

>Docker compose. Swarm is a closer alternative, although it's future is unclear.

Another alternative is Nomad.