This article first appeared in the DataPlatformGeeks Magazine.
Author: Kathi Kellenberger .
Subscribe to get your copy.

Technology changes fast. Twenty years ago, I was a new DBA supporting SQL Server 6.5, 7, and 2000. Those were the days when SQL Servers ran on physical servers with 32-bit operating systems and minimal resources compared to servers today. Now SQL Server runs mostly in virtual machines, and there are many ways to run SQL Server from containers to in the cloud that I couldn’t begin to imagine back then.

Just as technology evolved, so did the responsibilities of database administrators as organizations found new and better ways to develop and deploy software. The Waterfall methodology of software development made way for Agile, which is more responsive to changing requirements and delivering results sooner. Nothing’s perfect, and eventually to solve problems with the Agile method, DevOps was born. DevOps doesn’t replace Agile, but it can improve its efficiency.

But what is DevOps? My favorite definition is

The union of people, process, and products to enable continuous delivery of value to our end users –Donovan Brown, Partner Program Manager, Azure Incubations at Microsoft

I like this definition because people, processes, and products (tools) are all equally important. The end goal is to deliver value quickly to the customer, but it that also means the business will be more successful and competitive. The goal is accomplished by:

• Removing technology silos. When each team is responsible for their own part and not the end goal, they might hoard knowledge that would be useful for the other teams and be more concerned with protecting their domain than making sure the customer gets value from the software. The use of cross-functional teams can improve communication and collaboration.

• Measuring the right things. Measuring something easy to measure, like lines of code, doesn’t tell you anything. The 2021 Accelerate State of DevOps Report looks at four crucial metrics: deployment frequency, lead time for changes, time to restore service, change failure rate.

• Automating everything. Experienced DBAs automate repetitive tasks to give them time for other responsibilities like performance tuning and important projects. DevOps takes automation to a whole new level, which might make DBAs who are not familiar with DevOps uncomfortable. DevOps means frequent, small deployments. According to Accelerate, the Elite DevOps performers make deployments multiple times per day instead of deploying large amounts of code infrequently. When developers commit code, an automated build process integrates (continuous integration) the code with that of other developers. Unit testing, quality assurance, and other checks are performed to find errors early in the pipeline, and only fully tested code makes it to production. Even the creation of the downstream environments for these stages is automated, including containerized database servers.

• Making a broad cultural change. Changing the culture is probably the most challenging aspect of DevOps, because it requires a new way of thinking. The “blame game” culture prevalent in many IT shops discourages experimentation which stifles innovation. How different roles are compensated can also play a part. DBAs and other operations folks are incentivized to keep systems stable, which means resisting releases while developers are judged by release frequency and may care less about stability. All teams should share responsibility for stability and release tempo to meet the end goal.

Deploying frequent application changes is straightforward because it means replacing files and settings that can be rolled back if necessary. Database changes, however, are much more complex because it’s not just replacing files. Care must be taken when deploying schema changes to avoid data loss. Fortunately, tools specifically for database DevOps are available that fully integrate with the tools used for application code to avoid the database becoming a bottleneck.

The State of Database DevOps 2021 Report showed that there are challenges to bringing the database to DevOps. However, the organizations that do are seeing many benefits, including increasing the speed of delivery of database changes, freeing up developers’ time for more added value work, and minimizing application downtime.

Since so much is automated, DBAs may be concerned that they won’t be needed in DevOps organizations, but database expertise is still needed. In addition to typical responsibilities such as HA/DR, performance, and security, the DBA’s role in DevOps is to:

• Share best coding patterns for database changes
• Create checklists to avoid hidden pitfalls in automated releases
• Share expertise in automation for building and deploying database code
• Create practices for compliant database DevOps

When I’m asked what DBAs should be learning about now, I recommend:

• Version control systems, for example, Git, GitHub, Azure DevOps
• Scripting with Bash in addition to PowerShell because containerized SQL Server instances will run on Linux
• Speaking of containers, learn about running SQL Server in Docker
• Data masking, to protect sensitive data and comply with regulations like HIPAA and GDPR
• Cloud databases such as Amazon Web Services RDS and Azure SQL Database

There are tons of white papers and reports about DevOps, but my favorite way to get started is reading The Phoenix Project by Kim, Behr, and Stafford. The Phoenix Project is an entertaining fictional book about a company with a big overbudget, overdue and critical project that fails miserably. It shows how building trust between teams and adopting the three ways of DevOps based on manufacturing principles:

• Work must constantly flow from left to right in small batches without passing along defects.
• Feedback must constantly flow from right to left at all stages so that development stops in case tests fail.
• Creating a culture that encourages experimentation and taking risks to improve the system.

DevOps brings a world of opportunity for database administrators. Even if you are not working for a DevOps organization today, you may be soon.

This article first appeared in the DataPlatformGeeks Magazine.
Author: Kathi Kellenberger .
Subscribe to get your copy.