11–20 of 169 posts
Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?
Big corp wins while their customers create DevOps and other buzzword teams and the majority of IT world loses the capability to actually administer systems and becomes users addicted to ever-changing vendor offerings that complicate learning useful stuff outside.
Monolith is an unfortunate term by which everyone seems to mean something different. So is any application whose parts do not communicate via network interfaces a "monolith"? Is an application where the majority of the function calls are not realized as a series of network transactions (like CORBA at that time) a less good application than one where different classes and modules on the same machine communicate directly with each other?
We should stop using the term, nor assigning blanket value attributes to it. "Monolyth" is not the antonym to "Microservices", as suggested by the article. From a certain distance, every system looks like a monolith; that has more to do with the viewer than the system.
Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?
Yea. IMO, microservices are usually more of an organizational solution than a technical solution
Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?
Breaking up an app into microservices is total overkill in this instance...
Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff
Microservices instantly looked like a fad. Two classes of fad apply. One is a "move stuff around and complexity will magically go away" fallacy fad. The other is a "way to promote vendor lock-in or higher cost" fad.
Other major classes of fads are: consultant self promotion fads, re-invention fads of all kinds in which devs speed run the history of some aspect of computing to arrive at the same place, magic pixie dust fads where sprinkling some buzzword on things makes everything better, management "methodology" panacea fads, etc.
Avoiding fads is a superpower. It tends to save a whole lot of money and wasted time.
The test of whether something is a fad is whether it reduces incidental complexity, enables something categorically new, or genuinely boosts developer velocity.
Incidental complexity is the complexity that creeps into our designs that is not essential to the problem but an artifact of how we got there or some prior limitation in how things are done. A genuine innovation will make incidental complexity actually go away, but not by pretending that essential complexity doesn't exist.
A categorically new thing would be e.g. deep learning or an actually practical and useful provably-safe language (Rust).
Boosting developer velocity means actually speeding up time to ship without doing so by adding a ton of technical debt or making the product suck.
If something doesn't do at least one of those things well, it's a fad.
Yes, but it also comes with a cost. Microservices might still fail in a cascade manner and bringing such system up under significant load is even more challenging.
Microservice is to manage junior level programmers who don't know how to make loosely coupling architecture. That's it. Because your job is to manage low quality code produced by junior devs, you need to use microservice to prevent bad code to break the monothlic. Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff