Comment by FLT8 | Hacker News Reader

Comment by FLT8 | Hacker News Reader

Parent Full thread

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.

exactly - refactor the monolith. What we do is refactor the monolith into microservices that we like to call "micro-monoliths". What you get is the agility of a microservice with the simplicity and lack of sync issues of a monolith. Monoliths are problematic because they are too large and unweildy; microservices are problematic because now you have 200 microservices to track and if one service node goes down it can trigger a cascading failure - we're talking complex distributed systems here. The solution is the micromonolith, a hybrid approach striking a balance between the two, best of both worlds.

> Monoliths are problematic because they are too large and unweildy;

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.

Reply on news.ycombinator.com