3 ms·
I have this thing I say sometimes... "Which kneecap do you want the bullet in?" Microservices vs monoliths is a tradeoff, and a partisan holy war "My way is rig
by beat 10y ago
I have this thing I say sometimes... "Which kneecap do you want the bullet in?" Microservices vs monoliths is a tradeoff, and a partisan holy war "My way is right and their way is wrong" argument fails to recognize that point.
Monolithic services benefit from integration and suffer from complexity. Microservices benefit from simplicity and suffer from isolation. That's it. That's what matters. If you build a monolith, sooner or later you wind up with a big ball of mud that nobody fully understands, with careful consideration required before any new functionality or refactoring. Likewise, if you build microservices, you wind up not knowing exactly who or what is dependent on whatever mistakes you might have made in the design in the first place, and a lot of inter-team negotiation required to make significant changes in how the microservices behave.
What I find interesting is the evolution. If you have a ball of mud monolith, it can be very difficult to refactor due to complex internal dependencies. Pulling a chunk of functionality into a - microservice - is a way of pulling off a major refactoring without finding yourself up to your ass in alligators.
Likewise, if you find integration points and inter-team communication and duplicated structures are killing you, you start merging microservices together, building something more complex to solve complexities that exist outside of any single service.
Software evolves. Deal with it.