by clubdorothe on 8/4/21, 2:17 PM with 65 comments
by rollulus on 8/4/21, 3:12 PM
Or am I missing something?
by zinekeller on 8/4/21, 3:06 PM
This is basically how everything should work. There's no need to rush things if you don't need 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.)
> So maybe there’s no point in keep discussing microservices vs monoliths.
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 (https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Ac...), they are more concerned with disaster recovery and slowness to logged-in users, not quick scalability.
by BiteCode_dev on 8/4/21, 2:59 PM
by recursivedoubts on 8/4/21, 3:06 PM
yeah, there's a place for monoliths, and developers who are willing to ignore the industries ludicrous fads and faang-chasing have the advantage.
by eric4smith on 8/4/21, 3:41 PM
Then as it grows and it makes sense to decouple at the edges then it makes sense.
And these micro services only make sense when there is a team responsible for each one.
Otherwise the whole thing is like a game of chess - you will forget to make a move at some point.
by loourr on 8/4/21, 7:50 PM
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.
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.
I highly recommend the monolith for anyone who is not trying to cope with epic scaling issues.
All hail the monolith!
by cientifico on 8/4/21, 3:18 PM
It's alignment with the company structure is.
The same way Conway's law tells us that company structure and the communications should be in sync, the architecture should match the teams.
As a rule of thumb... the good architecture is the one that minimize the communication within the different teams.
by dasil003 on 8/4/21, 3:48 PM
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, then they probably shouldn't be two services.
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.
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.
by silvestrov on 8/4/21, 3:04 PM
I have the inverse experience: management wants to brag about tech and therefore force ill-suited tech onto the developers.
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).
by glutamate on 8/4/21, 3:00 PM
Please ELI5 how I get better code reuseability in microservices than in my monolith with separated concerns into libraries and helper modules.
by littlecranky67 on 8/4/21, 3:35 PM
> Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed.
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).
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.
by madeofpalk on 8/4/21, 3:08 PM
> Is there any place for monoliths in 2021?
maybe one year we'll get our answer!
by fortytw2 on 8/4/21, 3:03 PM
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.
by halfmatthalfcat on 8/4/21, 3:00 PM
I think it ultimately it depends on the tools being used and the team building them because there's tradeoffs to going each way.
by tester756 on 8/4/21, 3:07 PM
Way easier to debug
by cwitty88 on 8/4/21, 3:05 PM
by lobo_tuerto on 8/8/21, 5:42 PM
by mat0 on 8/4/21, 3:44 PM
by KingOfCoders on 8/4/21, 3:25 PM