The Azure Dictionary of Pain: Five Of Azure’s Toughest Cloud Topics

Attention! Class is now in session. Please fasten your seatbelts and ensure your tray tables are upright and closed.

Azure is one of the fastest-growing cloud platforms, especially as companies start to shift to a multi-cloud strategy. But like AWS (and Google Cloud), there’s a near endless number of individual services that come with it—and a whole dictionary to describe them. Beyond knowing how they actually work, you have to know they’re called and what they do in the first place.

At ACG, we want to teach the world to cloud. And that means making sure everyone on your team can “speak cloud” in the first place—and understanding some of the basic challenges you’ll face when implementing cloud tools. We’re here to help you achieve that baseline cloud fluency with your team. To do that, we’ve built a cloud dictionary of some of the most challenging topics you’ll run into it. Given the difficulty here, we’ve decided to name this the Cloud Dictionary of Pain.

Get the full Cloud Dictionary of Pain
Speaking cloud doesn’t have to be hard. In our cloud guide, you’ll find the full list of succinct definitions to some of the most painful cloud concepts.

We analyzed 2.7 million responses to thousands of quiz questions on our platforms to identify some of the most challenging cloud infrastructure topics. We looked for questions where learners fell below a 60% success rate and, based on the topics in those questions, have outlined more than a dozen challenging topics that learners can, at times, struggle to decrypt—at least in some specific scenarios.

Today we’ll be covering five of the most challenging topics we identified for Azure infrastructure: Cosmos DB, Traffic Manager, Azure Functions, Snapshots, and Virtual Private Networks. This list is a subset of dozens of terms and topics we attacked across all three major cloud platforms: AWS, Microsoft Azure, and Google Cloud. You can find our complete walkthrough to Amazon’s thorny topics in the full Cloud Dictionary of Pain. 

With all that out of the way, let’s get started!

Cosmos DB is a system that tries to synchronize data all across the globe instead of for specific regions. This kind of global synchronization is super essential for global applications that need to be highly responsive, have a lot of continuously changing data, and are always available to users. Facebook is a good example—people use it worldwide and are constantly changing the data. Applications will essentially think CosmosDB is in their region, while Cosmos DB is handling replication across all regions to ensure it’s a continuous global database. Cosmos DB automatically partitions data to optimize performance and storage capacity. CosmosDB is also accessible through multiple APIs, such as Document DB (for SQL), MongoDB (for NoSQL), Graph API (for Gremlin), and Tables API (for key/value pairs). 

With all that replication happening across regions, there’s bound to be some variations in quality. You’re choosing between performance and consistency when picking a consistency level. Cosmos DB calls these consistency levels, which come in five categories: 

• STRONG: A guaranteed write operation committed and visible on a primary Cosmos DB after being committed and confirmed on all replicas. Strong consistency is the most predictable and intuitive. 
• BOUNDED STALENESS: The most frequently chosen, Bounded Staleness, allows you to figure how stale docs can be used. It decides how far behind a document can be before it needs to be updated.
• SESSION: Ensures all read/write operations are consistent within a current user session. In a user session, for example, Facebook will have data particular to that user. 
• CONSISTENT PREFIX: This ensures changes are read in the sequence of the corresponding writes. 
• EVENTUAL: The loosest consistency, commits and writes against a primary immediately, and replicant transactions are synchronously handled and eventually get to replicas.

A Cloud Guru learners missed tough questions related to NoSQL and Cosmos DB 47% of the time.

Next!

The domain name system is the internet’s phone book, converting a name (like acloud.guru) to an IP address. Azure contains a DNS zone for a domain name, which hosts the IPs for that domain name. You’ll build a DNS zone from a unique resource group that gives you a domain. You can also create a private DNS zone, though you have to set one up through the command line. All the records for a domain are in a DNS zone. 

Traffic manager, meanwhile, figures out how to intelligently route someone to your application. Traffic Manager ensures high availability across different geographic regions. If a region within your solution goes offline, Traffic Manager can route to online regions. Here’s what it looks like: 

1. The user loads the solution (and does a DNS lookup) 
2. Traffic Manager responds with an IP address based on your configuration of the Traffic Manager service 
3. The user then navigates to the appropriate solution. 

Both Traffic Manager and Azure DNS work closely together to make sure your users are able to access your app and have a good experience. DNS is the phone book that contains IP addresses from the domain name, while Traffic Manager will pick the right IP from that list of IP addresses. In classic cloud fashion, there are a ton of routing methods that come with Traffic Manager. These are multiple types you’ll put into your Traffic Manager profile: 

• PRIORITY: prioritizes primary and backup endpoints. 
• WEIGHTED: distributes traffic according to weight value, such as if you’d like 20% to go to one region and 20% to another. 
• PERFORMANCE: sends traffic to the “closest” endpoint, which is excellent for solutions global in design. 
• GEOGRAPHIC: route traffic based on the geographic location of the client. 
• MULTIVALUE: returns multiple endpoints, and up to the client to determine which endpoint to use. 
• SUBNET: route based on the requester’s IP address. You have to actually own the domain name. 

Once you’ve added your custom domain, you’ll have to complete your custom domain’s validation. You have to add a text record from whoever manages your domain name and upload it to validate that you own it. You can also configure a Vnet to enable auto-registration, pointing to a private internal DNS zone. You can use a private DNS for VMs to connect with named domains, such as somethingsomething.internal.

A Cloud Guru learners missed tough questions related to DNS 49.7% of the time.

Next!

Azure Functions are Microsoft Azure’s serverless computing product, abstracting out all the reliance on infrastructure. It’s the most flexible type of scaling based on workload volumes. The serverless programming model is based on triggers and bindings— focusing on writing code that responds to specific events and returns data the function needs to return. Functions also have a rich end-to-end development experience. 

Ultimately there’s a server in Azure running your function—you don’t know anything about it whatsoever. You write some code to respond to an event, and never see anything that’s happening with the server on Microsoft’s end. 

Functions offer the ability to run single code pieces in response to events and are billable for that execution time rather than in any other billing method. As a result, you can save an enormous amount of money on servers that are up and running but not doing anything. 

Serverless can feel somewhat orthogonal to traditional cloud computing. 

Though the benefits are enormous (especially from a cost perspective), companies accustomed to managing VMs to handle their applications will have to change the way they think about their structure. That includes at an architectural level, as well. Here are some architectural considerations that are essential to understanding functions: 

• EVENT-DRIVEN: Code is executed in response to events on an as-needed basis. Servers aren’t sitting around waiting for things to happen.
• REACTIVE: Code is applied to particular events that happen when needed. It’s responsive, resilient (events will be re-processed if failed), elastic (as events go up, it scales up), and message-driven. 
• MULTI-FACTOR: Declarative and automated deployment (the function can be deployed via code), configuration is in the environment (not configuration files), concurrency is via the process. 

There are also many ways to execute a function: on time intervals, HTTP requests, whenever something is uploaded in Blob storage, a message from an Azure Storage queue, a Cosmos DB document change, or an event hub receiving a new event.

A Cloud Guru learners missed tough questions related to serverless operations 48% of the time. 

Next!

Snapshots are a point-in-time copy of a managed disk. You’ll choose the account type (such as choosing between an HDD and SSD) for the snapshot for whatever managed disk you’re looking to save with a snapshot. They’re effectively backups for your managed disks. You can also create a new managed disk based on your snapshot of another managed disk. You might use that snapshot for troubleshooting or as a master snapshot for creating new VMs. 

WHY IS IT HARD? 

There are two kinds of snapshots: full snapshots and incremental snapshots. The former is exactly what it sounds like, a full point-in-time backup of your disk. But if you continued to use full snapshots, you’d start to rack up your storage very quickly. Incremental snapshots may be backups, but they technically aren’t a full backup. 

Each snapshot isn’t necessarily a complete backup of your storage or disk. Instead, it stores the incremental changes from your last snapshot, and the previous snapshot captures the changes from the snapshot before it. When you’re taking a new snapshot, you’re able to save money because you’re backing up the incremental changes rather than a full backup.

A Cloud Guru learners missed tough questions related to Azure Disk Storage and snapshots 50% of the time.

Often called a Vnet, virtual private networks enable Azure VMs to communicate with each other, on-premise networks, and on the Internet. Just like a VM, it’s yours to use, but the physical hardware is abstracted out. You can define multiple subnets within each VNet, which segregate your network, allocating an IP space for resources such as SQL databases or VMs

Each Vnet comes with an address space that you can divvy up across multiple subnets. Perhaps more importantly, you can isolate subnets from the Internet within your Vnets.

Vnets, and the Azure VMs within them, behave just like the Azure VMs within Microsoft’s Azure cloud. You can scale Vnets or add Vnets as you need them and isolate resources within them through subnets. You can also peer Vnets to allow routing between the two of them, while the Azure public cloud itself provides high availability. 

The upside is companies starting their migration into the cloud have an option to keep some of their resources walled off from the Internet. While they might not actually need a Vnet during their migration, it can help when trying to herd the cats internally (namely your compliance team). And Vnets allow you to isolate information that needs to be separated from the Internet, such as regulated data.

Count the arrows on that flow chart! A whole lot is going on and a lot of points of failure, especially if you’re trying to keep data isolated from the Internet. The last thing you want to do is unintentionally increase your surface area for Bad Things To Happen. If you’re starting your cloud migration, you’ll want to make sure you have an expert in networks on hand to make sure everything is spun up smoothly. 

In addition, subnets within your Vnet are restricted to one availability zone rather than spanning multiple availability zones. As such, you’ll have to configure your systems in such a way to ensure you don’t run into a scenario where one subnet needs to be talking to another in a different availability zone. 

A Cloud Guru learners missed tough questions related to Vnets and subnets 49.8% of the time.

We hope after going through these examples, you’re getting a taste of just how hairy the cloud can be. It has its own custom dictionary to go along with its sprawling urban environment of products.

We can empathize how complicated the cloud can be and hope we can provide some guidance. Then again, we didn’t write down the rules. (Well, we wrote the questions—we are genuinely sorry about that.)

You can find our full walkthrough to Azure’s thorny topics in the full Coud Dictionary of Pain. You can also find their equivalents—and what makes AWS and GCP uniquely tortuous—in our AWS and Google Cloud Dictionary of Pain. You will also find our full methodology.

Looking to level up your cloud career? Get started with A Cloud Guru's Azure learning paths and see how getting hands-on can help you master modern tech skills.

Azure Data Engineer Certification Path

Azure DevOps Certification Path

Azure Security Certification Path

Azure Development Path