91–100 of 243 posts
Earlier quoted context omitted.
He's always been pushing monoliths.
Then I ask forgiveness for ever doubting him. Can he help us turn back from this Cloud Hellscape?
Earlier quoted context omitted.
“we have 100 people so require 20 microservices”. More like 3 people requiring 13 microservices
I'm convinced that micro-service hell happens when the primary app calcifies and becomes too difficult to modify.
Once we've explored this to its logical conclusion the pendulum will swing back to something more logical. Of course, it will swing too far and the cool kids will only want to work on monoliths even when it doesn't make sense (kind of like what is happening now with SQL maximalism).
You know, I'm pretty sure you could build a PHP monolith in 2023 without a framework and it would do what it needed to do.
Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…
The talk of essential and incidental complexity is, in practice, far less useful than it seems. It's just very easy to just agree in trying to just get rid of incidental complexity, in the same way that it's easy for people to agree on getting rid of unnecessary, wasteful government programs, until the second you define which ones you mean. Every time I've had that argument at work, ultimately there's no agreement of…
He’s been ranting against cloud too.
[1] https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-se...
I can’t believe it’s news that someone said this. I thought everyone understood: you don’t try to do microservices until you have to . Before you get to that point you make your monolith modular enough that if you ever need microservices you’re prepared to break them out.
I've seen terrible spaghetti code apps where literally nothing can be refactored because of the model / view, God object dependency stuff all over the place.
I can’t believe it’s news that someone said this. I thought everyone understood: you don’t try to do microservices until you have to . Before you get to that point you make your monolith modular enough that if you ever need microservices you’re prepared to break them out.
If the need arises, you could move into SOA, and break out a couple of your larger domain modules. Continue following these same rules though.
If the need arises still, you could move into micro services, and break out more / all of your domain modules. Truly understand first whether you actually need this first.
But the "let's do micro services this monolith is old junk" trope, abandonwaring the codebase, building out a bunch of services without strong, fundamental domain knowledge, and then complaining when shit is expensive and fragile and broken- it's getting tiring.
Earlier quoted context omitted.
There is no going back. The industry has seen a 5X raise in money and people. It's only natural that a job that used to take 2 now takes 10 people because of those facts. And I agree. We've traded safety and a few other things that could have been ironed out in exchange of massive gridlocks, headaches and colossal facepalms. Performance is only on par if you consider the hardware improvements, it's crazy.
If you can have a monolith for $500/month with a team of 2, or a distributed system for $50,000/month with a team of 50, what manager in their right mind would choose the former. Zero prestige in that.
There is no formal theory around system design so you get people complaining about how monoliths are error prone and way too complex and you get people complaining about microservices with the exact same argument.
The result is that with a period of about a decade the industry just oscillates between the two methodologies in an endless flat circle.
Monoliths will come in vogue again in the 2020s.
Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…
Not true. I blow.up a car. Complexity is destroyed. I rebuild the car from blown up parts. Complexity is created.
There's no underlying generic philosophical point about microservices and monoliths. What we can say is that microservices are not necessarily less complex than monoliths, but this relationship has no bearing on the nature of complexity itself.
Earlier quoted context omitted.
The talk of essential and incidental complexity is, in practice, far less useful than it seems. It's just very easy to just agree in trying to just get rid of incidental complexity, in the same way that it's easy for people to agree on getting rid of unnecessary, wasteful government programs, until the second you define which ones you mean. Every time I've had that argument at work, ultimately there's no agreement of…
The strict definition would be essential complexity is only the complexity that would be required to implement in an "ideal system" (eg no latency, memory concerns, etc). By that definition you cannot just abandon all incidental complexity (as our systems are no where near ideal). Instead, this way of thinking is helpful for keeping the essential complexity implementation isolated and free from the incidental complex…