software dev ranting
@joepie91 ask 10 developers and you can't even get anyone to agree what it is, but the ideology is still damaging because of all the performance costs and externalized costs you get from trying to put every function behind a https call with authentication
microservices, re: software dev ranting
@rune Applying the "quacks like a duck" methodology yields a definition: microservices are an architecture where components of the application are split up into separate processes or (network-accessible) services proactively without having a concrete technical need for it yet".
As far as I'm concerned, that's the definition because it's the only fundamental property that sets microservices apart from everything that existed long before it (separating out intensive tasks is not exactly a new concept after all).
And if that definition sounds an awful lot like "premature optimization" to you, ding ding ding...
microservices, re: software dev ranting
@shine @rune I've found that this is pretty much the key to how microservices caught on in the first place, too. All the supposed 'benefits' of it being touted around are *really* just the benefits of modular code, and having separate services plays no role in this at all...
But you are pretty much *forced into* writing modular code with microservices, so people who have otherwise never learned to do so attribute all these benefits to microservices instead, which of course is great for the tech companies like Amazon that popularized the concept to begin with, because microservices are way more profitable for them
microservices, re: software dev ranting
@joepie91 @rune also, every problem of bad design in monolith has even worse impact in microservices and makes the whole thing more fragile.