In the cons of monoliths: "High coupling between components" is listed. I think this is a misconception, and a popular one: some people apparently believe that if you take software, and introduce some RPC form at "component" boundaries, things are magically decoupled. I.e., just because execution happens in a different process, it is decoupled. And this fallacy is what leads to the distributed monolith.<p>Or am I missing something?
> If we analyze most of the successful migrations into microservices, they were driven almost exclusively from necessity rather than preference.<p>This is basically how everything should work. There's no need to rush things if you don't <i>need</i> it now, especially that some that do convert are disappointed at the results (it's not the microservices themselves, it's the specific migration planning, design, and maintenance.)<p>> So maybe there’s no point in keep discussing microservices vs monoliths.<p>Wikimedia has monoliths for text-based systems and microservices for (some) media-based systems, and it make sense: transcoding is unpredictable workload (for them, I imagine this is more common for YouTube) while database operations (at Wikipedia's scale) is very predictable and doesn't warrant the additional complexity. Even in their planning for multi-datacenter operations (<a href="https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Active-active_MediaWiki" rel="nofollow">https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Ac...</a>), they are more concerned with disaster recovery and slowness to logged-in users, not quick scalability.
Most softwares are monoliths in 2021. The exceptions are over hyped, because the day to day lives of administration and corporate devs are boringly standard.
microservices: let's take the hardest problem in software construction, factoring the system properly, and introduce network connections and deployment complexity into it.<p>yeah, there's a place for monoliths, and developers who are willing to ignore the industries ludicrous fads and faang-chasing have the advantage.
Every project should be started as a monolith. Period.<p>Then as it grows and it makes sense to decouple at the edges then it makes sense.<p>And these micro services only make sense when there is a team responsible for each one.<p>Otherwise the whole thing is like a game of chess - you will forget to make a move at some point.
After much debate my company recently switched back to a monolithic architecture and it may be the greatest decision we've ever made.<p>It dramatically simplifies so many aspects of development, which means you can have developers working on more impactful features and you don't have to worry about create a meta structure for keeping things consistent across all your micro services which is one of the biggest benefits I didn't see mentioned in this article.<p>And in many systems with interdependent logic (which ours is), not duplicating data and not having micro services calling other micro services in loops become incredibly difficult things to avoid.<p>I highly recommend the monolith for anyone who is not trying to cope with epic scaling issues.<p>All hail the monolith!
In my experience, the architecture is not relevant at all for the success of a business.<p>It's alignment with the company structure is.<p>The same way Conway's law tells us that company structure and the communications should be in sync, the architecture should match the teams.<p>As a rule of thumb... the good architecture is the one that minimize the communication within the different teams.
I feel all these black and white comparisons of monolith vs microservices tend towards being overly reductive and miss the crux of the matter.<p>First, "microservice" is a terrible name (we should have just stuck with SOA), it leads to all kinds of agile consultant snake-oil salesmen claiming some ideal size for a service. That's bullshit. Services should be defined by their interfaces, full stop. If you can't come up with a stable interface between two services such that the interface changes orders of magnitude than the code within each service, or if you find yourselves always having to deploy the services in pairs due to leaky abstraction on the interface, <i>then they probably shouldn't be two services</i>.<p>Second, SOA is primarily a tool for scaling teams. Yes there are some tangential benefits in terms of code base size, CI build time, etc, but those are false economies if you have a small team that has to deal with the overhead of many services.
Modern web-scale architectures are really about factoring things to leverage specialists to scale very large tech platforms.<p>Third, and perhaps most importantly. In any rapidly growing business you need to evolve quickly. You should not expect to design a perfect architecture day one, you should plan to evolve the architecture continuously, so that every two orders of magnitude growth you look up and realize you've replaced most of what you've previously written one way or another. Small startups that focus on "microservices" before they are anywhere near 100 engineers tend to die before traction.
> Developers always want to try the new flashy things [...] On the other hand, management mostly sees risks .. mostly wants new fancy features<p>I have the inverse experience: management wants to brag about tech and therefore force ill-suited tech onto the developers.<p>I've had managers that wants a CDN because that's what all professionals do and they don't take a moment to think about added risk by adding more components to the system (or even if it adds any benefit at all).
Microservices Pros: Code reusability?<p>Please ELI5 how I get better code reuseability in microservices than in my monolith with separated concerns into libraries and helper modules.
Hearing a lot about monolith vs. microservices, can someone shed some light how "pluggable/plug-in driven monoliths" fit in? To Quote Martin Fowler on monoliths:<p>> Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed.<p>But this is not true. I worked at some C# "monolith" ~2010ish, and we used MEF framework to build pluggable .dll files that you could just "drop" into the deployment folder. As long as you stuck to the same interfaces (through a shared interfaces project) you could build and ship individual parts of the application in separate teams. Even exceptions could not harm the full system (when they were properly caught in the host) - and segfaults shouldn't happen in a managed system (but yes, they did, mostly through P/Invokes).<p>I always liked the good old "Winamp model" where you would just drop some dlls and got new visualization plugins enabled - each more different than the other.
Many of the points in this article are entirely a matter of implementation, not inherent to or ingrained in any particular architectural choice.<p>You can just as easily build a highly modular and decoupled monolith as you can a tightly coupled and fragile microservice. The same point holds true for many of the other pro/cons the author brought up.
It really depends on the framework being used. Some frameworks are essentially micro-in-monolith (Akka) and some encourage the microservice framework (Federated Apollo GraphQL) due to their use case.<p>I think it ultimately it depends on the tools being used and the team building them because there's tradeoffs to going each way.
Decent write-up. I agree that most things should start as a monolith and only move to microservices if no other solution will solve the problem. You can scale a monolith quite effectively with a little planning.