Monolith -> Services: A Sketchy Approach

People hating their monoliths because of lazy tight coupling proceeding to create tightly coupled microservices that are even more of a headache is definitely something I've seen. Also seen them used as a bad escape valve for poor testing and deployment practices.

On the mark.

My favourite failure mode for this is throwing lot of effort into porting a chunk of the rancid old monolith into microservices without decoupling. This ends up with a stack of microservices that handle 1% of the total revenue generating traffic yet 80% of the infrastructure cost due to the additional complexity and adding 30% more overall latency due to the network hops and inflexibility of the service API. At the same time it doesn't deliver enough productivity doing this so there is gas being poured into the burning monolith too.

We have a monolith and it's great. It's also organized, which appears to be unusual.

Microservices have become a panacea for bad design. If your code is spaghetti, the microservices will be even worse.

Maintaining consistently is also way easier when different parts of the app share the same db context.

> What is that benefit? Micro-services aren’t the point.

This is a key point, if you can't articulate the benefit of migrating to micro-services, maybe you don't need it.

Micro-service is not a panacea, the architecture is intended to solve some practical but also very boring problems around scaling traffic and engineering teams.

An interesting thing I've read recently is that there can be different kinds of monolith:

- application monolith (what we usually talk about)

- database monolith (multiple apps all using one db)

- deployment monolith (multiple apps but need to be deployed together)

- organization monolith (multiple apps built by teams that have to follow the same processes and practices, or using the same technologies)

This made me think that migration to services has different layers and just running multiple apps might solve some problems, bet introduce others. I think learning how to slice things properly is the key here and is often only considered in terms of source code.

Kent Beck was one of the first software engineers I admired when getting into the field 7 years ago!

We are undergoing a mono->service shift at our company, and I think for reasons in agreement with this article. The main goals being to handle persistence of high write data beyond stable capabilities of our monolith, build services whose logic perspective deviates from the monolith (recommendations, text generation, search), and add new features that have a clear purpose and boundaries thought decoupled services.

But we still invest in the monolith, and develop all important things on it. It's our camel.

This is the conclusion I've come to on the monolith I work on. We're trying to extract some microsercives but the start of that effort hasn't yet bore fruit and the pace / cost is so slow I suspect it won't really be possible to actually fully carve out some of the stuff we are trying to.

To be fair, at least the initial stuff is stuff that would benefit from being carved out owing to it being integration code that should be independently deployable allowing for quicker turn around of issues with the integration and us being able to benefit from newer tech we want to use but can't.

The actual domain stuff we haven't been able to touch. Mostly because the data access is a veritable trashfire. It's a can that has been kicked 10 years down the road.

My thinking has basically shifted to pushing for us to carve out services for things our backend does that aren't in our core domain but are heavily trafficked, possibly because they're not well designed, and fundamentally affect the performance characteristics of our app. Carving them out is actually tractable, and we can probably reasonably get better perf/design and IMO would be a value add.

For our domain there is just no way we should even attempt to carve it up. We just need to tidy that sucker up until the domain operations are performant, and cleanly implemented.

If and only if we get there would it make sense to attempt carving out of the domain. But in reality we will probably live with a few non-domain related microservice, integration microservice, and our monoservice.

For a flip side to the dominant opinion here... we migrated to micro services. Then the PMs figured out a bunch of new products to ship by combining the micro services in different ways. Grew the business a lot.