You are viewing...

Terrible Ideas #1: Database Model as a Service

Updated on September 09, 2019 at the 17th hour
Posted under:

DISCLAIMER: All views are considered my own and you should not draw any conclusions on associates.

Had a go thinking about abstracting database access into a service and the question I have is why? Why bother abstracting this access? What benefit does one get when abstracting the database away from an application? Let's have a go at it shall we?

Imagine starting with a monolithic application that accesses a few databases and their tables. Life is great and everytime you update version x to version x+1, you update that application to support both version until fully migrated. Lets say you start hiring people and splitting responsibilities into accounting, market and product. Each needs database access and have their own applications to access said database. Accounting and marketing are gonna execute SQL queries to get data while product will have common access patterns with some cases where they need to analyze data.

Product says we wanna move to SOA, so they can move more flexibly. They start splitting up the monolith into services to handle some business cases in a more agile manner. Seeing progress on this front not being satisfying, Product now wants microservices since smaller === more agile, but at the same time Product says let's globalize our common access patterns to all databases by standing up a bunch of microservices that will only do CRUD to databases. Now microservices won't even need database libraries, they just need clients to talk to the DB CRUD service! How exciting that most of the time spent on it was thinking about how to do it, wait for resources and then create it and figure out how to migrate users then try to migrate users! Just include the client and start using it! Hey, you get metrics on database access and everything!

How does accounting or marketing benefit from this? Less data corruption? Oh, we'll just give them snapshots of the database that they can perform queries on. Mind you that database backups add latency to production. Why are we doing large database backups again? Oh right, our database isn't mirrored appropriately or it would be too expensive to use existing replication architectures. Oh, ok.

Remember that case of going from v1 to v2. How do we do that now? Yes, we modify the database, modify the service then modify every other service that uses the client then modify the business logic that needs to use the new data. We are using GRPC where deletion is not supported, so now we carry extra "deprecated" data every time we use the client. Insanity.

Just insane. All of this is crap. Dumpster fire. Maintenance free, zero cost etc. All snake oil bullshit. There is no such thing as easy, zero cost service. Databases are gonna get upgraded, hard drives are gonna fail, network partitions are going to happen, databases are gonna have bugs, etc. Database Model as a Service just because a few people cannot auto generate a model and connect to the database which is a "service". Moreover database access using stored procedures means that the database provides CRUD RPC functions already, but hey let's throw up a service in front to do exactly the same thing. Telemetry, are you kidding? There is one service that is responsible for touching the database/table anyway. No telemetry there, so let's shunt telemetry onto the DB X Model Service. Once something is made a service and client publish, it is now public domain. Everyone can touch the database directly now. Oh, but you still need to give user/password. Omg. 😅

Your Accounts, Products, Cards or etc. service is the source of truth for every other service that wants to know what the hell an acoount or card is for an "id." That service is responsible for providing the Domain Object model to other services who want to know. How that model is hydrated is up to that service alone.

Use the fucking database. It is a "service." I cannot and will not contribute to such shit just because a few people think it is a good way to move in. I would fire the hell out of people for bringing this kind of nonsense up. It has no real benefit to anyone and if your developers do not know how to use a database library or need some abstraction for database, it is time to consider hiring competent people for a change.

Gonna have to make up a "Saga" for this kind of insanity.

You just read "Terrible Ideas #1: Database Model as a Service". Please share if you liked it!
You can read more recent posts here.