by Robert Reeves, CTO, Datical.
Quick. Draw the simplest diagram of your application architecture.
I bet it looks like three blocks, one on top of the other connected with two lines. Those boxes represent the web server, application server, and database server. This is important.
When we started to think about Application Release Automation (ARA) we wanted to speed moving the compiled code to a server. As applications have become more complex and interdependent, the term ARA has expanded to comprise many other tasks. As our deployments have changed, so should our concept, idea, definition of ARA. These new tasks include: (virtual/cloud) server provisioning, automated testing post release, network changes (putting servers in and out of load-balancer rotation), and database change.
Just like the rise of Agile led to the need for ARA (frequent releases begat frequent deployments), Application Release Automation tooling itself is now leading to the need for database change functionality. Dev was killing the Release Managers with releases. Now, the Release Managers are killing the DBA. It’s the last mile!!!
ARA Vendors are starting to get it, but are still woefully behind
Additions such as server provisioning, rolling updates, even the beginnings of canary deployments leveraging automated testing tools, have benefited a large number of users in customer installs. But, there is one area completely neglected: the database.
Of course, there is some messaging around database change management. IBM UrbanCode describe their Deploy tool as: “IBM UrbanCode Deploy orchestrates and automates the deployment of applications, middleware configurations and database changes into development, test and production environments.” Inedo BuildMaster does the same. When performing a demonstration, every ARA vendor will say they manage database change. But, look around the room and note the number of DBAs. It will be zero. The DBAs are not part of the DevOps Inner Circle. No one will perform a demo to the DBA team. Moreover, no one pushes to production using ARA tools today. As one Datical customer put it: “Using ARA to execute our SQL scripts helped us destroy the database much faster than if we had done it manually.”
Why did they neglect the Database?
Simply put: managing databases is hard. It’s even harder if you subscribe to a DDL/SQL only view of the world. But, SQL is a programming language. It can be parsed and broken down into an object. That’s why Datical DB is superior to just throwing in SQL scripts into ARA.
Also, DBAs have pushed back on development for so long (“Just let us write the SQL. Can’t trust you around the database.”). Imagine if system administrators acted the same way! “Just let me write the application code. Can’t trust you around the servers.” There are institutional habits (bad habits) that will take time to break. Luckily, the time is now as DBAs are now working later and longer hours.
Finally, DBAs don’t buy ARA tools. But, they are impacted by them. Shame on the ARA vendors for not including them in evaluations. Bet this problem would have been fixed a long time ago if that was the case.
What happens if you continue to ignore the Database?
Complete. Stand. Still.
There are only so many SQL scripts DBA can review manually, only so many they can execute manually. Thus, you must hire more DBAs. Insert data on how tough the labor market is right now for skilled DBAs. Can’t hire all those rust belt autoworkers to do this!
The other way you get a stand still is if you miss an error in SQL. You’re now down because you need to perform a full restore. Ugh! The time to modernize your database deployment practices is now.
What do you get when you bring the database into ARA?
Simply put, you get the full promise of ARA. See the recent Gartner ARA Magic Quadrant report to see the benefits of ARA. Of course, all of these benefits do not materialize until you have full stack automation, and that includes the database. But, once completed, you will have push button deployments that speed your entire organizations drive to a digital future.
To find out more about the evolution of application release automation, check out this white paper.