Comment by _gabe_ | Hacker News Reader

Comment by _gabe_ | Hacker News Reader

> With that in mind, I want to talk about the sources of complexity in Kubernetes.

I don't care about the complexities in Kubernetes, I care about the complexities it (cl)aims to be solving. I reread the article a second time to see if I missed something, but the whole article just seems to be talking about the complexities within kubernetes and justifying those.

I still don't understand why every application must be able to scale to infinity and maintain 99.999% reliability. Not everyone is Google and I feel like we'd be a lot better if if the not-Google companies just recognized that instead of layering on accidental complexity in the form of infinite scaling for your service that gets all of 5,000 requests a month.

It's funny, this article mentions Fred Brook's "No Silver Bullet" and then proceeds to tout a solution developed for Google scale problems as the silver bullet to whatever it is Kubernetes is actually solving. Like what does it even mean to be using kubernetes if you only ever have 1 or 2 instances (pods?) running and deploy infrequently (which I suspect is the norm rather than the exception)?

I have been using Kubernetes for my side projects and personal home services for almost 5 years now. I only ever have 1 pod per service and I deploy pretty infrequently.

For me its because how much easier Kubernetes makes my life. I'm using digital ocean's managed kubernetes offering. This means I don't have to worry about the cluster. The OS and updates and all that are managed for me. Same thing with cluster scaling. I just keep adding or removing services and they make sure the cluster is right sized. Basically I just dont ever have to worry about infra.

The next nice thing is the community support. Do I want a load balancer/reverse proxy with auto certificate renewal? It's a simple install command away from running. How about a HA database? MFA? Block storage? It's like magic.

The third thing is that most services are going to have a pretty similar deployment/testing strategy. So when I want to stand up a new one. I can copy 2 or 3 files from another repo, do a find and replace on the App name and port number and deploy a new service with just one command. Again, its like magic.

While I dont use this feature, I like the fact that I know I can move my setup to anywhere I want. Move my cluster into my house? on another cloud provider? This would be really easy to lift and shift.

> The OS and updates and all that are managed for me.

I can see this being a nice feature! I feel like the updates have never been a big issue for me in the past though unless it breaks some sort of dependency. In a typical Linux server `sudo apt-get update` has never been a big pain point for me :)

> I can copy 2 or 3 files from another repo, do a find and replace on the App name and port number and deploy a new service with just one command. Again, its like magic.

I just looked it up because I was curious, and it looks like setting up an Apache server on Linux is pretty much this same process, as in copy a couple files and tweak a couple settings. Also, I think my biggest question is if you're only using this for home services why can't they all live on one server and deal with it in a traditional style? Why does each service need its own environment as opposed to one environment with multiple services?

I feel like Kubernetes is hoisting all the traditional problems of deployment and infrastructure up to another level. Which is basically the definition of accidental complexity, adding additional complexity where none was warranted.

Once again, I can see how this is very useful if you're Google and need to ensure that if a service goes down it can spin itself back up on an arbitrary machine, but 99% of homebrewed services probably don't need this capability.

Then again, maybe I just enjoy the infra side of things and hacking together a build system and this is just my bias speaking :)

The cloud provider might handle OS and platform upgrades for you, but don't forget about updating your images! :)

Then again, dealing with that is also something Kubernetes can help with.

> I still don't understand why every application must be able to scale to infinity and maintain 99.999% reliability. Not everyone is Google and I feel like we'd be a lot better if if the not-Google companies just recognized that instead of layering on accidental complexity in the form of infinite scaling for your service that gets all of 5,000 requests a month.

I agree with this, but some are using Kubernetes (or other orchestrators) just to be able to utilize containers effectively across multiple nodes.

Containers absolutely solve many problems with application packaging, configuration, deployment, healthchecks, resource limits, port allocations, storage persistence, running multiple versions of the same software concurrently and managing more of the deployments as code.

I've actually written about my personal experiences and why containers helped me before, "My journey from ad hoc chaos to order (a tale of legacy code, services and containers)": https://blog.kronis.dev/articles/my-journey-from-ad-hoc-chao...

It's just that Kubernetes is the most popular solution for orchestration, which is why many end up getting pigeonholed into using it, especially if they need a managed container platform in the cloud. Finding hosted/managed Nomad or Swarm is an exercise in futility for the most part.

Reply on news.ycombinator.com