Hacker News Reader

Comment by Pamar | Hacker News Reader

From what I understand (never actually worked with MS, so no hands-on experience) a "proper" MS architecture will also include separate data persistence layers for each service.

I.e. if your service manages persisted data, it will access (and own) a dedicated storage instance which no other service has access to.

Assuming it is really true, folding a microservice back into a monolith should also mean that the data are ported back into the main DB? The article does not seem to spend much time discussing this, though. So maybe it is one of those ideas that everyone conveniently decides to ignore when they actually start dealing with a real world problem?

View on HN

Some services don't own any of their own data, so for them the question wouldn't arise. You could split them out without migrating data, and you could fold them in without it as well.

Otherwise, yes, moving a service out of a monolith without moving its data leaves you in a pretty tricky and problematic place, though the reverse is much less true: a single service having multiple data layers for different things isn't really a big operational or organizational problem.

> a single service having multiple data layers for different things isn't really a big operational or organizational problem.

Your statement is true, and I’d like to consider the product/feature side as well. Enterprise SAAS customers expect their Single Source of Truth to be, well, a single source. They want reports across all of the data they have put into a product. A feature that should be a couple of JOINs can quickly become pretty dicey when data is sliced across multiple data stores.

This is exactly what always made me very skeptical about microservices (as I said, no actual experience so I might just change my mind if I start using them) - for any non-trivial problem reasoning about your data in a integrated and coherent way seems pretty daunting.

For that reason people employ "data warehouse" systems and architectures. Microservices aren't complete without that complexity.

My problem with this approach is that my system basically handles a complex inventory and allows complex orders out if it, orders you can modify/update/cancel over a very long (months) period.

So we do have data warehouse for strategic analysis and planning, but we need to also manage complex data which has to be consistent and available 24/7.

You push the data from all the microservices to a single data warehouse and do the reporting from there - so all the aspects that modify the data are microservices, but the reporting is based on a data storage monolith.

One strategy is to use the strangle pattern where your new monolith just proxies the old service as you slowly or lazily migrate the data or re-implement the service.

You don't have to, in the short term. Just pull data from different databases.

You don't get the advantage of relational DBs though (ie, the relations, no JOIN for you) so you probably want to migrate at some point. It doesn't seem impossible though, write to both your micro-database and new tables of your main database for a while, then switch to the main database only when you're confident.

(Almost) Everything is "possible" - but looks pretty inefficient to do this. So are MS relevant/appropriate when you are trying to push stuff through the door at a very fast pace, but have to go back to something more "monolithic" sooner or later? Just like the article is suggesting?

Inefficient as in slow? Yes it is (slower than a JOIN, of course), this is explicitely a migration strategy to move from a MS architecture to a monolithic architecture. The alternative is a big-bang migration, which is a much bigger risk.

> So are MS relevant/appropriate when you are trying to push stuff through the door [...]

That really wasn't my argument, I was highlighting that it's possible to do a progressive migration from MS to monolith, I was not making an argument that one is "better" than the other.

To answer this question though: no. A MS architecture will probably give slower responses than the equivalent monolithic architecture (multiple DB lookups, inter-service comms), but that's just one element in the balance (and rarely the most important one, it's rarely important whether you get a response in 100ms or 200ms). I'm not going to go into "why microservices", there's plenty of litterature about it on the internet by people that know much more than me.

A decoupled monolith is _harder_ to achieve than decoupled services. Services are decoupled because they have to. It's perfectly normal to go from "ball of mud monolith" -> "decoupled services" -> "decoupled monolith". These transitions do not _need_ to happen either, they're just perfectly okay

Reply on news.ycombinator.com