The Data platform has evolved – so too must the DBA.

This blog post is around the changing landscape of both SQL Server and the people who are our trusted guardians of it – DBAs.

If you have been involved with SQL Server in the past 5 years, you will have seen some fantastic changes within the product. Where once we worked on SQL Server—we now work on a Data Platform. Microsoft has evolved the name of the SQL Server platform for very good reasons.

These days data exists both on-premises and in the cloud—data is being retrieved from Big Data running on Kubernetes clusters, it is being consumed by open source services that are interfacing with cognitive intelligent applications and data is being used with AI and Machine Learning models to provide predictive analytics. Our usage of data has also changed dramatically in the past 5 years, and with it, our administrative guardians of that data, the DBA, must also evolve with these changes

This article will help the reader who is trying to determine what they need to do to remain relevant—and more importantly—employable.

Embrace DevOps and Automation:

Automation will kill the DBA” this statement is wrong – automation will enhance the DBA. Deployments that were manual and disjointed can now be automated and by utilizing DevOps principles like Continuous Integration (storing the database model/code in source control and automating the building and testing of it) and Continuous Delivery (automating the repeatable, reliable release of that code through consistent environments).

There are open source (free) tools for automating a lot of manual database processes and tasks, for example https://dbatools.io which is a community-driven project helping DBAs work better. By automating a lot more it means DBAs will have more time to be proactive, to tune their systems more and to have time to upskill for the evolving platform that they manage.

Consider the Cloud as your next Server and Skillset:

Cloud-based computing has revolutionized industry and the same can be said around database management. No longer do DBAs need to be tethered to their infrastructure, looking at what security patches need to be applied or how to manage on-premises capacity constraints within their database ecosystem.

Cloud-based databases are shifting DBAs from hands-on guardians of databases to value-drivers for their businesses. I use the term value-drivers because cloud computing does cost money, where provisioned incorrectly it can cost a lot, and if DBAs have the skills to tune databases then that compute cost can be reduced.

The changes that the cloud brings are:

  • More higher quality deployments, less weekend work
  • More automation, less hands-on work
  • More data enrichment, less database maintenance
  • More growth in data, less resource constraints

The growing importance of cloud-based data and databases frees up DBAs from mundane, tasks, and provides more time to work directly with the business on ways data can be applied to market driven needs. The cloud also opens the door to DevOps; through the use of consistent tooling and automated processes, the work of DBAs, developers and operations teams are synchronized to deliver value at a velocity the business requires.

Lastly, by embracing the cloud and what it has to offer, DBAs have the greatest ability to advance and extend their career opportunities that they’ve had for the past 25 years.

Understand How The Platform is Evolving:

If we look at Big Data clusters—these are typically run on the Linux platform or on containers within a Kubernetes cluster. These clusters need to be provisioned and how they integrate together needs to be understood by all involved. What this means is DBAs need to become more general technologists. DBAs need to understand how SQL Server will run in a container, they need to look at how R, Python, Bash and PowerShell are languages they need to know in conjunction with T-SQL. The role of the DBA now encompasses more intelligent tooling that can manage and report on data infrastructure and processes across a wide variety of platform technologies. Hint: SQL Server doesn’t just run on windows server anymore…

Conclusion:

Data has never been more important to organizations, and no individual has a better understanding of how to manage and ultimately harvest that data than the DBA. However, with the evolution of the Data Platform to be more self-autonomous, DBAs will be under increased pressure to prove their value. Whether that is learning open source tools, big data clusters, cloud technologies, or performance monitoring processes, that is up to the DBA. The DBA has to evolve, like all professions that have with the introduction of cloud and automation, but the role itself is unlikely to ever disappear—the name could even evolve to become “Data Platform Engineer”.

If you are going to PASS Summit this November, then I feel the following sessions would greatly help you on your evolving career path within the Data Platform:

Journey to the Cloud: Planning the First Steps

Best Practices for Branching Database Code in Git

SQL Migration to Azure: Best Practices, Accelerators, and Production Case Studies

Should I Move My Production SQL Server Workloads to Containers?

How to Deploy SQL Server Containers on Kubernetes in Azure

Introducing SQL Server 2019 Big Data Clusters

This blog post is a reproduction of an article I wrote for PASS:

https://www.pass.org/PASSBlog/TabId/68281/ArtMID/99177/ArticleID/692/The-Data-platform-has-evolved-so-too-must-the-DBA.aspx

You’re keen about data and haven’t heard about PASS?

You should join it – it has a LOT of free resources and is free to join:

https://www.pass.org/

Joining revolutionised my career and life.

Yip.

 

Advertisement

Quick 6 month check – how are those learning goals going…?

So in January I wrote a blog post on some goals I had this year:

Some of my goals for 2019

It’s now July – how are things going?

I’m happy to say that I have indeed been doing a whole heap more on containers and have been using the Azure Kubernetes Service (AKS). Admittedly this has had to be in my own spare time as I have found that my clients are not ready to embrace either containers or AKS for SQL Server yet.

In fact a fair chunk of my clients need help getting SQL Server tuned optimally….

But in my spare time I have been folding AKS into CI/CD pipelines and looking at as much as I can.

In fact I am speaking about AKS in the following places:

Data Platform Summit:
https://www.dataplatformgeeks.com/dps2019/resources/DPS_2019_session_list.htm

SQLSaturday Perth:
https://www.sqlsaturday.com/894/Sessions/Schedule.aspx

PASS Summit:
https://www.pass.org/summit/2019/Learn/SessionDetails.aspx?sid=92753

(As a slight aside I am also speaking at Redgate SQL in the City Summit at PASS (https://www.pass.org/summit/2019/Learn/SessionDetails.aspx?sid=92888) – which is a life goal achieved!!)

So 6 months in – I’ve been doing a fair bit of what I had planned to do. Which after a fairly tumultuous start to the year is a pretty good start.

Yip.

 

“An installation package for the product Microsoft SQL Server 2012 Native Client cannot be found” – during SQL Server 2017 install

This blog post is about a situation that initially perplexed me – I was installing SQL Server 2017 onto a new DEMO machine – running Windows Server 2019. This install is one I have done over 50 times, if not more.

Halfway through I got an interesting error that (1) I’ve never seen before and (2) did not expect post SQL Server 2014.

MSI Error: 1706 An installation package for the product Microsoft SQL Server 2012 Native Client cannot be found. Try the installation again using a valid copy of the installation package ‘sqlncli.msi’.

And it then asked me to locate the install files for SQL Server 2012 Native Client.

I (obviously) could not find those as I had not installed it – so I downloaded the native Client off Microsoft’s website and then proceeded to get this error:

NativeClientError
If a later version is installed – why does the installer want me to install it…??!!

At which point I wondered what the heck was going on….

Until I remembered that unlike my normal setup I had installed Visual Studio 2019 on the VM first. So I looked in Programs and Features and lo and behold there was SQL Server Native Client:

Screen Shot 2019-07-20 at 11.14.04.png
Huh – I didn’t install that… oh wait – Visual Studio probably did!!

I also noticed SQL Server 2016 LocalDB which is installed by Visual Studio – which I made a note to upgrade to version 2017 as this can cause issues with things like the TRANSLATE function that was introduced in SQL Server 2017.

So I uninstalled SQL Server 2012 Native Client and reinstalled SQL Server 2017 Developer Edition and boom!! – it worked.

Yip.