Today cloud computing has matured and has clear demarcations between the different classes of service—platform, software, and infrastructure. Microsoft offers services in all three categories. But before we jump into them, let us first understand the nuances involved in cloud services. In this chapter, we will understand how Infrastructure as a Service (IaaS) works. Think of IaaS as a pizza where your favorite pizza vendor provides the frozen pizza and you need to manage the stuff that is used to warm and serve the pizza. In the IaaS world, this usually means that the vendor provides all the hardware, including the computing power, network, and storage along with its associated services. All you do is use the combination of the infrastructure offerings, which allows you to deploy any application or service on that platform.
Microsoft’s Azure platform is not just about hyper-scale abstraction of virtualization fundamentals. There is also a large amount of innovation that Azure drives in the form of its data centers. Let’s quickly look at how the hardware behind the concepts described here are laid out. The Microsoft cloud server specification essentially provides the blueprints for the data center servers Microsoft uses to deliver a diverse portfolio of cloud services. They offer dramatic improvements over traditional enterprise server designs: up to 40 percent server cost savings, 15 percent power efficiency gains, and 50 percent reduction in deployment and service times. Microsoft hosts its cloud services on owned and leased data centers across the world, which spans over a million servers and over hundred data centers.
There are some interesting strategic decisions that were made to get Azure to where it is today. The most interesting is the cost factor. Cost is always a discussion point in the IT world and Microsoft decided to reduce cost of hosting these environments by allocating against key cost drivers. This is fundamentally different from how the standard cost calculation works, which involves association of cost with the amount of space used. In contrast, Azure uses key factors like energy consumption, bandwidth consumption, incident response, and server capacity for determining cost.
In 2014, Microsoft contributed the Open Cloud Server design to the Open Compute Project, which allows the industry to benefit from the company’s experience in setting up data centers for the various cloud-based services that it managed.
In the next few sections, we will learn how compute, network, and storage is organized in Azure and the internals that you would need to know to make an IaaS offering work for you.
The Azure Services
Azure today offers a multitude of services in all three categories—PaaS , SaaS , and IaaS —and it keeps growing. The biggest challenge about writing a book on Azure is not whether the book will remain current after you have written it but whether it remains current while you are writing it. The world of sprints, shortened release cycles, and agile development methods ensures that the consumer of technology receives the technology content as quickly as possible.
Instead of naming the various services that Azure offers today, you will just learn about the different areas that Azure can help you and your business. In the recent times, Azure has increasingly sought to gain parity between what you are used to in the on-premises world and what you see in action in Azure. This means that the lines between your data centers and the Azure data centers are becoming increasingly fuzzy and a user of your platform will very rarely be able to gauge the difference between what is running on Azure and on-premise (unless you put a banner on their application that proclaimed its host data center).
Azure today offers services for:
Management and security like key value and operational insights
Developer services like Visual Studio Team Services
Identity and access management like Azure Active Directory, multifactor authentication
Hybrid integration like BizTalk, Site recovery
Media and CDN like media encoding, media indexer
Internet of Things (IoT), like Event Hub, Stream Analytics
Analytics like Data Lake, HDInsight, Machine Learning, Data Factory
Data and Storage like SQL Database, DocumentDB, SQL Data Warehouse
Web and mobile like Web Apps, API Management
As you see, Azure is more than just a bunch of hardware running your virtual machines. All of these solutions make use of certain parts of Azure’s compute, storage, and networking. In the next few chapters, we will delve deep into the internals of the Azure’s compute, storage, and networking, but in this chapter, we will understand how all of this is tied together.
The Compute
The compute in Azure is a combination of processing power and physical memory. When you start deploying compute in Azure, you are essentially spawning a virtual machine with an operating system backed by local storage that hosts the operating system files and a temporary storage. The local storage solution is not recommended for hosting your application or any data that your application might need. There might be situations where you use your ephemeral storage, which is referred to as the D drive. Examples are explained in later chapters.
Azure offers different tiers of compute that attract different sets of pricing (see Figure 2-1). The pricing is similar to your cellular minutes. You pay for every minute of usage. So if your virtual machine is up and running, you are paying for the compute power. Whether you are using the compute power or not is immaterial. Again similar to your cellular minutes. Your usage gets accounted for whether you talk or stay silent on the call. It is very important to understand what kind of physical memory and processing power you require to host your application or service.
Figure 2-1. Azure pricing calculator
The next question on your mind would be what can you host. Well it’s an empty house! You can literally host anything you want as you would on a virtual machine hosted in on-premise data center. The inherent advantage of using cloud-based infrastructure services is you have to click a button and the magic happens in the background. Spawning up the virtual machine, setting up the operating system, and tying the compute, network, and storage together is done by Azure infrastructure. Your job is to just provide the inputs!
Another advantage of hosting in the cloud is the packaged deployment offering, namely the gallery image. You can spawn up a virtual machine with software solutions preconfigured. Azure Virtual Machines support SQL Server, Oracle, IBM, SAP, and much more. The endearing aspect of such a one-click deployment is the license cost can be baked into it if you pick a solution-based image like SQL Server, Oracle, etc. If you don’t want to have the license cost baked into your per-minute cost for compute, then you can use your own license and use Azure’s automation offering to run your post virtual machine deployment steps.
Let’s now quickly understand about compute tiers that are available in Azure. For example, the Basic tier (A0, A1, A2 … An) consists of machines as small as 1 core and 0.75GB of RAM with 20GB local disk attached to it. You would pay approximately $13 if you left a virtual machine with this configuration running for an entire month. On the other end of the spectrum, you currently have the G-series machines which provide 32 virtual CPUs and 448GB of physical memory.
As you can see, there is a wide range that allows you to pick the right combination for your business.
The compute provides elasticity, which is what the cloud is famous for, by allowing you to scale out as per your load requirements. A scale out capability is not required when you are deploying SQL Server as a standalone SQL Server does not have scale out capabilities. There are features in SQL Server that allow you to scale out with the help of replication or availability groups. You can scale up and scale down your virtual machine instances as and when you need or even to your whims and fancies. While a whim and fancy might not be sufficient business reason, you can definitely use the trends from your compute baselines to scale up and scale down! Elasticity is becoming ubiquitous in the compute world today and public cloud makes that a reality. One of the most common scenarios for retailers is to match the holiday season traffic burst. This typically leads to over-provisioning of hardware throughout the year for a peak season that lasts less than a month at times. Elasticity in the cloud makes this a reality! Azure provides an auto-scaling feature that allows you to scale your workload running on web roles, worker roles, or virtual machines. Virtual machines are turned on or turned off from an availability set of previously created machines when you scale an application running on Azure IaaS. One of the options is to specify scaling based on the average percentage of CPU usage.
Some of the common conundrums in a hosted or on-premise data center are not really issues in Azure.
The Storage
In the previous section, you understood how Azure compute ties what we know as physical memory and processing power as a cohesive unit. This section explains what it means to store data in Azure. In the 1950s, the first hard drive stored five million six-bit characters, which today would not be sufficient to store that data housed in 4GB USB drive. The 3.75MB disk drive was approximately the size of two refrigerators and had a stack of 50 disks! Over the years, the world of digital data storage has seen improvements in leaps and bounds, and it allows you to store over 64GB of information in your mobile device. Today’s cell phones have in-built storage that can house over information which would have taken 17,000 disk drives from the 1950s era!
Due to the use of standardized commodity hardware for scaling out storage in cloud environments, the cost of storage is not a deal breaker anymore! There definitely is a time in every IT professional’s career when asking for additional storage space for their personal computing device or the servers that they managed was a well thought out business proposal. Today, the cloud provides abundance of storage at the click of a button in various forms, throughput, and cost factors.
Azure storage provides the storage foundation for all Azure Virtual Machines. It encompasses all the tenets of cloud, which means Azure storage is scalable, durable, and highly available. Once again, the advantage of cloud is that you pay for what you use and when you use it. It’s a like a pay-as-you-go cell phone subscription.
Azure Storage uses an auto-partitioning system that automatically load-balances your data based on traffic. As the demands for storage of your application grow, Azure Storage automatically allocates the appropriate storage resources to meet them.
Like any Azure component, Azure Storage is accessible from anywhere in the world. One unique aspect of Azure Storage is that any type of application, whether it’s running in the cloud or desktop or on-premises or mobile or tablet device, can access Azure Storage services. Advanced concepts and design decisions for Azure storage will be explained in detail in Chapter 3 of this book.
Now it is time to understand briefly how the storage in Microsoft’s Azure platform is organized. As shown in Figure 2-2, storage is organized in different formats—blobs, tables, queues, and files. Storage is organized in the form of containers, tables, queues, and shares. Think of each of these as the storage containers in your kitchen. You typically had different container with different attributes storing our cereals, flour, rice, etc. Similarly, the storage in Azure is segregated into containers of a particular type.
Figure 2-2. Azure storage concepts
Blob storageis essentially a binary representation of any storage object that you place in an Azure blob container. Each blob store can host documents, media files, executables, and basically any object that you want to store in the cloud. These are typically used to host raw data and media-related files like music, pictures, videos, etc.
Table storagecan be used to house structured datasets, which is a NoSQL key-attribute data store used for fast programmatic access to large quantities of data.
Queue storageprovides reliable messaging for workflow processing and for communication between components of cloud services. The messages could flow between any application endpoints. This could either applications hosted on the cloud or in our data center.
File storageoffers SMB-based file shares but the difference is that these are hosted on the cloud. These shared have a cloud-based path that any application can access as long as it is connected to the Internet.
Since the cloud hosts applications of various types, the throughput and performance requirements vary for each and every business. This is something that Azure storage provides in the form of Standard and Premium storage.
The main design goal of Azure Premium storage was to provide high performance, low latency disks for virtual machines that run I/O intensive workloads. Certain SQL Server workloads definitely benefit from the use of Azure Premium storage for its data disks. You will find multiple references in this book where SQL Server instances and premium storage accounts play along nicely for meeting and beating your performance and throughput SLAs.
If you wanted to put things in perspective, you get access to 64TB of storage per virtual machine, which can achieve 80,000 IOPS and 2000MB per second disk throughput per virtual machine. The introduction of premium storage allows you to lift-and-shift your enterprise applications that require consistent high performance and low latency for their IO requirements.
The Network
Before we dive into how the compute and the storage layer communicate with each other, it is important to understand the last and final cog in the hardware wheel of the Azure platform. The interservice communication and the external communication is handled by a network layer that, simply put, is a cloud version of a network that you lay out in an enterprise environment. Figure 2-3 illustrates a typical network configuration in an enterprise.
Figure 2-3. Network configuration of an on-premises environment
Azure Virtual Network is a representation of the all things networking in the Azure data centers. It compartmentalizes your IP address blocks, DNS settings, security policies, and route tables associated with your Azure subscription. Azure networking also allows you to stretch your on-premises network and make your Azure subscription objects are an extended part of the actual network.
If you want to draw parallels, you will notice in Figure 2-4 that the Azure infrastructure takes on the role of the router. It allows access from your virtual network to the public Internet without the need of any configuration. Think of the network security groups (NSGs) as firewalls that are applied to each individual subnet. The physical load balancers are substituted by Internet facing and internal load balancers in Azure.
Figure 2-4. Azure Virtual Network illustration
A very pertinent question at this point would be to question the need for a virtual network. The reasons are many. Apart from providing the connectivity layer for connecting between various Azure services and virtual machines, there is a need for isolation which allows you to create disjoint networks for various functions like development, testing, and production that use the same CIDR address blocks. Azure also provides internal name resolution for your virtual machines and PaaS role instances deployed in your virtual network (VNet) . You can also deploy your own DNS servers and configure the VNet to use them.
One of the interesting challenges of the modern day network administrator is to provide network connectivity to the outer world, a.k.a. the Internet, without compromising security. Azure networking makes public Internet connectivity possible without compromising on security with the help of network security groups (NSGs).
Let’s quickly understand what network security groups are and their role in the Azure networking architecture. If you had to draw an analogy, then the network security group (NSG) is basically a watchdog for the network traffic that originates between your Azure subscription objects and the internal as well as external client(s) that connect to these objects. You can create NSGs to control the inbound and outbound traffic to the networking components like network interfaces (NICs) , virtual machines, and subnets. You can use NSGs to decide whether or not network traffic is approved or denied based on source IP address and port or destination IP address or port. The NSG behavior is similar to firewalls in an enterprise environment.
Azure networking is covered in detail in Chapter 4.
How It Works Together
Now that you understand the basics of the building blocks available in Azure, it is important to understand how it all works together. If you had to look at an Infrastructure as a Service option in Azure, Figure 2-5 would show you how a virtual machine in Azure is laid out.
Figure 2-5. An Azure Virtual Machine
Figure 2-5 shows that Azure networking is the communication gateway between the external clients and the Azure Virtual Machines. One of the most interesting facts to note is that the storage layer is a completely separate physical entity. This is fundamentally different from how servers are structured in the data center. If someone wanted to draw a parallel, the storage layer could be envisioned as a marriage between a storage area network (SAN) and network attached storage (NAS) . The disk arrays are managed in a scalable and elastic manner by the storage layer, which communicates with the compute layer over a very fast network.
You can choose to deploy an Azure gallery image, which is a pre-cooked image available from Microsoft and other third parties, to host the operating system and pre-installed software of your choice. This way, you don’t have to write a single installer!
Infrastructure as a Service is just one of the service models that makes use of the compute, storage, and networking. In the on-premises world, a common deployment model is a web application, which consists of a three-tier architecture. The first tier is the client application, which is typically a web browser that connects to the middle tier, which is the application server. The application server connects to the backend server, which is typically a data store. A similar architecture can be achieved in Azure using web roles as the frontend, worker roles as the middle tier, and the data store (SQL server, blobs, NoSQL, etc.) as the third tier. Figure 2-6 illustrates a typical three-tier application architecture hosted on Azure.
Figure 2-6. An application service hosted on Azure
In Figure 2-6, the clients connect using Azure Virtual Network to a web role instance, which is a compute resource running the web application. Depending on the application’s need, the number of instances can be configured to scale up or down, which makes the service elastic out-of-the-box without having the developer to do anything specific. The storage comes into play depending on whether the application uses the Azure Storage entities for storing data like blobs or queues. An indirect use of the storage would be if a relational or non-relational Platform as a Service (PaaS) offering is used that internally makes use of the storage offering. Figure 2-6 shows the Azure SQL database as a storage option. This will be covered in detail later in this book.
Another deployment paradigm in Azure is to host application instances. These are not just limited to web applications but can be used on any kind of applications like mobile, services, APIs, etc. The Azure marketplace offers a plethora of pre-built service deployments from Microsoft and third parties. This allows you to spawn an application instance, which makes it a Software as a Service (SaaS) model for some deployments and Platform as a Service (PaaS) model for other deployments. Figure 2-7 shows how application deployments look.
Figure 2-7. Azure App instances
As you can see from the previous figures, Azure abstracts the deployment mechanics, decouples the hardware, and ties the various components together during deployment.
Update/Upgrade Domain
Now that you understand how the architecture is organized for the resource providers, it is imperative to understand the concept of update domains. Think of the update domainas a group of servers that you would patch in a maintenance schedule. If you are not the business owner, you need to ensure that the updates have little to no downtime for the applications hosted on the servers that are being patched. This is truly one of the most difficult IT problems in the real world.
Azure distributes instances evenly into multiple upgrade domains, with each upgrade domain acting as one logical unit of a deployment. When upgrading a deployment, the upgrade is carried out one upgrade domain at a time to minimize downtime for the services or applications running on these environments. Upgrade domains help reduce the impact of an upgrade to a running service and at the same time keep the environment up-to-date. This minimizes the risk of known issues affecting production environments due to lack of updates.
It is important to grasp this concept, as having an update domain alone will not help your SQL Server deployment. Even in a failover cluster or availability group environment, SQL Server instances can have only one active node where the service is running. So if the server running your SQL Server instance is rebooted, your database service will go down. It is important to have an Availability Group deployment for any production SQL Server environment hosted on Azure Virtual Machines to prevent extended downtimes.
Fault Domain
As noted earlier, the upgrade/update domain alone is not sufficient for maintaining the uptime of a SQL Server instance hosted on an Azure Virtual Machine. The scope of a single point of failure in Azure is essentially a fault domain .
The easiest way to draw a parallel with the on-premises world is to think of a failover cluster that prevents a single point of failure from a compute standpoint. Now extending this to the world of Azure, a single compute source connected to a power outlet is a fault domain. This could even be a rack in a data center since a power outage in a rack will take out multiple compute nodes from the infrastructure. The fault domain is determined by Azure during deployment and it is highly recommended to have two or more instances of each role deployed in Azure so that a single failure in a fault domain does not result in a service outage for your application. From a SQL Server hosted on an Azure Virtual Machine, it is always recommended to have a primary and secondary deployment from a high availability standpoint. This concept is followed in most enterprise environments and the need to do so in Azure remains. The SLAs are mentioned in the Azure service level agreements.
Deployment
One of the most common tasks when working with Azure is deployment. This used to be a one-way street until recently. Azure now has two deployment models: classic and resource manager. It is best to use the resource manager deployment model for any new development work as much as possible. All Azure resources support one or both deployment models.
There are some important considerations when working with virtual machines using these two deployment models:
Virtual machines deployed with the classic deployment model cannot be included in a virtual network deployed with Resource Manager.
Virtual machines deployed with the Resource Manager deployment model must be included in a virtual network.
Virtual machines deployed with the classic deployment model don’t have to be included in a virtual network.
Classic Deployment Model
Azure initially introduced a deployment model called the classic deployment model . For this section, we will be restricting the discussion of the deployment of virtual machines. In the classic way of doing things, a deployed virtual machine would be accessible only through a cloud service. The cloud service is a container for holding the virtual machines. The cloud service name had the format <name>.cloudapp.net.
Resource Manager Deployment Model
In the Resource Manager deployment model , cloud service is no longer an object required for creating a virtual machine (see Figure 2-8). The Azure Resource Manager enables you to easily leverage pre-built application templates or construct an application template to deploy and manage compute, network, and storage resources on Azure. The templates are available in the increasingly popular JSON format and are easily exported from an existing deployment and applied to a new deployment.
Figure 2-8. Azure resource providers and their relationships for an Azure Virtual Machine
Azure resource providers support the individual resources for creating functioning virtual machines in the configuration that you need. For virtual machines, there are three main resource providers:
Compute Resource Provider (CRP): Supports instances of virtual machines and optional availability sets.
Storage Resource Provider (SRP): Supports required storage accounts that store the VHDs for virtual machines, including their operating system and additional data disks.
Network Resource Provider (NRP): Supports required NICs, virtual machine IP addresses, and subnets within virtual networks and optional load balancers, load balancer IP addresses, and Network Security Groups.
We did discuss the fact that none of these resource providers can work in isolation, as hosting a simple virtual machine requires relationships between the resources in the resource providers. An example of this is that a virtual machine depends on a specific storage account defined in the SRP to store its disks in blob storage. A virtual machine references a specific NIC defined in the NRP and may also have an availability set defined in the CRP. A NIC references the virtual machine’s assigned IP address, the subnet of the virtual network for the virtual machine, and to a Network Security Group if gated access is required.
Resource Manager (ARM) makes is really simple to build, integrate, and collaborate on complicated applications that can include the entire gamut of Azure resources (such as web sites, SQL databases, virtual machines, and virtual networks) from a shareable template file. Such a shared template file can be used as repeatable deployments for setting up development environments with relative ease.
There is a deep integration of VM extensions (Custom Scripts, DSC, Chef, Puppet, etc.) with the Azure Resource Manager in a template file, which allows easy orchestration of in-VM setup configuration. ARM also allows simple and precise organizational resource access management using Azure Role-Based Access Control (RBAC) .
Deployment Automation
Now that we are talking about deployment, an obvious question is if there is a way to automate the actual deployment. Azure provides three different ways to manipulate the compute, storage, and networking objects. The first being the web user interface, which is expected as this is the company that made graphical user interface a commodity. The second and third methods are mainly for programmatically deploying whatever can be deployed using the web portal.
Azure exposes PowerShell cmdlets and REST APIs, which allow developers and IT administrators to write deployment routines. These routines automate the creation of the Azure entity and configure the post deployment configuration options exposed by the entity. The automation capabilities of Azure Automation service, when combined with these programmatic interfaces, are immensely powerful and allow customized workflows to be designed for deployment. A number of such examples can be found on GitHub.
Summary
In this chapter, you learned how Azure defines its compute, storage, and networking boundaries. While there is a layer of abstraction provided in Azure to make your deployment and daily operations easier, the parallels that you can draw with your on-premises environment are similar. This allows for a lower learning curve when migrating to Azure. Infrastructure as a Service has the highest similarity coefficient between your data center and Azure. The similarity wanes as you move from IaaS to PaaS to SaaS.