I’ve had many conversations at conferences where people have asked me about the role of the traditional DBA being phased out. When I ask why they think that’s the case, there’s a variety of answers:
“The introduction of the cloud will take care of everything for us.”
“The enhancements being made in automating SQL Server environments means we no longer need a DBA.”
“Self Service BI allows us to more quickly achieve our reporting requirements.”
Now I do agree that the introduction of all of these statements/concerns changes things, but they don’t eliminate the need for a DBA. At the same time, with the rate of change now being experienced, how can you as a DBA keep up? Which brings me to the point of this post: change and growth.
Change – If we’re not willing to change what we do and how we do it over the course of our career, do we have a career or are we like Ground Hog Day? Do, rinse, repeat.
Growth – In my opinion, an individual’s willingness to grow allows them to accept change, learn new things and approach things in different lights based on situations.
Your SQL Server database is more than just a storage bucket to hold your important data. Over the last couple of years, the amounts and types of data available is exploding and being able to keep up with ensuring the integrity, availability and performance of that data is hard, but simplifying database updates can be made easier.
We all know traditionally most database changes have to be undertaken out of hours so as to not impact the business. But what about the impact it has on staff? Late nights, weekends away from family and friends.
Secondly what most people don’t think about is the impact that humans make on implementations/deployments, because we’re prone to mistakes or inconsistencies. Case in point, a SQL Server build that relies on a fully manual process is not just time-consuming, but open to misinterpretation and inconsistencies with the builds that down the track can have issues bubble up to the surface over time.
An automated solution of pre-configured builds provide a consistent and reliable solution each and every time, and you can ensure the outcome is as required. By automating the build process, does that mean you’re doing yourself out of a job? No, in fact you’re able to spend more time on things that are more beneficial to the business, and you can sleep well at night knowing all of the builds are consistent.
Welcome to database DevOps
SQL Masters Consulting, a traditional database management consultancy, is now incorporating database DevOps to assist clients with trying to keep pace with the ever-increasing velocity of change.
This isn’t in any way an indication that the role of a DBA is no longer necessary. Encompassing database DevOps allows for DBAs to focus more on the requirements of the business, rather than the time-consuming activities that instead, with database DevOps, become a consistent, repeatable and reliable continuous delivery of change to the database.
Over the past 20 years, the concept of database DevOps has always been around, but the ability to automate tasks hasn’t been as simple for the database as it has been for application development. Database DevOps tools have now emerged, however, and the benefits of including DevOps for the database are being realized by many organizations to achieve greater operational efficiency.
Database DevOps utilizes the same principles that have already been widely accepted in application development:
The storing of all database code, from initial schema creation scripts to each iterative modification, allows for a known good state of a database in a particular environment at a particular point in time. This enable many database developers and DBAs to be confident in the state of play of what is happening in the database environment.
All changes that are being created and deployed require tests to verify the change being made meets the requirements and doesn’t break or cause issues to the deployed environment. Tests should not be an afterthought of a change, and should drive the change based on the particular requirements.
The process of being able to deploy small changes using the same process over and over again, means the same outcome can be achieved reliably and confidently.
The process of taking being able to apply a change through the various environments, utilizing unit tests and culminating in being deployed to production is, with database DevOps, largely automated. Importantly, with the process in place, ‘hot fixes’ are no longer made to the Production environment, avoiding unexpected problems in the future.
After seeing the efficiencies of practicing database DevOps, I’ve become an advocate and I do believe that embracing it can bolster and improve your ability as a DBA. You’ll be able to keep pace with the rate of change and not get bogged down in time consuming activities, and provide greater benefits for your employer.
|If you need help with, or training for,
your SQL Server data platform, get in touch
|Discover more about applying DevOps processes to the database on the Redgate solutions page|
Was this article helpful?