November 12, 2021 at 12:00 am
Comments posted to this topic are about the item Is the Database a Series of Microservices?
November 12, 2021 at 9:55 am
Interesting analogy here. And quite on point. Thanks so much, Steve.
On microservices, some points of view are that traditional RDBMSes do not quite fit into the design pattern. That each microservice should write data to its own "micro store", typically a NoSQL database. What are your thoughts on this?
Br. Kenneth Igiri
https://kennethigiri.com
All nations come to my light, all kings to the brightness of my rising
November 12, 2021 at 12:37 pm
Nicely put. Thanks, Steve for the analysis and analogy.
Richard
November 12, 2021 at 1:56 pm
I like your analogy. Well done.
Rod
November 12, 2021 at 2:12 pm
Love it! Thanks for helping me conceive of databases in a whole new way.
The three biggest mistakes in life...thinking that power = freedom, sex = love, and data = information.
November 12, 2021 at 6:19 pm
Except that, unlike microservices, and I'm thinking specifically about web services here, database objects are tightly coupled by things like dependencies and foreign keys. Also database deployment may involve altering the objects with existing data in place with the additional requirements of transactional consistency. RDMS platforms don't make it easy; there is no concept of an "XCOPY deployment".
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 12, 2021 at 6:24 pm
Eric,
Are you saying that any database object is always going to be tightly coupled with other objects? That a table or a stored procedure or even a function can not exist without anything else supporting or linked to it? Now I'm confused.
Richard
Just learning about databases and Sql Server since 1998.
November 12, 2021 at 6:35 pm
Glad you like the analogy. It's not perfect, but neither are microservices. I think it fits, and it helps to explain to dev teams the challenges of database development and coordinating their efforts.
For Ken:
I think there are problem domains where this works. Using separate data stores allows for scalability and it can work well when the data is disparate.
Where I think this fails is that in a lot of common applications, we want to use this data together. We need to relate customer data with shipping data, or something else. If we do this as singletons, i.e., I look up my order(s), this can work well with separate data stores. If I need to do this at any scale, like all orders for a store or a region, the microservices traffic can be problematic. It's also highly inefficient. It's row-by-row work.
What many places need that use microservices with separate data stores is strong ETL work to get the data from these stores into a warehouse of some sort. Spotify does this. Their data moves quickly into warehouses, because the problem domain supports microservices for the most part (we all listen individually in our accounts), but for lots of the add-ons, the mixes, the reporting, they need to have a way to consolidate data.
It's not good or bad, but something you need to consider.
November 15, 2021 at 2:13 pm
Eric,
Are you saying that any database object is always going to be tightly coupled with other objects? That a table or a stored procedure or even a function can not exist without anything else supporting or linked to it? Now I'm confused.
Always? No.
Sure you can create a database consisting of tables that are not related to other tables, or tables that never contain existing data, or create stored procedures that don't reference other database objects. That would make your database deployments a lot easier - but it would also make the database useless.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply