Is Your Application a Good Fit for Azure?
Updated: April 8, 2014
Author: Jason Roth
Reviewers: Paulette McKay, Ralph Squillace, Sidney Higa, Brian Swan, Larry Franks
If you're considering using to host an application, you might wonder if the platform serves your application or business requirements best. You can host most applications and machines on . However, some scenarios take better advantage of the benefits of running in the Cloud. In the following sections, this article will outline these benefits and scenarios in order to inform your decisions on migrating to :
Understand the Benefits of Azure
Target Scenarios that Leverage the Strengths of Azure
Identify Applications and Data that should Remain On-Premises
Evaluate Architecture and Service Options
The intent is to provide a framework for thinking about your application and how it relates to the capabilities of . In many cases, we provide links to additional resources. These resources will improve your ability to analyze your application and make a decision on how to move to the Cloud.
Understand the Benefits of
Before you can determine if your application is appropriate for , you must first understand some of the main benefits of the platform. You can find a complete list of benefits in the Azure documentation and in many articles and videos about . One excellent paper for thinking about the benefits of the Cloud is Cloud Optimization – Expanding Capabilities, while Aligning Computing and Business Needs.
It is also important to understand the three major options for running applications on : Web Sites, Cloud Services, and Virtual Machines. Web Sites and Cloud Services are both Platform-as-a-Service (PaaS) offerings. This means that provides all of the hardware and operating system images. You provide the application code that runs on the platform. Virtual Machines provide an Infrastructure-as-a-Service (IaaS) offering. This means that you manage machine images that run inside datacenters. These three options provide various advantages, and you're choice will depend on a number of factors. However, with these varying options and capabilities, almost any application is a good fit for .
There are some key benefits in running applications in the Cloud. Let's look at a few of these benefits at a high level before we discuss scenarios that take advantage of these features.
When you deploy your application and services to the Cloud, provides the necessary virtual machines, network bandwidth, and other infrastructure resources. If machines go down for hardware updates or because of unexpected failures, locates new virtual machines for your application automatically.
Because you only pay for what you use, you can start with a smaller investment. Doing so avoids incurring the typical upfront costs required for an on-premises deployment. This can be especially useful for small companies. In an on-premises scenario, small organizations might not have the datacenter space, IT skills, or hardware skills necessary to deploy their applications successfully. The automatic infrastructure services that provides offers a low barrier of entry for application deployment and management.
Dynamic scaling refers to the capability to both scale out and scale back your application depending on resource requirements. This is also referred to as elastic scale. Before describing how this works, let's look at the typical architecture of a application that uses Cloud Services. With Cloud Services, you create roles that work together to implement your application logic. For example, one web role could host the ASP.NET front-end of your application. One or more worker roles could perform necessary background tasks. One or more virtual machines host each role; these are called role instances in the datacenter. Requests are load balanced across these instances. For more information about roles, see the paper The Azure Programming Model.
In this scenario, as resource demands increase, you can provision new role instances to handle the load. When demand decreases, you can remove these instances so that you don't have to pay for unnecessary computing power. There are also options for automatically scaling up and down based on predefined rules and policies. This is very different from an on-premises deployment where you must over-provision hardware to anticipate peak demands. If you want more control over automatic scaling than the platform provides, you can use the Autoscaling Application Block created by the Microsoft Patterns and Practices team.
Although the previous scenario describes dynamic scaling in the context of Cloud Services, you can also scale out Web Sites and Virtual Machines. If your application requires fluctuating or unpredictable demands for computing resources, allows you to easily adjust your resource utilization to match the load.
High Availability and Durability
provides a platform for highly available applications that can reliably store and access server data through storage services or Microsoft Azure SQL Database.
First, ensures high availability of compute resources. For Web Sites, you can meet the requirements of the Service Level Agreement (SLA) with only a single instance. For Cloud Services and Virtual Machines, you can meet the SLA requirements by having at least two instances per role or machine type. For Virtual Machines, the instances must be interchangeable, load balanced, and part of the same availability group. In each case, monitors the actual hardware that hosts these virtual machines and instances. is able to respond quickly to hardware restarts or failures by deploying new instances or moving application code and processing to other working hardware.
Second, ensures high availability and durability for data stored by one of its storage services. storage services replicate all data to at least three different servers. By default, this storage also replicates to a secondary region. Similarly, Azure SQL Database replicates all data to guarantee availability and durability.
Other services provide similar high availability guarantees. For more information, see the Azure Business Continuity Technical Guidance.
Target Scenarios That Leverage the Strengths of
With an understanding of the strengths of the platform, you can begin to look at the scenarios that are best suited for the Cloud. The following sections discuss several of these situations and how is ideally suited for certain workloads and goals. The video Azure Design Patterns explains many of the scenarios below and provides a good overview of the platform.
|Although there is a focus on application scenarios here, you can choose to use individual services. For example, if using blob storage solves an application problem, the rest of your application can remain outside of the Cloud. This is called a hybrid application and is discussed later in this topic.|
Highly Available Services
is well-suited for hosting highly available services. Consider an online store deployed in . Because an online store is a revenue generator, it is critical that it stay running. To accomplish this, the datacenter performs service monitoring and automatic instance management. The online store must also stay responsive to customer demand. The elastic scaling ability of accomplishes this. During peak shopping times, new instances can come online to handle the increased usage. In addition, the online store must not lose orders or fail to completely process placed orders. storage and Azure SQL Database both provide highly available and durable storage options to hold the order details and state throughout the order lifecycle. For the highest levels of availability, you can deploy the same application to multiple regions. It is possible to design a service that remains available even if an entire region experiences a temporary failure. Doing this requires the proper synchronization architecture and procedures for routing users.
Another good fit for is some form of an "on and off" workload. Some applications do not need to run continuously. One simple example of this is a demo or utility application that you want to make available only for several days or weeks. allows you to easily create, deploy, and share that application with the world. But once its purpose is accomplished, you can remove the application and you are only charged for the time it was deployed.
|Note: You must remove the deployment, not just suspend the application, to avoid charges for compute time.|
Also consider a large company that runs complex data analysis of sales numbers at the end of each month. Although processing-intensive, the total time required to complete the analysis is at most two days. In an on-premises scenario, the servers required for this work would be underutilized for the majority of the month. In , the business would only pay for the time that the analysis application is running in the Cloud. Let’s assume that the architecture of the application is designed for parallel processing. The scale out features of would allow the company to create large numbers of worker role instances or virtual machines. Working together, these can complete more complex work in less time. In this example, you should use code or scripting to automatically deploy the application at the appropriate time each month.
All businesses have a goal of rapid and sustainable growth. But growth is very hard to handle in the traditional on-premises model. If the expected growth does not materialize, you've spent money maintaining underutilized hardware and infrastructure. But if growth happens more quickly than expected, you might be unable to handle the load, resulting in lost business and poor customer experience. For small companies, there might not even be enough initial capital to prepare for or keep up with rapid growth.
is ideal for handling this situation. Consider a small sports news web site that makes money from advertising. The amount of revenue is directly proportional to the amount of traffic that the site generates. In this example, initial capital for the venture is limited. Additionally, the company does not have the money required to set up and run its own datacenter. By designing the web site to run on , the company can easily deploy its solution as an ASP.NET application. The application will use a Azure SQL Database for relational data and blob storage for pictures and videos. If the popularity of the web site grows dramatically, the company can increase the number of web role instances for its front-end. The company can also increase the size of the Azure SQL Database. The blob storage has built-in scalability features within . If business decreases, the company can remove any unnecessary instances. Because its revenue is proportional to the traffic on the site, helps the company to start small, grow fast, and reduce risk.
With , you have complete control to determine how aggressively to manage your computing costs. You could decide to implement automatic scaling, either through the use of the Autoscale feature or through the Autoscaling Application Block. This can add and remove instances based on custom rules. You could choose to vary the number of instances based on a predetermined amount. For example, you might have four instances during business hours and two instances during non-business hours. You could also keep the number of instances constant and only increase them manually through the web portal as demand increases over time. gives you the flexibility to make the decisions that are right for your business.
This is another workload pattern that requires elastic scale. Consider the previous example of a sports news web site. Even as its business is steadily growing, there is still the possibility of temporary spikes or bursts of activity. For example, let’s say another popular news outlet refers to the site. The number of visitors to the site could dramatically increase in a single day. In a more predictable scenario, major sporting events and sports championships will result in more activity on its site.
An alternative example is a service that processes daily reports at the end of the day. When the business day closes, each office sends in a report that the company headquarters processes. Because the process is only active a few hours each day, it is also a candidate for elastic scaling and deployment.
is well-suited for temporarily scaling out an application to handle load spikes and then scaling back after the event has passed.
As demonstrated in the previous examples, many of the most common Cloud scenarios take advantage of the elastic scaling of . However, even applications with steady workload patterns can realize cost savings in . It is expensive to manage your own datacenter, especially when you consider the cost of energy, people, skills, hardware, software licensing, and facilities. It is also hard to understand how costs are tied to individual applications. In , the goal is to reduce total costs as well as to make those costs more transparent. We suggest that you read the paper Cloud Optimization – Expanding Capabilities, while Aligning Computing and Business Needs. The paper does a great job of explaining typical on-premises hosting costs and how can reduce these costs.
Virtual Machines and Virtual Network provide the simplest way to migrate on-premises servers and networks to the Cloud. Transitioning on-premises applications to Cloud Services or Web Sites also alleviates the pressure on the on-premises datacenter. Instead of the on-premises datacenter, is now responsible for providing the required computing and storage resources for those applications.
provides a pricing calculator for understanding specific costs. It also provides a TCO (Total Cost of Ownership) calculator for estimating the overall cost reduction that could occur by adopting . For links to the calculator tool and other pricing information, see the Azure web site.
Identify Applications and Data That Should Remain On-Premises
has services and options that fit almost any application. These span PaaS options, such as Cloud Services and Web Sites, and IaaS with Virtual Machines and Virtual Network. However, there are scenarios that warrant slower or no migration to the Cloud.
One scenario is a low-volume application or service with no projections for growth. It is possible that you might be able to run that application on commodity hardware on-premises less expensively than in the Cloud. There are two exceptions to this. There are benefits to moving to that go beyond simple hosting costs. For example, you might want to be free from managing the server, its availability, and the durability of your data. Second, with Web Sites, there is a free hosting option for low-volume web sites. For example, you might use this to host a personal WordPress blog.
Another scenario involves data that you cannot move to . Businesses and governments sometimes regulate the type of data that can reside in the Cloud. In these cases, you might consider a hybrid solution. In this instance, hosts only certain data or specific parts of your application that are not as sensitive and need to be highly available.
By understanding the strengths of , you can recognize applications or parts of an application that will not leverage these strengths. You can then more successfully develop the overall solution that most effectively utilizes capabilities.
Evaluate Architecture and Service Options
Of course, evaluating a move to involves more than just knowing that your application or business goals are appropriate for the Cloud. It is also important to evaluate the architectural and development characteristics of your existing or new application. A quick way to start this analysis is to use the Microsoft Assessment Tool (MAP) for . This tool asks questions to determine the types of issues you might encounter when moving to . Next to each question is a link called "See full consideration", which provides additional information about that specific area in . These questions and the additional information can help you identify potential changes to the design of your existing or new application in the Cloud.
In addition to the MAP tool, you should have a solid understanding of the basics of the platform. This includes an understanding of common design patterns for the platform. You should also consider reviewing the technical posters for . These have rich information about the capabilities of the platform, as well as links to more information. Review the different services available in and consider how they could factor into your solution. For an overview of services, see What is Azure?. When you are planning your architecture, review the Azure Subscription and Service Limits, Quotas, and Constraints.
It is beyond the scope of this paper to cover all of the possible considerations and mitigations for solutions. However, the following table lists four common design considerations along with links to additional resources.
IaaS or PaaS?
Infrastructure as a Service (IaaS) allows you to put your own images on Virtual Machines in . This is often a simpler way to migrate to the Cloud because it involves fewer changes to the application architecture.
Web Sites and Cloud Services provide Platform as a Service (PaaS). Applications you design for a PaaS environment are often more flexible, scalable, and manageable than similar solutions on IaaS. However, it typically takes more time to complete a migration to Cloud Services. Web Sites provides a good balance between PaaS’ advantages and IaaS’ ease of migration.
To better understand these options from a Web perspective, see Azure Web Sites, Cloud Services and Virtual Machines comparison.
It can be difficult to move complex legacy applications to . There are also sometimes regulatory concerns with storing certain types of data in the Cloud. Some answers about security and regulatory compliance are addressed in the Azure Trust Center.
To meet these challenges, one solution is to create a hybrid application that connects services that hosts with on-premises applications and data. There are multiple technologies that support this capability, including Service Bus and Virtual Network. For more information, see Building Hybrid Applications in the Cloud on Azure.
If you are moving an existing application to Virtual Machines, you can typically handle state data in the same way that you did on-premises. However, if you want to take advantage of the PaaS architecture of Cloud Services, you must evaluate how you handle state. Many on-premises applications store state locally on the hard drive. Other features, such as the default ASP.NET session state, use the memory of the local machine for state management. Although cloud service roles have access to their virtual machine's local drive space and memory, load balances all requests across all role instances. Additionally, your role instance could be taken down and moved at any time (for example, when the machine running the role instance requires an update).
This dynamic management of working role instances is important for the scalability and availability features of Cloud Services. Consequently, you must design application code in the Cloud to store data and state remotely using services such as storage or Azure SQL Database. For more information about storage options, see the resources in the Store and Access Data section of the web site.
Azure SQL Database is the relational database solution in . If you currently use SQL Server, the transition to Azure SQL Database should be easier. You can also choose to run SQL Server on a Virtual Machine. If you are using a different database system, one option is to migrate to Azure SQL Database or SQL Server on a Virtual Machine. There are SQL Server Migration Assistants that can help with this process. For more information on migrating data to Azure SQL Database, see Data Migration to Azure SQL Database: Tools and Techniques. Another option is to migrate your third-party database directly to . One technique is to install your database system on a Virtual Machine. However, there are also third-party offerings in the Azure Store for systems like MySQL and MongoDB.
Also consider storage for durable, highly available, and scalable data storage. One good design pattern is to effectively combine the use of Azure SQL Database and storage tables, queues, and blobs. A common example is to use Azure SQL Database to store a pointer to a blob in storage. You do this instead of storing the large binary object in the database itself. This is both efficient and cost-effective.
The SDK and tools for Visual Studio greatly simplify the process of creating or migrating .NET applications to .
But what if you are using open source software or third-party development languages and tools? Web Sites and Cloud Services support applications written in Node.js, PHP, Python, and Java (for Cloud Services only). If your application uses another language, consider a Virtual Machine.When working with services, all operations are based on a REST API. You can directly code for this. However, provides official SDKs for Java, Node.js, PHP, Python, and Ruby that provide friendly wrappers around the REST API. There are also community-created SDKs that interact with .
Of course, there are some challenges to address depending on your technology. For Virtual Machines, you must install the necessary runtimes and dependencies on your machine image. For Cloud Services, you may need to add a custom startup action to install the third-party dependencies for your role. For Web Sites, you may need to make minor modifications to allow the application to work in a PaaS hosting environment. A great resource in this area is the Ineroperability Bridges and Labs Center.
The important point is that is accessible from a variety of languages. Therefore, you should look into the options for your particular language of choice before deciding if the application is a good candidate for .
Beyond these issues, you can learn a lot about potential development challenges and solutions by reviewing content on migrating applications to . The Patterns and Practices group at Microsoft published the following guidance on migration: Moving Applications to the Cloud on the Microsoft Azure Platform.
offers a platform for creating and managing highly scalable and available services. There are two PaaS offerings, Web Sites and Cloud Services, and an IaaS offering with Virtual Machines. In addition to these offerings, there are many supporting services and features that support many different application scenarios. You pay only for the resources that you require and then scale them up and down at any time. And you don't have to own the hardware or supporting infrastructure to do this. If your business can leverage the platform to increase agility, lower costs, or lower risk, then is a good fit for your application. After making this determination, you can then look at specific architecture and development options for using the platform. This includes decisions about new development, migration, or hybrid scenarios. After this analysis, you’ll have the necessary information to make an informed decision about how to most effectively use to reach your business goals.