Migration to the cloud presents new ways to think about your IT expenses. The cloud also removes the burden of supporting IT infrastructure.

As you move to the cloud, you might ask:

• How much will it cost?

• What guarantees does Azure provide around uptime and connectivity?

• How do preview services impact my production applications?

Learn about the factors that influence cost, tools you can use to help estimate and manage your cloud spend, and how Azure's service-level agreements (SLAs) can impact your application design decisions.

Learn about the factors that influence cost and tools you can use to help estimate and manage your cloud spend.

6.1.1 Introduction

In this module, you'll learn about the major factors that influence the cost of running in the cloud. Along the way, you'll get hands-on experience with some of the tools you can use to estimate the costs of running your workloads on Azure to help ensure that you stay within budget and use only the services that you need.

Meet Tailwind Traders

Tailwind Traders is a fictitious home improvement retailer. It operates retail hardware stores across the globe and online.

Tailwind Traders specializes in competitive pricing, fast shipping, and a large range of items. It's looking at cloud technologies to improve business operations and support growth into new markets. By moving to the cloud, the company plans to enhance its shopping experience to further differentiate itself from competitors.

How will Tailwind Traders manage cloud costs?

Tailwind Traders is planning its migration to the cloud. The company has run a few successful proof-of-concept projects and wants to better understand how to manage its costs before it moves its workloads to Azure.

Running in the datacenter requires you to maintain a facility and purchase, power, cool, and maintain your servers. Running in the cloud presents new ways to think about your IT expenses.

To answer the question of how much it will cost, you need to understand the factors that influence cost. You also need to understand what tools are available to you to help estimate and manage your cloud spend.

Learning objectives

After completing this module, you'll be able to:

• Use the Total Cost of Ownership Calculator to compare your current datacenter costs to running the same workloads on Azure.

• Describe the different ways you can purchase Azure products and services.

• Use the Pricing calculator to estimate the monthly cost of running your cloud workloads.

• Define some of the major factors that affect total cost, and apply recommended practices to minimize cost.

6.1.2 Compare costs by using the Total Cost of Ownership Calculator

Before Tailwind Traders takes its next steps toward migrating to the cloud, it wants to better understand what it spends today in its datacenter.

Having a firm understanding of where the company is today will give it a greater sense of what cloud migration means in terms of cost.

In this unit, you'll see how the Total Cost of Ownership (TCO) Calculator can help you compare the cost of running in the datacenter versus running on Azure.

What's the TCO Calculator?

The TCO Calculator helps you estimate the cost savings of operating your solution on Azure over time, instead of in your on-premises datacenter.

The term total cost of ownership is commonly used in finance. It can be hard to see all the hidden costs related to operating a technology capability on-premises. Software licenses and hardware are additional costs.

With the TCO Calculator, you enter the details of your on-premises workloads. Then you review the suggested industry average cost (which you can adjust) for related operational costs. These costs include electricity, network maintenance, and IT labor. You're then presented with a side-by-side report. Using the report, you can compare those costs with the same workloads running on Azure.

Note
You don't need an Azure subscription to work with the TCO Calculator.

How does the TCO Calculator work?

Working with the TCO Calculator involves three steps:

• Define your workloads.

• Adjust assumptions.

• View the report.

Let's take a closer look at each step.

Step 1: Define your workloads

First, you enter the specifications of your on-premises infrastructure into the TCO Calculator, based on these four categories:

· Servers
This category includes operating systems, virtualization methods, CPU cores, and memory (RAM).

· Databases
This category includes database types, server hardware, and the Azure service you want to use, which includes the expected maximum concurrent user sign-ins.

· Storage
This category includes storage type and capacity, which includes any backup or archive storage.

· Networking
This category includes the amount of network bandwidth you currently consume in your on-premises environment.

Step 2: Adjust assumptions

Next, you specify whether your current on-premises licenses are enrolled for Software Assurance, which can save you money by reusing those licenses on Azure. You also specify whether you need to replicate your storage to another Azure region for greater redundancy.

Then, you can see the key operating cost assumptions across several different areas, which vary among teams and organizations. These costs have been certified by Nucleus Research, an independent research company. For example, these costs include:

• Electricity price per kilowatt hour (KWh).

• Hourly pay rate for IT administration.

• Network maintenance cost as a percentage of network hardware and software costs.

To improve the accuracy of the TCO Calculator results, you adjust the values so that they match the costs of your current on-premises infrastructure.

Step 3: View the report

Choose a time frame between one and five years. the TCO Calculator generates a report that's based on the information you've entered.

For each category (compute, datacenter, networking, storage, and IT labor), you can also view a side-by-side comparison of the cost breakdown of operating those workloads on-premises versus operating them on Azure.

You can download, share, or save this report to review later.

In the next unit, you'll use the TCO Calculator to help the Tailwind Traders team understand their total costs.

6.1.3 Exercise - Compare sample workload costs by using the TCO Calculator

In this exercise, you use the Total Cost of Ownership (TCO) Calculator to compare the cost of running a sample workload in the datacenter versus on Azure.

Tailwind Traders is interested in moving some of its on-premises workloads to the cloud. But first, the Chief Financial Officer wants to understand more about moving from a relatively fixed cost structure to an ongoing monthly cost structure.

You've been tasked to investigate whether there are any potential cost savings in moving your European datacenter to the cloud over the next three years. You need to take into account all of the potentially hidden costs involved with operating on-premises and in the cloud.

Instead of manually collecting everything you think might be included, you use the TCO Calculator as a starting point. You adjust the provided cost assumptions to match Tailwind Traders' on-premises environment.

Note
Remember, you don't need an Azure subscription to work with the TCO Calculator.

Let's say that:

• Tailwind Traders runs two sets, or banks, of 50 virtual machines (VMs) in each bank.

• The first bank of VMs runs Windows Server under Hyper-V virtualization.

• The second bank of VMs runs Linux under VMware virtualization.

• There's also a storage area network (SAN) with 60 terabytes (TB) of disk storage.

• You consume an estimated 15 TB of outbound network bandwidth each month.

• There are also a number of databases involved, but for now, you'll omit those details.

Recall that the TCO Calculator involves three steps:

6.1.4 Purchase Azure services

In this unit, you learn how to purchase Azure services and get a sense for other factors that affect cost.

You meet with your Chief Financial Officer and some of the team leads. You learn about some assumptions you've missed. You were able to quickly update your total estimated spend through the Total Cost of Ownership (TCO) Calculator.

During the meeting, some new questions arose as the discussion moves toward cloud migration:

• What types of Azure subscriptions are available?

• How do we purchase Azure services?

• Does location or network traffic affect cost?

• What other factors affect the final cost?

• How can we get a more detailed estimate of the cost to run on Azure?

It's important to learn how costs are generated in Azure so that you can understand how your purchasing and solution design decisions can impact your final cost. You agree to research these questions, so let's review each one in greater detail.

What types of Azure subscriptions can I use?

You probably know that an Azure subscription provides you with access to Azure resources, such as virtual machines (VMs), storage, and databases. The types of resources you use impact your monthly bill.

Azure offers both free and paid subscription options to fit your needs and requirements. They are:

· Free trial

A free trial subscription provides you with 12 months of popular free services, a credit to explore any Azure service for 30 days, and more than 25 services that are always free. Your Azure services are disabled when the trial ends or when your credit expires for paid products, unless you upgrade to a paid subscription.

· Pay-as-you-go

A pay-as-you-go subscription enables you to pay for what you use by attaching a credit or debit card to your account. Organizations can apply for volume discounts and prepaid invoicing.

· Member offers

Your existing membership to certain Microsoft products and services might provide you with credits for your Azure account and reduced rates on Azure services. For example, member offers are available to Visual Studio subscribers, Microsoft Partner Network members, Microsoft for Startups members, and Microsoft Imagine members.

How do I purchase Azure services?

There are three main ways to purchase services on Azure. They are:

· Through an Enterprise Agreement

Larger customers, known as enterprise customers, can sign an Enterprise Agreement with Microsoft. This agreement commits them to spending a predetermined amount on Azure services over a period of three years. The service fee is typically paid annually. As an Enterprise Agreement customer, you'll receive the best customized pricing based on the kinds and amounts of services you plan on using.

· Directly from the web

Here, you purchase Azure services directly from the Azure portal website and pay standard prices. You're billed monthly, as a credit card payment or through an invoice. This purchasing method is known as Web Direct.

· Through a Cloud Solution Provider

A Cloud Solution Provider (CSP) is a Microsoft Partner who helps you build solutions on top of Azure. Your CSP bills you for your Azure usage at a price they determine. They also answer your support questions and escalate them to Microsoft, as needed.

You can bring up, or provision, Azure resources from the Azure portal or from the command line. The Azure portal arranges products and services by category. You select the services that fit your needs. Your account is billed according to Azure's "pay for what you use" model.

At the end of each month, you're billed for what you've used. At any time, you can check the cost management and billing page in the Azure portal to get a summary of your current usage and review invoices from prior months.

What factors affect cost?

The way you use resources, your subscription type, and pricing from third-party vendors are common factors. Let's take a quick look at each.

Resource type

A number of factors influence the cost of Azure resources. They depend on the type of resource or how you customize it.

For example, with a storage account you specify a type (such as block blob storage or table storage), a performance tier (standard or premium), and an access tier (hot, cool, or archive). These selections present different costs.

Usage meters

When you provision a resource, Azure creates meters to track usage of that resource. Azure uses these meters to generate a usage record that's later used to help calculate your bill.

Think of usage meters similar to how you use electricity or water in your home. You might pay a base price each month for electricity or water service, but your final bill is based on the total amount that you consumed.

Let's look at a single VM as an example. The following kinds of meters are relevant to tracking its usage:

• Overall CPU time.

• Time spent with a public IP address.

• Incoming (ingress) and outgoing (egress) network traffic in and out of the VM.

• Disk size and amount of disk read and disk write operations.

Each meter tracks a specific type of usage. For example, a meter might track bandwidth usage (ingress or egress network traffic in bits per second), number of operations, or its size (storage capacity in bytes).

The usage that a meter tracks correlates to a quantity of billable units. Those units are charged to your account for each billing period. The rate per billable unit depends on the resource type you're using.

Resource usage

In Azure, you're always charged based on what you use. As an example, let's look at how this billing applies to deallocating a VM.

In Azure, you can delete or deallocate a VM. Deleting a VM means that you no longer need it. The VM is removed from your subscription, and then it's prepared for another customer.

Deallocating a VM means that the VM is no longer running. But the associated hard disks and data are still kept in Azure. The VM isn't assigned to a CPU or network in Azure's datacenter, so it doesn't generate the costs associated with compute time or the VM's IP address. Because the disks and data are still stored, and the resource is present in your Azure subscription, you're still billed for disk storage.

Deallocating a VM when you don't plan on using it for some time is just one way to minimize costs. For example, you might deallocate the VMs you use for testing purposes on weekends when your testing team isn't using them. You'll learn more about ways to minimize cost later in this module.

Azure subscription types

Some Azure subscription types also include usage allowances, which affect costs.

For example, an Azure free trial subscription provides access to a number of Azure products that are free for 12 months. It also includes credit to spend within your first 30 days of sign-up. And you get access to more than 25 products that are always free (based on resource and region availability).

Azure Marketplace

You can also purchase Azure-based solutions and services from third-party vendors through Azure Marketplace. Examples include managed network firewall appliances or connectors to third-party backup services. Billing structures are set by the vendor.

Does location or network traffic affect cost?

When you provision a resource in Azure, you need to define the location (known as the Azure region) of where it will be deployed. Let's see why this decision can have cost consequences.

Location

Azure infrastructure is distributed globally, which enables you to deploy your services centrally or provision your services closest to where your customers use them.

Different regions can have different associated prices. Because geographic regions can impact where your network traffic flows, network traffic is a cost influence to consider as well.

For example, say Tailwind Traders decides to provision its Azure resources in the Azure regions that offer the lowest prices. That decision would save the company some money. But, if they need to transfer data between those regions, or if their users are located in different parts of the world, any potential savings could be offset by the additional network usage costs of transferring data between those resources.

Zones for billing of network traffic

Billing zones are a factor in determining the cost of some Azure services.

Bandwidth refers to data moving in and out of Azure datacenters. Some inbound data transfers (data going into Azure datacenters) are free. For outbound data transfers (data leaving Azure datacenters), data transfer pricing is based on zones.

A zone is a geographical grouping of Azure regions for billing purposes. The following zones include some of the regions as shown here:

• Zone 1: Australia Central, West US, East US, Canada West, West Europe, France Central, and others

• Zone 2: Australia East, Japan West, Central India, Korea South, and others

• Zone 3: Brazil South, South Africa North, South Africa West, UAE Central, UAE North

• DE Zone 1: Germany Central, Germany Northeast

How can I estimate the total cost?

As you've learned, an accurate cost estimate takes all of the preceding factors into account. Fortunately, the Azure Pricing calculator helps you with that process.

The Pricing calculator displays Azure products in categories. You add these categories to your estimate and configure according to your specific requirements. You then receive a consolidated estimated price, with a detailed breakdown of the costs associated with each resource you added to your solution. You can export or share that estimate or save it for later. You can load a saved estimate and modify it to match updated requirements.

You also can access pricing details, product details, and documentation for each product from within the Pricing calculator.

The options that you can configure in the Pricing calculator vary between products, but they can include:

· Region

A region is the geographical location in which you can provision a service. Southeast Asia, Central Canada, Western United States, and Northern Europe are a few examples.

· Tier

Tiers, such as the Free tier or Basic tier, have different levels of availability or performance and different associated costs.

· Billing options

Billing options highlight the different ways you can pay for a service. Options can vary based on your customer type and subscription type and can include options to save costs.

· Support options

These options enable you to select additional support pricing options for certain services.

· Programs and offers

Your customer or subscription type might enable you to choose from specific licensing programs or other offers.

· Azure Dev/Test pricing

This option lists the available prices for development and test workloads. Dev/Test pricing applies when you run resources within an Azure subscription that's based on a Dev/Test offer.

Keep in mind that the Pricing calculator provides estimates and not actual price quotes. Actual prices can vary depending upon the date of purchase, the payment currency you're using, and the type of Azure customer you are.

7 Units

Learn about service-level agreements (SLAs) in Azure, and how they can affect your application design decisions. See how to access preview services and learn how they affect your planning.

Learning objectives

After completing this module, you'll be able to:

• Describe what a service-level agreement (SLA) is and why SLAs are important.

• Identify factors, such as the service tier you choose, that can affect an SLA.

• Combine SLAs to compute a composite SLA.

• Describe the service lifecycle in Azure, including how to access new capabilities that are coming to Azure.

6.2.1 Introduction

In this module, you'll learn about service-level agreements (SLAs) in Azure and how they can affect your application design decisions. You'll also learn about the lifecycle of new Azure services, from preview to general availability.

Meet Tailwind Traders

Tailwind Traders is a fictitious home improvement retailer. It operates retail hardware stores across the globe and online.

Tailwind Traders specializes in competitive pricing, fast shipping, and a large range of items. It's looking at cloud technologies to improve business operations and support growth into new markets. By moving to the cloud, the company plans to enhance its shopping experience to further differentiate itself from competitors.

How will moving to the cloud affect availability agreements?

Moving to the cloud removes the burden of supporting IT infrastructure. When network connectivity is lost or a hard drive fails, you rely on the cloud provider to restore service.

Tailwind Traders' IT department hosts applications and services in its datacenter for the rest of the company. The IT department has agreements with other teams in place that state how available those services will be, which includes when and how planned maintenance can happen. As Tailwind Traders moves its workloads to Azure, it no longer has full control over the hardware and networks. How will its agreements around availability be affected?

6.2.2 What are service-level agreements (SLAs)?

As mentioned in the video, a service-level agreement (SLA) is a formal agreement between a service company and the customer. For Azure, this agreement defines the performance standards that Microsoft commits to for you, the customer.

In this part, you'll learn more about Azure SLAs, including why SLAs are important, where you can find the SLA for a specific Azure service, and what you'll find in a typical SLA.

Why are SLAs important?

Understanding the SLA for each Azure service you use helps you understand what guarantees you can expect.

When you build applications on Azure, the availability of the services that you use affect your application's performance. Understanding the SLAs involved can help you establish the SLA you set with your customers.

Later in this module, you'll learn about some strategies you can use when an Azure SLA doesn't meet your needs.

Where can I access SLAs for Azure services?

You can access SLAs from Service Level Agreements.

Note
You don't need an Azure subscription to review service SLAs.

Each Azure service defines its own SLA. Azure services are organized by category.

Open the SLA for Azure Database for MySQL, a managed database that makes it easy for developers to work with MySQL databases. You'll refer back to this SLA in a moment.

To do so:

1. Go to Service Level Agreements.

2. From the Databases category, select Azure Database for MySQL.

What's in a typical SLA?

A typical SLA breaks down into these sections:

· Introduction

This section explains what to expect in the SLA, including its scope and how subscription renewals can affect the terms.

· General terms

This section contains terms that are used throughout the SLA so that both parties (you and Microsoft) have a consistent vocabulary. For example, this section might define what's meant by downtime, incidents, and error codes.

This section also defines the general terms of the agreement, including how to submit a claim, receive credit for any performance or availability issues, and limitations of the agreement.

· SLA details

This section defines the specific guarantees for the service. Performance commitments are commonly measured as a percentage. That percentage typically ranges from 99.9 percent ("three nines") to 99.99 percent ("four nines").

The primary performance commitment typically focuses on uptime, or the percentage of time that a product or service is successfully operational. Some SLAs focus on other factors as well, including latency, or how fast the service must respond to a request.

This section also defines any additional terms that are specific to this service.

Take a moment to review the SLA for Azure Database for MySQL.

You see that this SLA focuses mainly on uptime. Azure Database for MySQL guarantees 99.99 percent, or "four nines", uptime. This means that the service is guaranteed to be running and available to process requests 99.99 percent of the time.

How do percentages relate to total downtime?

Downtime refers to the time duration that the service is unavailable.

The difference between 99.9 percent and 99.99 percent might seem minor, but it's important to understand what these numbers mean in terms of total downtime.

Here's a table to give you a sense of how total downtime decreases as the SLA percentage increases from 99 percent to 99.999 percent:

How do percentages relate to total downtime?

What are service credits?

A service credit is the percentage of the fees you paid that are credited back to you according to the claim approval process.

An SLA describes how Microsoft responds when an Azure service fails to perform to its specification. For example, you might receive a discount on your Azure bill as compensation when a service fails to perform according to its SLA.

Credits typically increase as uptime decreases. Here's how credits are applied for Azure Database for MySQL according to uptime:

What are service credits? Monthly uptime percentage Service credit %

uptime <99.99% = 10% service credit

uptime <99% = 25% service credit

uptime < 95% = 100% service credit

What's the SLA for free services?

Free products typically don't have an SLA.

For example, many Azure services provide a free or shared tier that provides more limited functionality. Services like Azure Advisor are always free. The SLA for Azure Advisor states that because it's free, it doesn't have a financially backed SLA.

How do I know when there's an outage?

Azure status provides a global view of the health of Azure services and regions. If you suspect there's an outage, this is often a good place to start your investigation.

Azure status provides an RSS feed of changes to the health of Azure services that you can subscribe to. You can connect this feed to communication software such as Microsoft Teams or Slack.

From the Azure status page, you can also access Azure Service Health. This provides a personalized view of the health of the Azure services and regions that you're using, directly from the Azure portal.

How can I request a service credit from Microsoft?

Typically, you need to file a claim with Microsoft to receive a service credit. If you purchase Azure services from a Cloud Solution Provider (CSP) partner, your CSP typically manages the claims process.

Each SLA specifies the timeline by which you must submit your claim and when Microsoft processes your claim. For many services, you must submit your claim by the end of the calendar month following the month in which the incident occurred.

Next, let's look at some other factors that Tailwind Traders needs to consider that might affect SLA performance targets.

6.2.3 Define your application SLA

An application SLA defines the SLA requirements for a specific application. This term typically refers to an application that you build on Azure.

Tailwind Traders runs an application that it built on Azure called "Special Orders." The application tracks special orders that customers have placed in the company's retail stores. A special order includes an item and any customizations the customer needs. For example, a folding door might include customizations such as dimension and hinge placement. Because customizations typically require special handling, the customized item needs to be ordered from the supplier when a customer needs it.

There are many design decisions you can make to improve the availability and resiliency of the applications and services you build on Azure. These decisions extend beyond just the SLA for a specific service. In this part, you'll explore a few of these considerations.

A good place to start is to have a discussion with your team about how important the availability of each application is to your business. The following sections cover a few factors that Tailwind Traders might consider.

Business impact

If the Special Orders application goes down, what would the business impact be? In this case, customers can't place new orders through the store and staff can't check the status of existing orders. Customers will either need to try again later or possibly go to a competitor.

Effect on other business operations

The Special Orders application doesn't affect other operations. So the majority of the Tailwind Traders business will continue to function normally if the Special Orders application went down.

Usage patterns

Usage patterns define when and how users access your application.

One question to consider is whether the availability requirement differs between critical and non-critical time periods. For example, a tax-filing application can't fail during a filing deadline.

For Tailwind Traders, retail stores aren't open 24 hours a day, so if the application were down in the middle of the night, the impact would be minimal. However, because Tailwind Traders has retail locations all over the world, it will need to ensure that each location has access to the service during its retail hours.

What does the team decide?

Let's say that Tailwind Traders decides that an SLA of 99.9 percent is acceptable for the Special Orders application. This gives the company an estimated downtime of 10.1 minutes per week. But how will it ensure that its technology choices support its application SLA?

In the next part, you'll see how the team maps its application requirements to specific Azure services. You'll learn about some of the techniques you can use to help ensure that your technology choices meet your application SLA.

6.2.4 Design your application to meet your SLA

Tailwind Traders decides that an SLA of 99.9 percent is acceptable for the Special Orders application. Recall that this gives the company an estimated downtime of 10.1 minutes per week.

Now you need to design an efficient and reliable solution for this application on Azure, keeping that application SLA in mind. You'll select the Azure products and services you need, and provision your cloud resources according to those requirements.

In reality, failures will happen. Hardware can fail. The network can have intermittent timeout periods. While it's rare for an entire service or region to experience a disruption, you still need to plan for such events.

Let's follow the process Tailwind Traders uses to ensure that its technology choices meet its application SLA.

Identify your workloads

A workload is a distinct capability or task that's logically separated from other tasks, in terms of business logic and data storage requirements. Each workload defines a set of requirements for availability, scalability, data consistency, and disaster recovery.

On Azure, the Special Orders application will require:

• Two virtual machines.

• One instance of Azure SQL Database.

• One instance of Azure Load Balancer.

Combine SLAs to compute the composite SLA

After you've identified the SLA for the individual workloads in the Special Orders application, you might notice that those SLAs are not all the same. How does this affect our overall application SLA requirement of 99.9 percent? To work that out, you'll need to do some math.

The process of combining SLAs helps you compute the composite SLA for a set of services. Computing the composite SLA requires that you multiply the SLA of each individual service.

From Service Level Agreements, you discover the SLA for each Azure service that you need. They are:

Combine SLAs to compute the composite SLA

Service vs SLA

Azure VMs = 99.9%

Azure SQL Database = 99.99%

Azure Load Balancer = 99.99%

Therefore, for the Special Orders application, the composite SLA would be:

99.9%×99.9%×99.99%×99.99%

=0.999×0.999×0.9999×0.9999 =0.9978 =99.78%

Recall that you need two virtual machines. Therefore, you include the Virtual Machines SLA of 99.9 percent two times in the formula.

Note that even though all of the individual services have SLAs equal to or better than the application SLA, combining them results in an overall number that's lower than the 99.9 percent you need. Why? Because using multiple services adds an extra level of complexity and slightly increases the risk of failure.

You see here that the composite SLA of 99.78 percent doesn't meet the required SLA of 99.9 percent. You might go back to your team and ask whether this is acceptable. Or you might implement some other strategies into your design to improve this SLA.

What happens when the composite SLA doesn't meet your needs?

For the Special Orders application, the composite SLA doesn't meet the required SLA of 99.9 percent. Let's look at a few strategies that Tailwind Traders might consider.

Choose customization options that fit your required SLA

Each of the workloads defined previously has its own SLA, and the customization choices you make when you provision each workload affects that SLA. For example:

· Disks
With Virtual Machines, you can choose from a Standard HDD Managed Disk, a Standard SSD Managed Disk, or a Premium SSD or Ultra Disk. The SLA for a single VM would be either 95 percent, 99.5 percent or 99.9 percent, depending on the disk choice.

· Tiers
Some Azure services are offered as both a free tier product and as a standard paid service. For example, Azure Automation provides 500 minutes of job runtime in an Azure free account, but is not backed by an SLA. The standard tier SLA for Azure Automation is 99.9 percent.

Make sure that your purchasing decisions take into account the impact on the SLA for the Azure services that you choose. Doing so ensures that the SLA supports your required application SLA.

Here, Tailwind Traders might choose the Ultra Disk option for its virtual machines to help guarantee greater uptime.

Build availability requirements into your design

There are application design considerations you can use that relate to the underlying cloud infrastructure.

For example, to improve the availability of the application, avoid having any single points of failure. So instead of adding more virtual machines, you can deploy one or more extra instances of the same virtual machine across the different availability zones in the same Azure region.

An availability zone is a unique physical location within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. These zones use different schedules for maintenance, so if one zone is affected, your virtual machine instance in the other zone is unaffected.

Deploying two or more instances of an Azure virtual machine across two or more availability zones raises the virtual machine SLA to 99.99 percent. Recalculating your composite SLA above with this Virtual Machines SLA gives you an application SLA of:

99.99%×99.99%×99.99%×99.99%

=99.96%

This revised SLA of 99.96 percent exceeds your target of 99.9 percent.

To learn more about the SLA for Virtual Machines, visit SLA for Virtual Machines.

Include redundancy to increase availability

To ensure high availability, you might plan for your application to have duplicate components across several regions, known as redundancy. Conversely, to minimize costs during non-critical periods, you might run your application only in a single region. Tailwind Traders might consider this if there's a trend that the special order rates are much higher during certain months or seasons.

To achieve maximum availability in your application, add redundancy to every single part of the application. This redundancy includes the application itself, as well as the underlying services and infrastructure. Be aware, however, that doing so can be difficult and expensive, and often results in solutions that are more complex than they need to be.

Consider how critical high availability is to your requirements before you add redundancy. There may be simpler ways to meet your application SLA.

Very high performance is difficult to achieve

Performance targets above 99.99 percent are very difficult to achieve. An SLA of 99.99 percent means 1 minute of downtime per week. It's difficult for humans to respond to failures quickly enough to meet SLA performance targets above 99.99 percent. Instead, your application must be able to self-diagnose and self-heal during an outage.

6.2.5 Access preview services and preview features

Now that Tailwind Traders has its applications up and running, it wants to start looking into new capabilities. One option is to look at preview services. In this part, you'll learn how Azure services go from the preview phase to being generally available.

For Tailwind Traders, migration from the datacenter to Azure is more about operational efficiency. The research and development team is looking into new, cloud-based features that will keep them ahead of the competition.

Tailwind Traders is experimenting with a custom drone delivery system for customers in rural areas. The company needs the ability to use real-time storm tracking in the drone guidance system, but the feature isn't ready yet. There's a new AI Storm Analyzer service that has just entered the public preview phase. So Tailwind Traders has decided to incorporate it into the early stages of application testing.

Note
AI Storm Analyzer is a fictitious Azure service, introduced here for illustration purposes only.

Before the team moves forward, it wants a better understanding of how preview services affect its SLA. Let's begin by defining the Azure service lifecycle.

What is the service lifecycle?

The service lifecycle defines how every Azure service is released for public use.

Every Azure service starts in the development phase. In this phase, the Azure team collects and defines its requirements, and begins to build the service.

Next, the service is released to the public preview phase. During this phase, the public can access and experiment with it so that it can provide feedback. Your feedback helps Microsoft improve services. More importantly, providing feedback gives you the opportunity to request new or different capabilities so that services better meet your needs.

After a new Azure service is validated and tested, it's released to all customers as a production-ready service. This is known as general availability (GA).

What terms and conditions can I expect?

Each Azure preview defines its own terms and conditions. All preview-specific terms and conditions supplement your existing Azure service agreement.

Some previews aren't covered by customer support. Therefore, previews are not recommended for business-critical workloads.

How can I access preview services?

You can access preview services from the Azure portal.

Here's how to see what preview services are available. You can follow along if you have an Azure subscription.

1. Go to the Azure portal and sign in.

2. Select Create a resource.

3. Enter preview in the search box, and select Enter.

4. Select a service to learn more about it. You can also launch the service if you'd like to try it out.

How can I access new features for an existing service?

Some preview features relate to a specific area of an existing Azure service. For example, a compute or database service that you use daily might provide enhanced functionality. These preview features are accessible when you deploy, configure, and manage the service.

Although you can use an Azure preview feature in production, make sure you're aware of any limitations around its use before you deploy it to production.

How can I access preview features for the Azure portal?

You can access preview features that are specific to the Azure portal from Microsoft Azure (Preview).

Typical portal preview features provide performance, navigation, and accessibility improvements to the Azure portal interface.

You see Microsoft Azure (Preview) near the menu bar to remind you that you're working with a preview version of the Azure portal.

How can I provide feedback on the Azure portal?

You can provide feedback:

· From the Feedback tab in the Azure portal.

· From the Azure portal feedback forum.

How can I stay updated on the latest announcements?

The Azure updates page provides information about the latest updates to Azure products, services, and features, as well as product roadmaps and announcements.

From the Azure updates page, you can:

· View details about all Azure updates.

· See which updates are in general availability, preview, or development.

· Browse updates by product category or update type.

· Search for updates by keyword.

· Subscribe to an RSS feed to receive notifications.

· Access the Microsoft Connect page to read Azure product news and announcements.

6.2.6 Knowledge check

1. What's the SLA for Azure Maps in terms of guaranteed uptime?

· 99 percent

· 99.9 percent

· 99.99 percent

2. What's the new composite SLA? Remember, the new SLA includes a third virtual machine and Azure Maps.

· 99.58 percent

· 99.78 percent

· 99.99 percent

3. Adding a third virtual machine reduces the composite SLA. How can Tailwind Traders offset this reduction?

· Increase the size of each virtual machine.

· Deploy extra instances of the same virtual machines across the different availability zones in the same Azure region.

· Do nothing. Using Azure Load Balancer increases the SLA for virtual machines.

4. What approach might the company take in adding the augmented reality (AR) preview service to its architecture?

· The Special Orders app is already in production. The company shouldn't look into the AR service until the service reaches general availability (GA).

· The Special Orders app is mainly for use by retail employees. The company can integrate the AR service now because potential downtime or failures aren't an important factor.

· The development team can create a prototype version of the app that includes the AR service that it tests out with select retail employees.

6.2.7 Summary

A service-level agreement (SLA) is the formal agreement between a service company and the customer. For Azure, this agreement defines the performance standards that Microsoft commits to for its customers.

The Tailwind Traders team is working on quite a variety of projects! In addition to its main website, the team is adding a mapping feature to its Special Orders application so that it can calculate routes between suppliers and retail stores. The team is also exploring how severe weather tracking can improve its drone guidance system.

As requirements evolve, it's important for the team to understand how the SLA for each service it chooses affects the overall performance guarantees of its applications.

For example, the main website must be available as close to 100 percent of the time as possible. To accomplish that, Tailwind Traders might deploy extra instances of the same virtual machine across different availability zones in the same Azure region. Doing so helps ensure that if one zone is affected, virtual machine instances in the other zone can pick up the load.

The Special Orders application might have more flexible tolerances. As long as retail employees don't lose data and can quickly regain network access, the Special Orders application might have a lower SLA. Here, the team can choose to include less redundancy in its design.

When defining your SLA requirements, be sure to consider both your business needs and the time it takes to restore a component after a failure. Also consider how the use of preview services and preview features might affect your systems in production.