I’m sure you’re familiar with the famous brand and its product line of toys. You’ve probably seen one of the recent movies – The Lego® Movie and The Lego® Batman Movie. You may have played with it yourself when you were a kid. I know I did.

I got fascinated with Lego® when I was in pre-school. I like the idea of putting together different interlocking pieces and blocks to create something – anything. Just like a painter working with a blank canvas to create a wonderful piece of art. Or the musician playing the instrument that produces a relaxing sound. Creativity at its best. The only limits are your imagination.

To create something from the Lego® pieces, you need to know what the piece does and what it doesn’t. If a piece cannot achieve what you had in mind, you grab another piece, try it out and see if fits your overall “design.” The Lego® toys currently available in the market are not as much fun as they were before. In the past, you were given generic pieces of the same size. You supply the creativity. Today, you are provided a packaged set with instructions on how to build something. You don’t have to design anything. You just need to follow instructions and build what somebody else already did.

What’s In The Packaged Set?

One comment I typically hear from SQL Server professionals who are given responsibilities to deploy resources on the cloud is that “it is very confusing.” And I get it. You have to deal with storage, compute and networking resources – all of which are outside the scope of a typical SQL Server DBA’s job responsibilities.  In a large enterprise environment, somebody takes care of the storage (the storage engineers), the compute (the server administrators) and the networking (the network engineers). The SQL Server DBA’s responsibility is mainly the database server – tuning queries, applying security patches, performing backups, etc.

But not so with the cloud.

Before you can even deploy a database on an Azure virtual machine (VM) running a SQL Server instance, you need to understand what the available Azure storage types are, the available Azure VM sizes, how Azure networking works and how SQL Server depends on all of these components.

The Storage Piece

As far as I can recall, a SQL Server database still requires some form of storage – be it on-premises, an Azure SQL Database or inside an Azure VM. A database backup also requires some form of storage. When you’re designing a SQL Server solution on Microsoft Azure, you need to know what the available storage options are and how you can use them with your overall solution. Just like that Lego® piece that you need.

Start with this: Introduction to Microsoft Azure Storage. Whether you’re stretching your SQL Server Availability Group to Azure for disaster recovery or using it simply to send your backups to an offsite location, you need to know what is available and what you can use them for. Hint: You’ll most likely be working initially with general-purpose storage on Azure. Between standard and premium, that’s for you to decide. Or should I say, that’s for your performance numbers and recovery objectives to decide.

The Compute Piece

This is just a fancy name that cloud providers came up with. But it is simply the server that runs your workload. The server has CPU, memory and local disk resources. In the good-old-days of physical machines, this could be an HPE DL 380 machine or a Lenovo X-series machine. In today’s world of virtualization, this could mean anything.

Start with this: Azure Virtual Machine series. You know your workload and your applications better than anyone else. Collect performance metrics, run tests, validate assumptions. For a hybrid SQL Server high availability and disaster recovery solution, you might be tempted to go cheap on the Azure VM size. Again, that’s for your performance numbers and recovery objectives to decide.

The Networking Piece

Despite the fact that I knew networking quite a bit, I still struggled with this when I was starting out with cloud computing. That’s because everything is abstracted. With on-premises networking, you can still unplug cables to check if the physical connection is damaged (I worked part-time doing structured cabling installations to partially pay for my last year in university). This is something you cannot do on the cloud. You “assume” that layers 1 and 2 of the OSI model will not have any issues because your cloud providers will take care of it. How you wished that plugging the server to the network is all you need to do.

I’m tempted to say “start with this: Azure virtual networks.” I realized that it doesn’t work. Unlike the storage and compute pieces, the networking piece is something most SQL Server DBAs rarely get the chance to explore. But I would say this: “grab your network administrators and ask them to explain the basics of TCP/IP networking to you.” You don’t need to be an expert on configuring supernets or defining routing tables. You just need to understand the basics and how to use them when designing your solutions on the cloud.

Putting Different Pieces Together

I’m sure you’re still telling yourself, “it’s still very confusing.” But before you get too overwhelmed with the available information, why not think about each of the components as pieces in a Lego® set. The pieces have already been created for you. Your business requirement paints the entire picture of what you need to build. Identify what type of storage that you need, choose the Azure VM size for your workload and get your network administrators to assist you in designing the virtual network for your solution.

Besides, I bet you enjoyed playing with Lego® at some point in your life.