Remove reliability intercorrelations, so for example that your cart api and payment gateway is up and collecting orders no matter to what happens to the front-end services.

But then for perfect decorrelation you'd also need independent databases behind the microservices, and queues between them for horizontal communication,and few are actually going all in with that, and so fall in the 95% where they go trough te motion and the effort of splitting microservices,but reap no actual benefit from it.

Like any tool, there is nothing that cannot be done without microservices. However that doesn't mean they never make sense. Microservices have certain costs and certain benefits. I can believe there are certain situations where the benefits outweigh the costs. Its just not most situations. But that doesn't mean it never exists. I could believe it makes sense in extremely large apps with huge number of different groups working on them, where the communication complexity outweighs the other complexities microservices bring.

That's very hypothetical. Building a distributed system just might always be way more resource intensive than comparable monlith regardless of number of developers involved.

There's a bunch of things I'd like to have them do. If they could span across machines like clusters that would be amazing.

If I could trivially package them up and deploy them locally with intrinsically less effort and wall-time then the old way, that'd be amazing.

If I could somehow get the horizontal scaling promises and redundancy as some kind of built-in, like I can with say, memcache, that's be cool.

If I could do these kinds of "hard" things with them more trivially, that'd be really nice.

There's a lot of things I want them to do but it's a god-damn bull-riding rodeo every time I try to get there.

And before you reply, I know you're an expert and can do all these things trivially. That's amazing. The vast majority of the industry creates a giant fragile spaghetti knot with them and I am not a full time k8s admin nor do I want this to be a career trajectory. It should be like you know, wine, ffmpeg, imagemagick, virtualbox, lua, qemu, redis, gnuplot, lvm2, gdb, ssh, sqlite; tools like that. It's pretty easy to get them to do really nice things. Those things deliver on their promises and potential pretty nicely.

It's nice that nobody feels a need to hype curl or squid. They just work. Isn't that nice? I mean look at gdb's website: https://www.sourceware.org/gdb/ it doesn't even have CSS animations --- in fact, it doesn't even have CSS.

Did you ever play with the Erlang VM?

Absolutely. It's pretty brilliant. I thought about mentioning it. I don't hate it. It's a bit exotic to trust with the likes who tend to fill the ranks of development teams which try to force every language into looking like C++ of Java but I dunno, send them off to a retreat in the mountains to microdose and take lessons from an erlang yogi for 12 weeks and have them come back.

Your asks seem easily answered with docker + kubernetes. Actually, this is in fact the use case for kubernetes — a fault tolerant distributed system running arbitrarily, simply packaged code. This has to be what you’ve tried — what issue are you running into?

Kubernetes isn't something I'd put in the same sentence as 'easy'. Docker is a close contender for the same.

I still recall the day when my local Docker builds necessitated a new router to properly manage streaming traffic at home while I downloaded a few GBs of layer images. Or the time I wanted to setup a 'simple' hosted Kubernetes cluster of my own in my lab for testing, only to discover the nightmare that is networking on it. Then there was the grim discovery that Docker containers were much more sensitive to the hosting environment than I had assumed, resulting in some fun "but it worked and tested fine" moments.

Did they all work eventually for me? Yes. Was it simple? Not by my standards.

If you find all that simple, kudos to you.

When they say k8s is "easy" they mean "for developers", not people/automation running it.

Like, compared to implementing hitless rollback over bare metal services k8s way is "easy", just set some stuff in YAML and have proper healtchecks in your app.

The issue I encounter is the overhead in setting up a repeatable, easy-to-use dev environment, and working out the bugs locally before I push to a prod-like system.

trying to using the actual software to accomplish these actual tasks. You're right though, that is the promise of the software - it doesn't deliver.

I wish I had infinite time to document all the issues. This isn't a small nuanced detailed thing - it falls deeply, systemically fundamentally short and in practice you still get the magical monolithic system it tried to kill but now with more obfuscation, complexity and a theatrical slight of hand to convince yourself it isn't that.

Instead of the server being configured for the monolithic app, it's now extensively and carefully configured for the myriad of containers, hostnames, configurations and connections of the containers running the microservice app.

It's in practice the same problem with a different costume.

The other promise of it being a collection of smaller constrained services running on tcp ports talking to each other ... that's nothing new. You've invented the idea of computer networks.