Monday, October 23, 2017

The Tractor Beam of the Database in an API World

DZone Database Zone
The Tractor Beam of the Database in an API World
The Tractor Beam of the Database in an API World

I’m an old database person. I’ve been working with databases since my first job in 1987. Cobol. FoxPro. SQL Server. MySQL. I have had a production database in my charge accessible via the web since 1998. I understand how databases are the center of gravity when it comes to data — it's something that hasn’t changed in an API-driven world. This is something that will make microservices in a containerized landscape much harder than some developers will want to admit. The tractor beam of the database will not give up control to data so easily — either because of technical limitations, business constraints, or political gravity.

Databases are all about storage and access to data. And APIs are about access to data. They're about storage, and the control that surrounds it is what creates the tractor beam. Most of the reasons for control over the storage of data are not looking to do harm. Security. Privacy. Value. Quality. Availability. There are many reasons stewards of data want to control who can access data, and what they can do with it. However, once control over data is established, I find it often morphs and evolves in many ways, that it can eventually become harmful to meaningful and beneficial access to data — which is usually the goal behind doing APIs, but is often seen as a threat to the mission of data stewards, and results in a tractor beam that API-related projects will find themselves caught up in and find difficult to ever break free of.

No comments:

Fun With SQL: Functions in Postgres

DZone Database Zone Fun With SQL: Functions in Postgres In our previous  Fun with SQL  post on the  Citus Data  blog, we covered w...