- #1
SlurrerOfSpeech
- 141
- 11
Let me describe the problem I see as an engineer when a business wants to create microservices out of its "monolith" (a term used derisively to describe an existing service that works quite well).
You have X that you want to divide into A, B, C, or maybe A, B, C, D, E. So you want to create 3 or 5 distinct responsibilities from X.
Services are not like classes. If X is designed properly, it might have 1,000 classes each with a single responsibility. But it would be incredibly wasteful to 1,000 services. Creating a service requires a lot of overhead comparing to creating a class (as simple as "right-click + new file" in an IDE). You have to create APIs, contracts, secure access keys, deployment scrips, etc. for each of the 1,000 services.
So, the couple services A, B, C you create are at best buckets that hold different code from X. What exact problem is being solved by taking 1 thing and slicing it into 3 things that are 1/3 the size? You just create a distributed monolith. X still exists.
Here is the point I am trying to make: You should only do this microservices thing if you are rearchitecting X. That means you are creating a new platform that accomplishes the same thing, and you might need to get rid of old business entities, old data flow, old concepts. There is no value in fulfilling a request like "We want our same platform but as microservices."
[/rant]
You have X that you want to divide into A, B, C, or maybe A, B, C, D, E. So you want to create 3 or 5 distinct responsibilities from X.
Services are not like classes. If X is designed properly, it might have 1,000 classes each with a single responsibility. But it would be incredibly wasteful to 1,000 services. Creating a service requires a lot of overhead comparing to creating a class (as simple as "right-click + new file" in an IDE). You have to create APIs, contracts, secure access keys, deployment scrips, etc. for each of the 1,000 services.
So, the couple services A, B, C you create are at best buckets that hold different code from X. What exact problem is being solved by taking 1 thing and slicing it into 3 things that are 1/3 the size? You just create a distributed monolith. X still exists.
Here is the point I am trying to make: You should only do this microservices thing if you are rearchitecting X. That means you are creating a new platform that accomplishes the same thing, and you might need to get rid of old business entities, old data flow, old concepts. There is no value in fulfilling a request like "We want our same platform but as microservices."
[/rant]