Live data from Hacker News

Do you really need Kubernetes?

blog.ekern.me

41–50 of 61 posts

Re: Do you really need Kubernetes?

#41

There's some legit notions here, but overwhelmingly it uses insinuation & suggestion to sow Fear Uncertainty and Doubt. > Despite its portability, Kubernetes also introduces a form of lock-in – not to a specific vendor, but to a paradigm that may have implications on your architecture and organizational structure. It can lead to tunnel vision where all solutions are made to fit into Kubernetes instead of using the ri…

>>> This seems a bit absurd on a number of fronts. It doesn't shape architecture that much, in my view; it runs your stuff.

I mean, let's be candid.

There are plenty of times where "containers" are bags of shit software that were pushing into production and throwing hardware at them to keep things going. There are containers out there with out of date libraries that aren't getting updated cause the "work" and no one gives a shit.

If you can get away with that, what is the incentive to do highly integrated engineering that produces diagonal scalability? Why be WhatsApp when you can just throw money at bad software?

Re: Do you really need Kubernetes?

#43
post #4

Related: https://doineedkubernetes.com/

Does this site return something different if it detects a Google/Facebook/Amazon corporate IP visiting?

Why would it? They have their own fleet management systems; Borg/Tupperware/ECS. I guess for the EKS team you'd say yeah.

Re: Do you really need Kubernetes?

#44

There's some legit notions here, but overwhelmingly it uses insinuation & suggestion to sow Fear Uncertainty and Doubt. > Despite its portability, Kubernetes also introduces a form of lock-in – not to a specific vendor, but to a paradigm that may have implications on your architecture and organizational structure. It can lead to tunnel vision where all solutions are made to fit into Kubernetes instead of using the ri…

I think the larger issue is how Kubernetes often is implemented in organizations - as part of internal developer platforms owned by central teams which on purpose or by accident can end up dictating how development teams should work. I think it's easy for such central teams to fall into the trap of trying to build smart, custom abstractions on top of Kubernetes to simplify things, but over time I believe these types of abstractions run a high risk of slowing down the rest of the org (good abstractions are really hard to come by!) and creating fuzzy responsibility boundaries between central and development teams. As an example, this can affect an organizational structure by (re-)introducing functional silos between development and operations. Can a development team really be fully responsible for what they build if they rely on high-level, custom abstractions that only someone else in the org really understands?

Furthermore, if everything in an org is containerized and runs on Kubernetes, it's really easy to have a strong bias towards containerized workloads, which in turn can affect the kind of systems you build and their architecture.

Re: Do you really need Kubernetes?

#45

Earlier quoted context omitted.

> At this point, a managed Kuberentes cluster is no worse than any other option Except in terms of pricing...?

K3s adds minor overhead to my single node $8/mo vps. Edit: no, not managed. Quite easy to get started with though. Edit2: took ~440MB of ram & 3% CPU (most of the CPU is the local storage provisioner, weirdly?). Why? Because it was much easier than continuing to maintain and run the handcraft Ansible scripts I've done over the years, and let me easily manage DNS, certs, metrics, two dbs, and its easier to reuse these…

I just ran the k3s install script on a vm, and then ran 'systemctl status k3s', and apparently it's using 1.4GB of memory (I haven't started any pods yet). I understand why you might opt for Kubernetes in a multi node cluster, but what does this provide in a single node cluster that you can't achieve with Docker Compose (or Podman Compose)? Not trying to be snarky, I'm legitimately curious.

EDIT: After playing around with this, it appears to scale its memory usage relative to the machine's total available memory. If you run it on a vm with 1GB or less of memory it'll use up roughly half the machine's memory.

Re: Do you really need Kubernetes?

#46
post #33
post #7

Earlier quoted context omitted.

The entire reason is popularity/marketshare, and that's a really valid reason to choose tech like this.

Makes sense. And with LLMs training on what is publicly available, this becomes self-fulfilling, because you'll get better answers from AI about what is popular - not what is technically superior.

That's already true on forums where answers depend on humans. It's possible that LLMs will make it even more prevalent but they won't have started the phenomenon.

Re: Do you really need Kubernetes?

#47
post #35

I’m sceptical of this article. I’m an indy dev using K8s at vultr (VKS) and it’s absolutely simplified my life. The article suggests just using EC2 instead of K8s, but if I do that, I now have to manage an entire operating system. I have to make sure the OS is up to date, and balance all the nuances this entails, especially balancing downtimes, and recovery from upgrades. Major OS upgrades are hard, and pretty much g…

(Author here) The main focus of the post is to highlight some of the long-term risks and consequences of standardizing around Kubernetes in an org. If you've done a proper evaluation, and still think Kubernetes makes sense for you, then it's probably a sound decision. But I think many skip the evaluation step or do it hastily. The post is more targeted towards organizations with at least a handful of employees. What…

I may have misread ECS as EC2 and I apologise for that.

But the argument you make should certainly be applied to other managed services. AWS generally has opaque pricing, and significant hidden complexity - are you really going to just subscribe to ecs and fargate? Or are you subscribing to a bunch of other complexities like CloudWatch, IAM, EBS, etc etc? If I want to control costs then do I also need some third party service? How many IOPS does my database need, anyway?

I’m not an AWS user, because every time I’ve looked at it I’ve come away shaking my head at how complex everything is, and how much vendor specific technology I need to learn just to do something simple.

And, having run organisations with more than a handful of employees, if there’s anything I’ve learned it’s that simplicity is a virtue.

In fact, the last company I was involved with went all-in on AWS which involved formal training for everyone, very high costs, and multiple dedicated administrators. My part of the business pre dated that decision, and we did well over 10x the throughput with a single dedicated ops expert, using our own gear, orchestrated with docker-swarm. Our costs were literally 10% of the cost of AWS for the other part of the business, including amortisation of the hardware, and that’s before all the extra training and operational costs of AWS.

Today, it’s far easier to run K8s than it was to run swarm back then. So quite honestly, if you’re an Indy developer like me, K8s is almost a no brainer, and if you’re a mid sized SaaS shop, AWS is just a really great example of spending tens of thousands of dollars a month to say you’re running in AWS.

Re: Do you really need Kubernetes?

#48

Earlier quoted context omitted.

Learn to write cachable, scalable apps. I'm expected to write a service like s3?

Well, you could deploy Minio. I see Kubernetes as an enabler. Grab some commodity hardware - your own or Linode - and have a cloud experience using open-source components. I just wish Kubernetes wasn’t so darn complicated.

Or use GKE/AKS/EKS and save on the salaries needed to operate clusters and hardware

Re: Do you really need Kubernetes?

#49

There's some legit notions here, but overwhelmingly it uses insinuation & suggestion to sow Fear Uncertainty and Doubt. > Despite its portability, Kubernetes also introduces a form of lock-in – not to a specific vendor, but to a paradigm that may have implications on your architecture and organizational structure. It can lead to tunnel vision where all solutions are made to fit into Kubernetes instead of using the ri…

>>> This seems a bit absurd on a number of fronts. It doesn't shape architecture that much, in my view; it runs your stuff. I mean, let's be candid. There are plenty of times where "containers" are bags of shit software that were pushing into production and throwing hardware at them to keep things going. There are containers out there with out of date libraries that aren't getting updated cause the "work" and no one…

Containers can be a crutch for poor software maintenance, oh sure! Lots and lots of companies skate by with shoddy container infrastructure (often to relatively little ill impact imo). But I don't see much opportunity that is opened up by getting away from containers. One can do "highly integrated engineering that produces diagonal scalability" just as easily on containers as not, in my view. Containers don't inhibit much.

WhatsApp remains the glorious one example of ultra-efficient software. Way to go taking ejabberd+erlang and going far!! But does that path exclude Kubernetes? I doubt it. That architecture would have ran fine as containers or+and on Kubernetes. It wouldn't have made a material difference to what they were doing. It just would have been a different way to manage the underlying platform. Who knows, maybe it would have provided some patterns/templates/apiserver-ing that the team would have found useful to develop atop, to build forward on, that they instead had to build themselves?

Re: Do you really need Kubernetes?

#50
post #44

There's some legit notions here, but overwhelmingly it uses insinuation & suggestion to sow Fear Uncertainty and Doubt. > Despite its portability, Kubernetes also introduces a form of lock-in – not to a specific vendor, but to a paradigm that may have implications on your architecture and organizational structure. It can lead to tunnel vision where all solutions are made to fit into Kubernetes instead of using the ri…

I think the larger issue is how Kubernetes often is implemented in organizations - as part of internal developer platforms owned by central teams which on purpose or by accident can end up dictating how development teams should work. I think it's easy for such central teams to fall into the trap of trying to build smart, custom abstractions on top of Kubernetes to simplify things, but over time I believe these types…

Can you name any systems which are possible by being non-containerized? What do you see as the advantage here?

It seems like a legacy view of the world that containers are at all worse. Today they seem to offer minimal overhead & access to all the same hardware capabilities as native apps.

Post reply on HN