6 ms·
Right. But you likely split the db for performance not just for decoupling data and code. Microservices is an option for scaling. My argument is more against it
by corethree 3y ago
Right. But you likely split the db for performance not just for decoupling data and code. Microservices is an option for scaling. My argument is more against it as a way to decouple and organize logic.
- hot_gril 3y agoPerformance wasn't the issue; mono DB was actually fast enough. Multiple teams' services sharing tables became effectively a fragile API between them with hidden dependencies. Small new business requirements were causing too many breaking changes, and the org relied too heavily on a few experts who understood it all. Plus, schema changes were behind a ton of red tape since they affected everyone. Also if by "decoupling data and code" you mean decoupling data from code, that's not the goal. It's to decouple one team's data from another team's data, and to properly abstract it. The only reason our mono-DB even lasted this long was because previously, very few requirements were changing over time. So when people say their big org is monolithic, I can believe it. It works in some scenarios, but probably not most.
- corethree 3y ago>you mean decoupling data from code, that's not the goal. It's to decouple one team's data from another team's data Use a schema bro. You can do this with two schemas. Think of it as folders in databases. Then give different permissions to users per schema.
- hot_gril 3y agoI know, but our DBMS doesn't support schemas. Instead, it's easy to spin up more "databases" that all share one instance but have separate ACLs, quota, backups, etc. Postgres has something similar but with less isolation. It doesn't really matter how exactly you slice it, point is you aren't sharing tables.