When you work in information technology long enough, you get to see how people react when something new comes along. Some people embrace change, even to the point of being an early adopter. Others might use a wait-and-see approach. And then there is the group of people who are afraid of change in any form.
A past example of change is virtualization, especially when it came to the virtualization of database servers. It took some effort, but today, the idea of a virtualized database server is the new normal, and physical servers are in the minority.
A current example of change is the cloud. And eventually the cloud discussion will be replaced by debates over containers, and then, likely, microservices. But we’re not there, yet.
Reasons We Fear the Cloud
In my experience, there are three main reasons why we fear a new technology:
- Fear of the unknown
- Fear of the loss of control
- Fear of becoming obsolete
The cloud is in our faces promising all three things at the same time! It’s a big unknown—a NULL in the sky promising to reduce administrative overhead and costs, and do more with less people. It’s no wonder there has been widespread panic when it comes to cloud technology.
Head in the Clouds
For the majority of the DBAs and data professionals in the world, our journey to the cloud will take a hybrid approach: you are not likely to lift and shift existing systems to Microsoft® Azure® or Amazon® Web Services (AWS®) overnight; instead, you are more likely to begin small, creating new applications in the cloud, while others remain on-premises. While, yes, this means that the scope and scale of the tasks you perform may increase, don’t let cloud fear get the best of you just yet.
I try to help others understand their fears by breaking them down into smaller bits that are more digestible. The three main points every DBA needs to understand when it comes to the cloud are as follows:
First, the hybrid IT world can be thought of as a borderless data center. However, the ease of use for public cloud services such as Azure and AWS means traditional data management methods may not provide the visibility and level of information you’re used to in order to deliver on end-users’ high expectations. Also, the traditional “nerd knobs” that we DBAs have relied on for our on-premises systems are not available in the cloud.
Second, despite this, the core responsibilities for today’s DBA, or what I have come to call the cloud DBA—data recovery, data security, and database performance—remain the same. While the integration of cloud services and distributed applications has introduced a greater level of complexity and potential challenges, the core missions remain the same: you must be able to recover data, protect data, and provide reliable performance.
That leads us to the third: it’s no longer enough for DBAs to be proficient in just database technology. The rate of change in the data center is accelerating. Data professionals must also change and adapt. The interconnected nature of the modern data center, coupled with the thousands of services technology vendors can provide, now requires us to deeply understand other technologies, including networking, VPNs, virtual networks, network topologies, and perhaps most importantly, how to troubleshoot network performance issues. For example, we now need to be able to first determine if a database performance problem is related to the network—whether one we own or the network of a cloud services provider—including when it’s a high level of data traffic that could be relieved by upgrading to a higher tier of cloud services.
Networking Skills for the DBA
Despite its growing relevance to the database, most DBAs have little to no experience with network administration, so it can be difficult to understand why such skills are necessary in the hybrid IT world.
Remember: we still have the same responsibilities in the cloud era, with data recovery being first and foremost. If an organization moves databases to the cloud, you must make sure you’ll be able to recover the company’s data, as well as access it when needed. The network, of course, is the primary conduit for doing just that. Thus, issues such as network bandwidth and latency become data recovery and accessibility issues.
When a database performance problem arises, make sure you’re prepared. This requires a proper understanding of network management practices and the right tools. You can start with a traffic analysis, looking at how much is SQL data traffic and how much the network bandwidth might be bogged down by YouTube™ enthusiasts, and then troubleshoot from there.
Furthermore, concerns about data security will always be present, so you need to also understand how users are accessing and consuming data. That requires you to have a broad knowledge of how data is handled in transmission, in addition to an idea of how all the systems are networked together and interconnected.
The best place to start is by making friends with your local network administrator. Ask questions, such as:
- What tools do you use to test and diagnose network performance?
- What tools do you use to notify you if there is a network issue?
- What steps do you take to fix common network issues?
Those questions and subsequent discussions will allow for you and the network team to open up the lines of communication, so you can work together to help ensure things such as recovery and performance.
If you’re like most DBAs, you’ve probably based your career around tuning workloads to run on spinning pieces of rust (i.e. traditional hard disk drives), and the idea of moving to something new—specifically the cloud—likely strikes at least a little fear in your heart. The key is to broaden your understanding and skill set, especially into the realm of network administration. Do you need to know every router and modem in your company’s network? Probably not. But to leave your fear behind and be successful in the hybrid IT era, you do need an understanding of the broader set of interconnected technologies that make up the modern data center, how data is getting from one point to another, and a baseline to help identify when performance is normal and when it’s not.