The current trend for software development teams is to adopt a continuous delivery approach based on DevOps and agile development techniques. DevOps is relatively a new term, coined in 2009, defining software engineering practices that combine software development (Dev) and software operations (Ops). The general idea is not really all that new, but the adoption of agile techniques and modern tooling to automate software delivery is. The goal of DevOps is for developers and operations personnel to collaborate throughout the entire service lifecycle, from design through development and into production.
A DevOps approach results in small and frequent code changes that can significantly reduce the lead time for changes, lower the rate of failure, and reduce the meantime to recovery when errors are encountered. With such benefits that can accrue, it is no wonder that DevOps and continuous delivery are gaining in popularity. Today’s development organization migrates more frequent changes into production than ever before.
While all of this sounds like a good thing, and it can be, there are challenges. One of these challenges is when an application change also requires database changes. In most cases, database development lags behind application development in terms of continuous delivery.
Dev and Ops Require Equal Treatment
The problem, as I see it, is that many DevOps shops, emphasize the “Dev” over the “Ops” causing important operational aspects to be overshadowed by development concerns. And the “Ops” part is where you will find database management and administration.
Far too often, control of the application delivery process is driven by development, sometimes without the traditional control and oversight of the DBA group. Without the expertise of the DBA, the delivery and integration process can fall apart because the oversight and administration required for database performance and change management cannot be accomplished in the same exact way as applications.
A particular problematic perception is that the DBA acts as a barrier to progress. The developers work on their code, test it, and are ready to move forward, only to be barred by the DBA from doing so. So, developers view the DBA as a bottleneck.
But it important to understand that DBAs are not just stopping things for the fun-of-it. There is important work that the DBA must perform to ensure that the application can be turned over to production without causing problems. This includes:
- Reviewing SQL code and access paths for performance under production volume and workload.
- Ensure that everything is production-ready: this includes statistics collection, index analysis and design, join method analysis, system parameter analysis, and more.
- Reviewing database structure changes required to support the application.
- Building scripts to ensure a successful migration.
- Coordination of database changes with application changes.
- Ensuring that all support jobs (backup, recovery, reorg, etc.) are in place for every database object.
- Determine and mitigate any impact of the new application (or changes) on any other existing applications and databases.
When there is little, or no, communication between development and database administration until the code is ready to be delivered to production, it will take time to allow the DBA to perform their portion of the application delivery.
Of course, if the DBA and application teams communicate and coordinate their workload the perceived bottleneck can be eliminated. This is at the core of DevOps and is sometimes referred to as “shifting left.”
The shift-left ideology arose out of the application testing discipline. Software development typically progresses from Requirements to Design to Coding to Testing to Deployment and then to Support, which can be viewed as a chain, starting from the right and moving to the left:
Requirements – Design – Code – Testing – Deployment – Support
With a shift-left development mentality, processes on the right are moved to the left, so they are performed earlier in the development lifecycle. So, the goal with database administration should be to shift tasks to the left instead of performing them all right before Deployment. And to enable developers and DBAs to work together and communicate as team members with the same goal: servicing the customers and end-users.
More Impact of DevOps on DBA
Implementing a DevOps approach to application development and delivery is more than a technical challenge. Yes, there are technical requirements, typically focused on automating and orchestrating the application development pipeline. But these challenges pale in comparison to the cultural impact that DevOps imposes on an IT organization.
The first impact is a requirement for success, and that is improved communication. To thrive with DevOps means that your developers and operations folks must work together in teams and communicate frequently. In non-agile, pre-DevOps organizations such communication and teamwork are not common. So, an organization shift is required to get everyone buying into the “new way of doing things” at the executive, management, and implementor levels.
The second impact, dealing with the increased velocity of change, is an effect of doing DevOps correctly. With DevOps and agile development as the norm, focused teams conduct sprints, with shorter development cycles. This translates to faster development with more frequent code turnover. A 2017 report from DevOps Research and Assessment[1] concludes that organizations that have adopted a DevOps approach achieve up to 200x more frequent deployments, with high performers running 96x faster with 46% more code deployments than low performers. To put this velocity of development into perspective, consider that Informa Tech’s 2019 State of DevOps research report[2] cites the average time to move an application into production after it has been developed is a day or less at 29% of survey respondents.
Another consideration is the customer feedback loop that is faster with an agile, DevOps approach. Development teams can deliver improvements in smaller chunks more frequently, instead of waiting until the end of the project. When small, useable pieces of an application are deployed to the end-user, feedback that can impact future development will be returned, thereby impacting the next round of development. In other words, DevOps team members must be adaptable and nimble, and capable of embracing constant revisions.
Automation Required
As the continuous delivery model for applications gains momentum and acceptance, tighter integration between application and database administration is required. Integration and expertise are required both at a technology level and at a personnel level. DBA-level expertise is needed on development teams to help guide, implement, and oversee testing, performance management, and implementing changes appropriately.
Most DBAs are already overworked and are outnumbered by developers. To have any hope of succeeding with DevOps when databases are involved, software that intelligently automates the integration of the database aspect of application delivery is required. Without automation, manual oversight will slow down the rapid application delivery that is the hallmark of DevOps. Or worse, the oversight goes away, and performance problems and errors creep into your production code. And nobody wants that, do we?
In future blog posts in this series on DevOps and the database, we will further examine DevOps and SQL Quality and Performance, DevOps and Database Design and Change Management, and how Automation is Key to Effective Database DevOps. So stay tuned for future posts!
[1] 2017 State of DevOps Report, DevOps Research and Assessment, www.devops-research.com/research.html
[2] 2019 State of DevOps, informa tech, May 2019, interop.com
© 2020 Craig S. Mullins