Why Kubernetes Will Disappear | Hacker News Reader

Why Kubernetes Will Disappear

medium.com

37 pointsAndrewBissell28 comments

IMO the Kubernetes is a "open source bait and switch" business model.

1. Let the potential customers run it for free 2. Wait for them to break their teeth on it. 3. Offer them GKE. 4. Profit!!!

To me the whole situation about k8s is that people are running at it like lemming over the cliff: "Yes, k8s is complex and complicated (even as SaaS!!!), but it's still great!" As an "operator" this just goes beyond my comprehension of what good software looks like.

GKE is free.

GKE is the managed version of Kubernetes that Google Cloud offers. Definitely not free.

Free as in you pay for your worker nodes, but nothing additional for operating the platform itself. You do lose control over your control plane nodes and etcd however.

Yes, it’s free as long as you pay for it.

No, there is no extra charge for gke. You pay for the nodes you use and you pay the same price whether you are using just cloud compute or whether you run those same cloud compute nodes in a gke.

Mhmm, it's free if you pay for the all other stuff.

Like everywhere else ...

> Free as in you pay for your worker nodes, but nothing additional for operating the platform itself.

If you go to the GCP pricing calculator[0] and add one n1-standard-1 VM to GCE, it costs $24.27/month.

Add one n1-standard-1 VM to a GKE cluster and you pay $38.27/month. There is a literal line item saying "Kubernetes Engine Cost: USD 14.00".

It's not free. It's just billed under the worker.

[0] https://cloud.google.com/products/calculator/

If you choose the standard engine edition, there is no additional Kubernetes Engine Cost.

I don't follow you.

Edit: ah, I see my mistake. There's a dropdown that lists "Advanced", which apparently accounts for the $14 difference.

Kubernetes' success is partly due to its novelty, as it happened with Mongo and Node when they were novelties.

The next-gen cloud systems (storyscript, darklang and so on) are embedding kubernetes, or the features provided by it, in their platform, so the end users do need to interact with Kubernetes.

Looks like we're starting to see k8s slide down the slope in the typical "hype cycle", in the way we've seen Docker do so over the last 12-18 months.

It'll be interesting to see how well it weathers this part of the cycle and comes out the other side.

For me k8s is useful but overhyped, leading to many companies making use of it when it really wasn't needed (I've seen k8s cluster deployed for single applications !?!)

It has a lot of complexity (far more than just Docker/Docker-compose style stacks) which are only likely to make sense at scale.

The thing that makes me thing k8s will suffer, is that complexity is increasing not reducing. Things like adding service mesh layer, use of operators, CRD etc are all additional complication on top of what is a moderately complex product.

Reminds me when Hadoop was going through it's hype cycle and I saw people installing it for a 10gb data set.

But... but... 10GB is REALLY BIG DATA :) You can't open that in Excel!

Kubernetes is complicated. But not so bad with hosted options like gke.

I put my relatively small app on it. We have just 3 nodes. One for database and the other 2 for application and supporting pieces like redis, and elk stack for reporting.

Docker compose doesn't work for more than a single node. I initially started using k8s for seemless deployment of updates in our CI.

Anything with docker alone was beginning to feel like a kludge.

Kubernetes gives you a standard way of describing and running distributed systems. It makes it easy to share distributed systems with others via a package manager. It makes it easier for companies to offer tools/services that simplify the management of distributed systems. It allows you to quickly get up and running with a complex distributed system (e.g. Kafka, Spark, Distributed Deep Learning) without relying on a cloud provider service (not always an advantage, but for some companies being cloud-mobile has substantial benefits).

That is valuable so I can't see k8s disappearing unless there's a better distributed OS - I don't see one right now.

The title is maybe a bit clickbaity -- the author does not mean that it will "disappear" in the literal sense, but rather that in the vast majority of cases it will become a managed service which end users don't really touch, much in the same manner as today's data center hardware. All the things you describe as its advantages could possibly be realized with a simpler interface provided and managed by a third party.

Maybe, but that doesn't make much sense to me. Kubernetes is an OS like Linux. You work with and think about Linux whether you're running your own hardware or relying on a cloud service like EC2 or even Lambda. The same will happen to k8s to the point where you will eventually not have to do any of the management - but you will still need to understand how the system works, the primitives it offers and how to use it.

And while k8s is painfully complicated, there were simpler alternatives and they lost. Maybe that's just a matter of execution or Google hype, but more likely it's because you need a complicated standard when you want to be able to describe most distributed systems.

I definitely see your side of the argument and I am sympathetic to the idea that (most of) the complexity of Kubernetes is inherent to the problem domain. That said, lots of devs do get by with knowledge of only the barest essentials of Linux.

A company I know writes software for small banks and telcos (which means no cloud) and has decided to switch to a Microservices architecture and all deployment concerns of clients were waved away with "Kubernetes takes care of it". Now the poor IT teams will have to learn K8s really quickly, and my guess is that they will fall back to Docker on VMs with compose as it simpler - Kubernetes is much more complicated to deploy than the 20 containers that the clients actually care about. But the IT teams of these clients they are not going to be happy over the whole ordeal.

When stories like this seems to me like a huge indication that K8s is at the top of the hype cycle. It only is suitable for maybe 5% of on-premise IT organizations, and the cloud is not for everyone (fortunately and unfortunately).

From my personal experience of working on it, it is becoming simpler every month. So from a infrastructure standpoint, it is going to be much simpler than vSphere or Openstack. This is a no-brainer.

Now, do everyone need to run their applications on Kubernetes? Say, I invested millions $$ into Kubernetes, but the very business applications that my team built were proven to be not worthy. Then I see competition happily using same old VM, lambda, api gateways, but much improved operations (logging, ML, automation). I think what is going to decide the widespread success will be the adoption of applications that run on Kubernetes. It will be 3-5 years until we know. Right now it is a honeymoon phase and let us enjoy and ride the wave.

As a DevOps engineer really trying to decide if learning kubernetes in a necessary investment I'm interested.

I think containerization is here to stay for sure. It just seems kubernetes offers a ton of complexity and commands that may be hard to debug to do things that I wish could be solved with an easier abstraction (maybe just AWS autoscaling groups?)

The key quote for me is this, (but I'm interested in opinions of others):

In the end, precisely because it’s generic and because running a deployment platform is an undifferentiated hard problem, it can and will be commoditised. Fargate and Cloud Run (Knative) are already barrelling down this road.

To me, kubernetes is basically containerization for infrastructure. So it makes sense that if containers are here to stay it is here to stay (or at least something like it).

Sure you can use AWS autoscaling, but that will only work on AWS.

I can tear down my kubernetes cluster on gke and without too much trouble, launch the whole thing on someone else's hosted kubernetes or run my own on bare metal.

What do you currently use for deployment when dealing with multiple nodes?

Saying that k8s is complicated is like saying your OS is complicated and will disappear. It's ridiculous.

Kubernetes is a network OS for scale. It's far easier to run an application on a cluster of hundreds to thousands of computers using kubernetes as the orchestrator than to use something home grown.

If you don't have a scaling/cluster problem, then k8s is not for you. If you on the other hand have application spanning a hundred computers, it's probably worth it for you.

What's the deal.with Docker swarm? It's MADE by Docker and seems like it could handle a bunch of biz use cases?

There’s always been two major threads to container software offerings - the container tech itself and container orchestration tools like Swarm/kubernetes/rancher etc.

Docker have had great success with the former but have never really delivered an industry leading product in the later. Swarm has had a number of drawbacks over the years vs some competitor offerings.

Reply on news.ycombinator.com