Caught this post about a presentation by Simon Sabin (@simon_sabin) talking about treating your databases and the integration with them like you would an API. It’s an apt comparison – and the ideas are really interesting in the post.
Of particular interest was the concept that, as you roll through updates and changes going forward, you can maintain some great compatibility if you think about the integration much like an API – specifically, keeping the connections up and going where possible by making sure legacy tools and connections are still supported. This can get challenging if you’re not managing to this goal.
One of the things that I’ve done before and was really jazzed to see, was the use of views and stored procedures to manage the interaction with the database – because you can often maintain these and hide changes to the database schema and functionality. It’s a great tool.
I think the whole thing of moving to treating your database management in a more devops way is critical to “doing it right.” The idea that you sort of set the database up so it works and then everything essential orbits around it, just doesn’t cut it.
When you start working to maintain those interfaces, you help extend the life of the current versions of your applications and tools. This is because they can float over top of the database version changes and you can manage things like updates, security and other things in a bit of a more abstract manner. You can see more about the approach in the linked post.
One of the things we’ve run into several times with this is that, over time, it can get pretty complex to maintain those views, stored procs and so-on. By putting those in place, you’re genuinely extending the lifetime of those interfaces, but like legacy code that you’re maintaining, you do end up with similar systems management issues.
You can end up with a whole array of things you’re building that are co-dependent on these custom interfaces – on the legacy APIs. It’s very important that you be a bit compulsive about documenting the things you put in place, and their known dependencies. If you have multiple layers of interfaces that you’re supporting (a view that references another view, or that relies on some other legacy supporting tool), it can get really difficult to move forward down the line.
Unless you’re in a position to re-code and work through any compatibility issues as releases arrive, you’ll simply *have* to support your legacy code, and this is a great way to go about that. Just keep in mind that you likely want to use it as a stepping stone to actual updates in a controlled manner. The last thing you want is this spaghetti-code type web of layers that you rely on to make things work.
Keep versions, but also keep documentation and notes. This is one of those “document your code” suggestions that can really save your sanity later on down the line.