Quote:
Originally Posted by muttiah
If microservices is a solution to an organizational problem that is indicative of major org problems (with an inappropriate technical solution).
Most companies have major org problems and the nature of business is such that you don't always get to fix things the right way in the right place especially if there's a cheaper way to duct-tape things elsewhere. It's like evolution. Very often, death is the cleanest solution.
Quote:
Microservices help to solve scaling and reliability in a large system. Independent development, development, and scaling, and reduce single point of failures.
It's rare that microservices are used this way - technical necessity for separate services comes when you have components that have drastically different scaling or reliability needs than other components in the system. And solutions to these problems are usually not considered to be "microservices" - people typically don't describe RDBMS, an asynchronous queue or custom services of that nature as microservices. It's much more common to use the term to describe a situation where you're splitting up a broad service into multiple services of the same nature in the same tier. Like an animal service into horse/cat/dog/mouse services. That's generally the industry context in which "microservices" are used in my experience. Splitting up services due to technical necessity generally falls under SOA unless "technical necessity" is something along the lines of "our complex service with lots of endpoints has to restart every 5 minutes and we have no idea why."
Quote:
You can definitely have ownership in a monolith.
The problem is that you have to have global ownership as well as local ownership. Clear and separate ownership of different components is not enough because you also need engineers to able to trace across components to be able to even let another team know that they are the ones responsible for a given problem.
Quote:
And in many cases the monolith is much easier to reason about and understand at a global level than microservices.
Of course it's easier to reason about monoliths at a global level. But this is useless unless you have engineers that are willing to do the reasoning. It's hard enough to find such engineers in the first place and lots of companies have organizational culture that explicitly discourages this.
Quote:
I strongly strongly disagree that it's easier to break up a monolith and consolidate services. I have done both and breaking up monoliths is generally much much harder. It's extremely slow and challenging to extract out logic and services from monolith applications that share a common database.
This is presumably because monoliths you broke up are old complex beasts, while microservices you consolidated are fairly new and simple. I mean you were breaking up complex things and bringing together components that wouldn't add to something all that complex, right? Otherwise, why are you moving in that direction? And you likely didn't have to consolidate anything that was unnaturally separated, nor do consolidation much beyond simply bringing a bunch of services under a single runtime/umbrella - it's completely different to replace service calls that accumulated over the years with simple method calls, replace over-specified disparate interface with a more coherent, unified interface, properly refactor years-old services who have developed completely independent and idiosyncratic ways to do the exact same thing and somehow properly translate different services written in different languages into a single codebase in a single language that can be easily worked on as a coherent whole by one person.
