Is the Database a Series of Microservices?

  • 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

  • Nicely put. Thanks, Steve for the analysis and analogy.

     

    Richard

  • I like your analogy. Well done.

    Rod

  • 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.

  • 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

  • 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.

  • 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.

  • rlDawson_SLC wrote:

    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 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply