Yes, let's compare CPUs that took literally decades to mature and there are a handful of companies that can design and manufacture them to K8s.

We don't want to run k8s from scratch? Let's buy the managed version in the cloud?

It sounds like an argument for containers.

I mean, at that point why not use a simpler abstraction, like a VM. Or just use functions.

No, it's not. If going for managed services: A load balancer + an asg is stupid simple to setup and it just works.

How do you deploy your code in this scenario, ssh into VMs?

Level 1) you package your service into a zip/rpm/deb/etc and have an agent on the machine that periodically pulls

Level 2) you pack your software into an ami and use the update the asg config. You can periodically "drain" the asg of old instances

Level 3) you deploy your stack again with the new stack having the ami that you've build at level 2 referenced. You start shifting traffic between the old stack and the new stack. You monitor and rollback if something is wrong.

I find it's easier to use Ansible/Salt/Puppet Bolt and Packer to bake an AMI every night, update the launch template in a DB (which Terraform pulls the value from, thus there is no drift), and auto the ASG. Then you just force a drain.

Now you've got automatic, constantly updating VMs every night if you want them. And a new deployment is just commiting code to master and pushing and that whole pipeline triggers for you.

People like to overcomplicate things, Mirceal. You're on the right path :-)

Worst solutions I've heard in a while, no offense...

sure thing. share your solutions and why the are better?

I'll be honest I haven't fully explored AMIs as a solution but how do you run the AMI in your local dev environment? I can replicate the same K8s with docker images easily in local dev.

If you can't run your software locally without Docker, I'd be worried.

But to answer the question, VMs have been a thing on the desktop for a very long time.

that's the crux of the problem. people no longer know, understand or want to know and understand what their software is vs what is around their software. they treat docker and k8s as a way of packaging software and just ignore all the lessons that generations of software engineers have learned when it comes to how to properly manage your dependencies and how to correctly pack your software so that it's resilient and runs anywhere.

we also live in a world that does not appreciate well crafted software and a lot of things are driven by the desire to build a resume. I've maintained code that was decades old and was amazing to work with and was still generating ridiculous amounts of money. I've also worked on code that was just written and used all the possible bells and whistles and development speed grinded to a halt once the it's been around for more than a couple of months.

My worst case scenario is having to work on code where the original developer didn't understand what they were doing and they just wanted to use X. Double the trouble if they didn't master X when the thing was put together.

How do you download AMIs of Redis, Postgres, etc? Are you building this all by hand?

A basic k8s service is just as easy if not easier and takes you way further

> Stop pretending Kubernetes is this humongous infrastructure investment that mandates a full time job to keep up at low scale.

It is a full time job. The cost of using something is not just the setup cost. The same way that software development is not just the cost of writing the software.

How? What is keeling over so often on that is not on a simpler setup?

I've set up EKS multiple times across different companies with few nodes and everything runs smoothly all of the time.

Can you go into detail?

Indeed. Hosted k8s has been low maintenance in my experience, much lower than managing a bunch of VMs. I think the common thread between people who have horror stories using k8s is either pains from self-hosting or teams who adopted it without experience and used the ample rope it gives to hang themselves.

YES!

"It's easy to setup" speaks nothing to how much effort it takes to maintain.

If you're on bare metal there is a case for K8s. How many people are on bare metal?

So, your argument is that you should use a tool if you know how to use it, regardless of if it's actually needed?

Personally I would take managing "a couple of webservers and a db" any day over k8s.

His point is to use whatever simplifies workflow / reduces operational overhead. To some people, that indeed would be k8s. To you, that may be "managing a couple of webservers and a db". And that is great for you.

yeah I use k8s for basic webapps and it works wonderfully, and is way way easier than anything else, and yes I started developing in the 90s so I've seen it all. There is a bit of overhead in learning k8s, but once you know it, it's dead simple for every use case I've found and takes you way further than anything else.

Hah. Interesting though experiment but in today's world even not all humans have human rights. Good luck enforcing that.

Inevitable at some point? At what point? If we are 500 years away from it does it make sense to invest resources in figuring it out now? It humans don't survive as a species is it really inevitable?

Another thing that most people don't get or don't want to acknowledge is that intelligence and consciousness is relative to the environment in which the entity is intelligent or conscious in. If you take a piece of software and expect it to be conscious the same way a human is conscious you're going to have a bad time. There is heavy heavy projection when it comes to humans interacting with basically everything. We anthropomorphize everything.

From that vantage point we will not be able to recognize intelligence and consciousness unless it look exactly as our own.

That's the tragedy of software development. Nobody wants to do work that isn't super visible (usually in the form of new features). Simplicity and robustness are not appreciated nor rewarded.

What? Are you a park ranger now?

It also seems designed to stop anyone walking to a bar, yet be able to walk to a church.