You should have a well curated DB regardless of whether one or many domain specific services sit in front of it. That is what would enable you to break a monolith up. Good code and architecture is the result of discipline. Your data is your most valuable asset. What you're describing is a mess.
You mentioned RPC's. Your service interface has nothing to do with the data organization.
But if you think microservices is what would work for you, then you should pursue that next time. My original post was a path to a multiple service architecture that approached service expansion with technical rhyme and reason. It really wasn't aimed at your organizations messy database.
> You mentioned RPC's. Your service interface has nothing to do with the data organization.
I find data organization to be a direct consequence of service interface. If two things aren't talking over RPCs or pubsub, they're talking through the database. It's not just my org. Pretty common for monoliths to end up with an obscene reliance on a single DB and start looking for a huge machine to support it.
There isn't a clear definition of what a separate "service" is, but I think it's fair to say that separate services won't have identical consistent views of the same DB. They'll be more independent than that, each with authority only over its own data, and use each other's data in an eventually-consistent manner through a well-abstracted API. And that does bring some overhead.
> I find data organization to be a direct consequence of service interface.
Then, you will not like microservices. Microservices make it harder, not easier, to organize data.
You have to worry about problems such as eventual consistency, and figure out how to join data across multiple data sources.
It compounds the problem significantly, and the only thing it gives you is that it forces you to silo data. That can be a good thing, but it doesn't solve the data organization problem.
Usually the service structure will mirror the team structure, e.g. one team of 2-6 SWEs per service. I've enjoyed doing things this way now that we're out of the monolith.
BTW, monolith DB has its own form of eventual consistency. Process A puts data into DB, process B picks it up later and affects the DB. There's no reasonable way that everything in such a multi-use DB is always logically in agreement. You're just guaranteeing that B sees what A writes immediately, which comes at a cost.
> the only thing it gives you is that it forces you to silo data
It gives you a smaller blast radius when something goes wrong, avoids over-stressing a single DB, alleviates single points of human dependency like the DB curator, lets you scale separate pieces independently, and yes forces you to silo the data. There are several good reasons larger orgs have been doing things this way for a long time.
Sure, but likely that team is not working on a single service when people say microservices. That could be SOA, which is more my preference, but definitely not a microservice going by the most popular definition which is "small enough to rewrite."
> BTW, monolith DB has its own form of eventual consistency.
Sure, on very large systems. Microservices always have this - even tiny systems.
> It gives you a smaller blast radius when something goes wrong,
At the cost of often having a much harder time fixing things when they do go wrong :)
> avoids over-stressing a single DB,
Monoliths can use as many databases as they want! And you can use a single DB with a microservice architecture across many microservices (tho I think this is an anti-pattern, teams often do it).
> alleviates single points of human dependency like the DB curator,
I haven't been at a job that has a DB curator, but it compounds the "bob wrote those ten services in rust, who... who knows rust? anyone?" issues :)
> lets you scale separate pieces independently,
You can do this with a monolith with many technologies, though seems easier to do for a microservice as a general rule. But, you have to need that scale first!
> and yes forces you to silo the data. There are several good reasons larger orgs have been doing things this way for a long time.
> BTW, monolith DB has its own form of eventual consistency. Process A puts data into DB, process B picks it up later and affects the DB. There's no reasonable way that everything in such a multi-use DB is always logically in agreement. You're just guaranteeing that B sees what A writes immediately, which comes at a cost
Transactions have existed for years, and DB execution engines have been able to concurrently handle non-dependent transactions since the mid 90's.
> It gives you a smaller blast radius when something goes wrong, avoids over-stressing a single DB, alleviates single points of human dependency like the DB curator, lets you scale separate pieces independently, and yes forces you to silo the data. There are several good reasons larger orgs have been doing things this way for a long time.
Vertical scaling of Db's is a non issue. If your DB is complex, get a DBA...
Have you actually done any of this in production before? It doesn't seem like it honestly.
You mentioned RPC's. Your service interface has nothing to do with the data organization.
But if you think microservices is what would work for you, then you should pursue that next time. My original post was a path to a multiple service architecture that approached service expansion with technical rhyme and reason. It really wasn't aimed at your organizations messy database.