4 ms·

And this organizational overhead is why I disagree with his setion about structuring your organization to fit microservices. I have seen first hand over horribl

by jeltz 2y ago

And this organizational overhead is why I disagree with his setion about structuring your organization to fit microservices. I have seen first hand over horrible it is when services do not share DBA resources for example. Every service has its own incorrectly and differently configured cloud PostgreSQL instance. Plus it bring really hard to innovate and create new features since many innovative features require you to touch multiple services and talk to a whole bunch of teams.

vrosas 2y ago
Somebody has never watched the whole company go down because some other team wrote a bad migration to the central db.
- sgarland 2y ago
  Which is a large reason why I don’t think dev teams should be managing DBs. It’s rare that anyone actually understands them, much less proper administration, configuration, tuning, etc. If you have no other choice because you’re a tiny startup, then fine, but at least show the DB the respect it deserves, and read its documentation. You wouldn’t (I hope) write and run code when you had no idea how it worked, or what the potential ramifications were, so don’t do it for the rest of your tools.
- jeltz 2y ago
  Yes, I have watched that happen both in microservices and monoliths.
sgarland 2y ago
This. It’s also more expensive. If one DB is multi-AZ, then all of them need to be, otherwise you’re giving up all reliability improvements. So now instead of a single beefy instance in multi-AZ with a few read replicas, every service has that. And as you correctly point out, the odds are low that there’s any semblance of a centralized configuration (nor that anyone knows what all the options for). So you wind up with 30 different DBs, all with different performance characteristics, and a ton of data duplication. Not to mention the observability nightmare. You want to trace something E2E? Have fun following all the traces and queries.

by jeltz 2y ago

vrosas 2y ago

Somebody has never watched the whole company go down because some other team wrote a bad migration to the central db.

sgarland 2y ago
Which is a large reason why I don’t think dev teams should be managing DBs. It’s rare that anyone actually understands them, much less proper administration, configuration, tuning, etc. If you have no other choice because you’re a tiny startup, then fine, but at least show the DB the respect it deserves, and read its documentation. You wouldn’t (I hope) write and run code when you had no idea how it worked, or what the potential ramifications were, so don’t do it for the rest of your tools.
jeltz 2y ago
Yes, I have watched that happen both in microservices and monoliths.

sgarland 2y ago

This. It’s also more expensive. If one DB is multi-AZ, then all of them need to be, otherwise you’re giving up all reliability improvements. So now instead of a single beefy instance in multi-AZ with a few read replicas, every service has that. And as you correctly point out, the odds are low that there’s any semblance of a centralized configuration (nor that anyone knows what all the options for). So you wind up with 30 different DBs, all with different performance characteristics, and a ton of data duplication. Not to mention the observability nightmare. You want to trace something E2E? Have fun following all the traces and queries.