Microservices Are Technical Debt
youtube.com
youtube.com
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.
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.
The idea that something could become less unwieldy or overall "smaller" by splitting it into separate codebases and introducing RPC and dealing with all the other complexities I mentioned above seems fanciful to me.
As far as I can tell the only semi-reasonable reason to want to move to micro-services is social -- effectively Conways law driven by Dunbar's number -- ie. you've scaled your organisation to a point where you have too many people to work effectively together and you need to split off into smaller teams, each with a subset of your total pool of developers, and want to be able to grant each team autonomy over their 'microservice'/domain to prevent death-by-committee.
I'd still argue most would be better off modularising/maintaining the monolith so multiple teams can work on it, but I do at least understand that rationale.
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.
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).
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.
That's a valid concern!
But surely there's a middle ground, maybe along the lines of: "okay, this is our main modular monolith codebase, but we'll make the decision to split this one vastly different type of workload in a separate service, since it adds 20 dependencies and we don't want to add that complexity in a codebase that's otherwise a fairly straightforwards RESTful API."
Yet, it's a bit odd, because people often talk about DDD and drawing domain boundaries, instead of "okay, so this group of functionality will need to export PDFs of bills and receipts, so we'll extract that and all of the related functionality because of technical considerations, whereas we don't care about adding 10 more API endpoints to our main codebase, because there's another 200 there already."
Instead, everyone seems to go "ohh, we'll have users in our system, so that's UserService (myproject-locksmith), we'll have orders in the system, so that's OrderService (myproject-bookkeeper), there's also bills so let's make BillService (myproject-scribe)" and so on.