Microservices architecture disaster

[SlurrerOfSpeech]

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]

 

[DaveC426913]

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).

First question would be: if it's working quite well, why fix it if it ain't broke?

There could be a few answers to this:

1. It's broke.
2. It requires excessive maintenance, and possibly downtime, to fix a small problem in a big application. The entire thing needs to be re-rested.
3. Smaller services tend to be more secure. It is easier to prevent intrusion of a bunch of small rooms than to prevent intrusion of a large factory floor.
4. Smaller services are far easier to debug.
5. They want to leverage the micro-services with functionality not directly part of the main app.

etc.

Those are just off the top of my head but there's many more reasons. You can't apply an architectural principle in a vacuum, without first getting a clear understanding of the business requirements.

 

[jedishrfu]

There is value though rearchitecting the monolith into component ms parts means individual parts can be spun up as copies to meet demand. It means individual ms parts can be replaced with newer designs or updated software.

Here’s a talk on ms from YouTube

 

[DaveC426913]

True, That's another advantage: micro-services don't all have to run on the same machine. You avoid catastrophic failure.

 

[SlurrerOfSpeech]

True, That's another advantage: micro-services don't all have to run on the same machine. You avoid catastrophic failure.

Huh? You can have N running instances of a monolithic service.

 

[DaveC426913]

Huh? You can have N running instances of a monolithic service.

Yes. But only one machine per monolith. So if it fails, the whole thing fails, instead of subcomponents failing one-at-a-time. Sure, you can have redundancy and failovers, but with smaller, distributed services, only smaller, distributed things fail.

I realize this is a bit of an over-simplification of major applications, but still my question remains: what is the business rationale for the change? You haven't told us why they want to do this.

 

[Rive]

Let me describe the problem I see as an engineer when a business wants to create microservices out of its "monolith"

By my experience this kind of change is often related to the assumption that a redo along the line of the actual buzzword can be done without much time assigned to planning, testing and debugging.