Comment by rahen | Hacker News Reader

Comment by rahen | Hacker News Reader

Kubernetes can really help bringing more scalability.

All you need is to rewrite your application (think microservices), reduce cold latency (get rid of anything VM based such as Java, or rewrite in Spring or Quarkus), use asynchronous RPC, and decouple compute and storage.

Then you need an elastic platform, for instance Kubernetes, with all the glue around such as Istio, and Prometheus, and Fluentd, and Grafana, Jaeger, Harbor, Jenkins, maybe Vault and Spinnaker.

Then you can finally have your production finely elastic, which 90% of companies do not need. Microservices are less performant, costlier, and harder to develop than n-tiers applications and monoliths, and way harder to debug. They're just better at handling surges and fast scaling.

If what you want is:

- automated, predictable deployments

- stateless, declarative workloads

- something easy to scale

Then Docker Compose and Terraform is all you need.

If you also need orchestration and containers are your goal, then first try Docker Swarm. If you need to orchestrate various loads and containers are a mean and not a goal, then try Nomad.

Finally, if you will need most resources Kubernetes has to offer (kubectl api-resources), then yes, opt for it. Few companies actually have a need for the whole package, yet they have to support its full operational cost.

Most companies just pile up layers, then add yet a few more (Java VMs on top of containers on top of an orchestrator on top of x86 VMs on top of(...)), and barely notice the miserable efficiency of the whole stack. Well it's using Kubernetes, it's now "modernized".

It honestly sounds like you've confused Kubernetes with some other platform.

Running a big Java monolith with 128GiB RAM footprint in Kubernetes works well. It's at its best when deployments are infrequent and traffic patterns are stable (or at least predictable).

If someone wants stateless microservices with immediate scale-up/scale-down, then that's more like a FaaS ("functions as a service") and they'll be better off with OpenFaaS instead of Kubernetes.

The true happy path: you have a big monolith hungry for resources, several instances of the monolith, and you want to be able to relatively quickly spin up new instances (modulo provisioning new nodes) without having to jump through 100 hoops.

For all people talk about autoscaling and whatnot, just hitting some buttons/sending a couple commands manually and getting some temporary scaling for reason X (or a temporary container for reason Y) without messing with a bunch of admin consoles is very nice.

You can do this type of analysis for most software, since building on existing solutions allows us to write powerful tools with less code. Listing out the existing solutions that allow developers to write less code doesn't necessarily mean the new solution is bad.

Every time I read a post like this about Kubernetes, I scratch my head. It takes me maybe half a day to deploy a CI/CD pipeline pushing into a new Kubernetes cluster with persistent DB's, configuration management, auto-renewing SSL certs and autoscaling API/web servers per environment. I'm by no means an expert, but I've been running 10+ sites this way for various clients over the past five years, with almost zero headache and downtime.

When I compare this solution to the mishmash of previous technologies I used prior to Kubernetes, it clearly comes out on top (and I use/d Terraform religiously). Setting up automatic server provisioning, rolling updates, rollbacks, auto-scaling, continuous deployment, SSL, load balancing, configuration management, etc... requires an incredible amount of work. Kubernetes either provides most of these out of the box, or makes them trivial to implement.

The only way I understand this argument is if you're building an extremely simple application. The nice thing about simple applications is that you can build them using any technology you want, because they're simple. Despite this, I often Kubernetes anyways, because it's _so simple_ to take a Helm chart and update the image name.

What is this? An argument for actual decisions based on merit? That's not the cargo cult i signed up for!

> reduce cold latency

You don't even really need to do this, as you can tell k8s how to check if the pod is healthy, what a reasonable timeframe for becoming healthy is, etc. I've got some services which can take up to 10 seconds before they're actually ready to serve workloads and k8s can scale those services up and down without too much issue. Its definitely nice to reduce cold latency, but I wouldn't say you need to do it.

There's no problem with running a java monolith in k8s. Elasticity isn't the only benefit to using k8s. And you should probably be running Jenkins and Prometheus even if your whole infra was launched with `docker run`.

> If what you want is... automated, predictable deployments... then Docker Compose and Terraform is all you need.

Can you elaborate on the deployment story here a bit?

Reply on news.ycombinator.com