[KronisLV]

When I'm forced to work with a monolith that has 4000+ source files and takes a few minutes to even start up, and has about 20 configuration files that all need to be setup properly for it to even start, I wish for microservices.

When I'm forced to work with microservices that need Skaffold and Helm charts just to run locally, but with the configuration in the monorepo being kind of mismanaged and strewn around a bunch of folders with no documentation, in addition to debugging in the IDE not working because nobody set it all up, I wish for monoliths.

Really, you can have good monolithic systems and you can have good microservices as well, in addition to something in the middle: https://blog.kronis.dev/articles/modulith-because-we-need-to... (actually the first blog post that I wrote, the casual language probably shows its age).

But there can also be plenty of poorly developed projects with either. It just so happens that people hate monoliths more in the mainstream culture because most of the older and worse projects out there were monolithic, much like many hate Java and other languages because of being exposed to bad legacy projects written in them: https://earthly.dev/blog/brown-green-language/

Just wait for 5-10 years and people's disposition towards both monoliths and microservices will even out, the advantages and disadvantages of either will become clearly recognized and the hype will shift towards something like serverless. Much like now we know the advantages and disadvantages of languages with/without GC as well as higher/lower abtraction levels pretty well (consider Python vs Rust, for example).

Maybe things will slow down a bit because Kubernetes will also become a bit easier to use, possibly thanks to projects like K3s, K0s, Portainer and Rancher.

[barking_biscuit]

It turns out the secret is just not writing crappy software and having crappy processes. It turns out the caveat is that the conditional probability of those two things is vanishingly small, so regardless of monolith or microservices, most devs are exposed to crappy stuff and because their sample sizes are tiny they assume well we just did it wrong, when in fact they did it average and average is crappy for any and all architectures.

[KronisLV]

> ...when in fact they did it average and average is crappy for any and all architectures.

I feel like this is probably more true than many of the people around would like to admit.

Very much like how there are plenty of proponents of DRY and SOLID but plenty of bad systems still get built regardless, even when trying to follow any number of principles along the way.

So you'd have to decouple what an architecture is supposed to (realistically) be, from any company-specific interpretation of that, which may not actually be doable. It's not so much the "No true Scotsman" fallacy (which comes to mind), but rather the fact that things almost always differ in theory in practice.

As an unrelated example, it would also be really useful to generate implementations from code models, like OpenAPI spec --> usable API client in language/framework X, or OpenAPI spec --> usable service stubs for the server in language/framework X, but in practice it never works out and most model driven approaches remain on paper.

Similarly, there are lots of ways to screw up your application architecture regardless of the specifics. Talking about which type is easier to screw up and in what ways, however would be a useful conversation to have!

[_hcuq]

I wonder if part of the problem is the always new technologies used. Maybe if the world had stuck with some sort of improved version of C and got really good at it, with all kinds of great tools and techniques, we might be able to deliver code efficiently.

[barking_biscuit]

I definitely think that's an aspect of it, but it's not one we can really do a whole lot about. The nature of what we do and the skillsets we have mean when we encounter problems we then come up with solutions and those solutions have their own problems, so it just infinitely recurses.

I think that's a lot more controllable on an individual level than on an industry level. I'm sort of attempting to do that myself in some ways by just picking a stack and working my way through building something in it end to end covering absolutely every aspect I can imagine in terms of software engineering "jobs to be done" and as I build it, going through industry go-to resources of how to best do X and properly implementing the advice. I think if more of us bothered to do that we'd be far more capable of starting software companies off at a much more advanced stage of technical maturity and hence with less problems that arise from the hacky shit we cobble together under financial pressure to ship, ship, ship. That would ideally result in significantly less churn.

Essentially, yes. Just take something and get ultra good at it and then stick with that thing.

[jnash]

Nothing stops microservices from having the same problems. Plus all the extra problems you get with distributed systems (timing issues, logical dependencies etc.)