Microservices are also the result of technical debt where the core monolith has become too much of a ball of mud to hack on efficiently anymore. It's the "you have to write code twice— first to find out what you actually need, and again to build the right thing" on a larger timescale. Never seen a satisfying way forward once you find yourself here.
It's 1000x easier to refactor the monolith into a more modular form when it's in a single repo. Wait until you want to try to refactor across service boundaries in a u-services world because you got your boundaries wrong.
Additionally, as soon as you introduce RPC-style (or even event-based) interactions between services your complexity goes through the roof. You need to deal with:
- service versioning and backward compatibility
- serialisation/deserialisation complexity and latency, and synchronization of DTO-style objects between services
- more complex deployments
- far more complex testing
- in-transit encryption for data and key management (eg. Istio, ...)
- network-layer issues
- circuit breakers
- caching / other performance band-aids
- graceful degradation across the stack when services fail
- sagas or equivalent mechanism for coordinating cross-service operations and what happens when things go wrong (fsm help you if you end up needing cross-service atomic transactions because of your ill-thought-out service boundaries)
- etc.
I'm honestly amazed at how many people blindly follow the "microservices good / monoliths bad" mantra given how obviously wrong it is for most teams.
I don't disagree at all. In fact I'm saying the desire for microservices is a sign your monolith could use a refactor. I would call it a canary but it's long dead by this stage.
If it's faster to spin up a new production service from scratch to implement some functionality than leverage your existing code then something has gone very wrong. Shouldn't all that code make implementing complex features faster and easier? Shouldn't your codebase be full of powerful tools that can be leveraged to build completely new things?
Every time I see this happen is because frameworks -- not 3rd party frameworks, but the whisper from Satan that suggests that wrap code in more layers to make it "easier", "simpler" for the user.
> ...where the core monolith has become too much of a ball of mud to hack on efficiently anymore.
A lot of people never go to microservices from that monolith, they just keep adding features to it and deal (well, try to cope) with it being increasingly unwieldy and hard to manage.
Also never forget how they constantly sunset microservices in order to make everyone scramble to refactor into the new (more expensive of course) microservice under a different name... ugh...
If it's been developed as a singleton application (all features always registered/enabled on startup, only one instance ever running), even that might prove to be quite hard. No idea what else to call a monolith that could never run as more than one instance at the same time.
You might have to go through dozens of files and sprinkle feature flags throughout to enable/disable certain modules and making any organizational changes to a codebase over a million lines of code is difficult. Plus, when you have 1000 API endpoints that's generally treated as just "the API", then splitting that up in meaningful ways might present challenges. Aside from that, even if you can cut down on what needs to be enabled for certain development scenarios, you are still compiling the whole monolith, so locally you're saving on some runtime resource usage at best and will still sit around when you make any changes that need you to relaunch the monolith.
In general, I agree. I'd even build new systems as modular monoliths first. Except when it comes to large systems of any kind, even just updating the dependencies might sometimes be impossible (in a reasonable timeframe).
> even just updating the dependencies might sometimes be impossible (in a reasonable timeframe).
Consider the situation where you have a proliferation of micro-services all using a similar but slightly divergent stack, and you're notified of a security issue that means you need to update the same library across the entire fleet of services. I know what situation I'd prefer to deal with.
I use Drupal... Although they issue way too many security & functional updates each year, it's been conveniently 100x less expensive to maintain than microservice architecture apps, and it's open source/PHP as a bonus.
Everything is technical debt once you add the semicolon.
Microservices are also the result of technical debt where the core monolith has become too much of a ball of mud to hack on efficiently anymore. It's the "you have to write code twice— first to find out what you actually need, and again to build the right thing" on a larger timescale. Never seen a satisfying way forward once you find yourself here.
It's 1000x easier to refactor the monolith into a more modular form when it's in a single repo. Wait until you want to try to refactor across service boundaries in a u-services world because you got your boundaries wrong.
Additionally, as soon as you introduce RPC-style (or even event-based) interactions between services your complexity goes through the roof. You need to deal with:
- service versioning and backward compatibility
- serialisation/deserialisation complexity and latency, and synchronization of DTO-style objects between services
- more complex deployments
- far more complex testing
- in-transit encryption for data and key management (eg. Istio, ...)
- network-layer issues
- circuit breakers
- caching / other performance band-aids
- graceful degradation across the stack when services fail
- sagas or equivalent mechanism for coordinating cross-service operations and what happens when things go wrong (fsm help you if you end up needing cross-service atomic transactions because of your ill-thought-out service boundaries)
- etc.
I'm honestly amazed at how many people blindly follow the "microservices good / monoliths bad" mantra given how obviously wrong it is for most teams.
I don't disagree at all. In fact I'm saying the desire for microservices is a sign your monolith could use a refactor. I would call it a canary but it's long dead by this stage.
If it's faster to spin up a new production service from scratch to implement some functionality than leverage your existing code then something has gone very wrong. Shouldn't all that code make implementing complex features faster and easier? Shouldn't your codebase be full of powerful tools that can be leveraged to build completely new things?
Every time I see this happen is because frameworks -- not 3rd party frameworks, but the whisper from Satan that suggests that wrap code in more layers to make it "easier", "simpler" for the user.
> ...where the core monolith has become too much of a ball of mud to hack on efficiently anymore.
A lot of people never go to microservices from that monolith, they just keep adding features to it and deal (well, try to cope) with it being increasingly unwieldy and hard to manage.
Also never forget how they constantly sunset microservices in order to make everyone scramble to refactor into the new (more expensive of course) microservice under a different name... ugh...
You could always replace it with a modular monolith in stead of microservices.
If it's been developed as a singleton application (all features always registered/enabled on startup, only one instance ever running), even that might prove to be quite hard. No idea what else to call a monolith that could never run as more than one instance at the same time.
You might have to go through dozens of files and sprinkle feature flags throughout to enable/disable certain modules and making any organizational changes to a codebase over a million lines of code is difficult. Plus, when you have 1000 API endpoints that's generally treated as just "the API", then splitting that up in meaningful ways might present challenges. Aside from that, even if you can cut down on what needs to be enabled for certain development scenarios, you are still compiling the whole monolith, so locally you're saving on some runtime resource usage at best and will still sit around when you make any changes that need you to relaunch the monolith.
In general, I agree. I'd even build new systems as modular monoliths first. Except when it comes to large systems of any kind, even just updating the dependencies might sometimes be impossible (in a reasonable timeframe).
> even just updating the dependencies might sometimes be impossible (in a reasonable timeframe).
Consider the situation where you have a proliferation of micro-services all using a similar but slightly divergent stack, and you're notified of a security issue that means you need to update the same library across the entire fleet of services. I know what situation I'd prefer to deal with.
I use Drupal... Although they issue way too many security & functional updates each year, it's been conveniently 100x less expensive to maintain than microservice architecture apps, and it's open source/PHP as a bonus.