Op-Ed: Why DevOps Needs To Embrace the Database
Agile. DevOps. Continuous delivery. If you have anything to do with IT, you’ve heard those words more than a few times and have probably used them yourself. Even though only a handful of organizations have successfully adopted and implemented all these methods, Agile, DevOps, and continuous delivery will continue to drive IT strategy. Gartner predicts the majority of application development will use Agile methodologies by 2018.
And with good reason.
The demands of the digital world have applied immense pressure on development teams to build, stage, and roll out applications faster than even a few years ago. These recently-introduced methodologies promise to make that happen.
With that level of innovation and automation, development teams are releasing applications at a pace that finally satisfies business leaders. They are producing more and having a greater impact on the business. In addition, IT has seen rapid innovation at the systems level, including virtualization and cloud, that shrinks the data center. Well-deserved high-fives and pats on backs all around! This innovation is making heroes out of formerly battered IT teams.
But Not So Fast
IT has a long history of operating in silos. DevOps collaboration eliminates barriers and creates a peaceful environment of mutual goals and seamless operation for all involved with the application delivery process…until we reach the last mile. Look a little closer and the last 10 percent of the development-to-delivery process takes 90 percent of the time and resources. Why is that?
We forgot the database.
Throughout time, whether the development team is using build and fix, waterfall, Agile or any other process model, the last mile is always on the shoulders of the DBA, who is tasked with implementing, recording, testing and managing the changes to the database. Nothing can happen without this final leg, yet the benefits and acceleration provided by automation stop short of the database. Applications are cranking out at record speeds, but DBA teams are not equipped to handle the massive increase in volume at the pace set by their dev team counterparts.
When IT decisions are made to accelerate the release process, DBAs are met with benign neglect or, sometimes, outright hostility. Development does not understand the importance of the DBA nor the difficulty of their roles. For example, we hear complaints from development about DBAs who won’t allow a column with a default value added to an existing table.
Robert Reeves
Development sees no issue with this but the DBA knows that the production table has over one million rows. That change would result in locking the table as each row of data is inspected and the new default value is being updated. The larger the row count, the longer the lock. There is good reason to not allow the change, as it would destroy the application SLA and blow out the maintenance window. DBAs are performing a needed service and should be recognized for that.
Something else often forgotten outside the margins of the DBA team is that updating and deploying the database changes required for every application release is a manual, error-prone, arduous process. With all the new innovation, technology and methods that enable IT to move at the speed of the digital enterprise, DBAs are being asked to keep up using the same old methods. The life of a DBA has become a constant state of barely treading water if staying above it at all.
As the pressure mounts, DBAs risk deploying changes that perpetuate the cardinal sin of application release – breaking the application. When erroneous database changes are not detected, the application(s) can go down and cause an unenviable ripple effect. DBAs have to track down and remedy the change, developers are annoyed that they have to go back and fix their app, C-level execs are likely livid that the business is losing money, and end users are thrown into a tailspin when they can’t access the apps they rely on.
Automating the Last Mile
Right now, companies throw more people and resources at the database bottleneck, but the continued increase in application release volumes and speeds means this is at best a stop-gap and not a real solution. Brooks’ law tells us this is foolish. Remember: Nine women can’t make a baby in one month.
So what kind of innovation can help the database immediately? Logically, we must apply the same principles that have fueled the development process to the way databases are managed. Discussions are happening across the industry around extending Agile workflows to infrastructure, security and even marketing; there’s no reason that DBAs should be left out in the cold. Perhaps the most important aspects of Agile are continuous improvement and rapid response to change, which align rather nicely with DBAs’ main goals.
At Datical, our engineers have developed Agile Database Automation, a set of technologies based on the same principles behind Liquibase, the popular open source database-independent library for tracking, managing and applying database schema change. Datical DB accelerates release cycles by making database deployments as agile as the application.
By welcoming the DBA into the DevOps organization and automating the last mile with an agile database solution, IT leaders can amplify current staff and tools, deliver applications faster, reduce downtime, enforce compliance and provide visibility of database environments across the
Let’s give the historically overlooked DBA a long overdue welcome to the club.
Feature Image via Pixabay.