Azure Coursebook

LECTURE 1: INTRODUCTION TO CLOUD COMPUTING .................................................................... 6 Essential Characteristics: ............................................................................................................. 6 Service Models: ........................................................................................................................... 7 Deployment Models: ................................................................................................................... 7 LECTURE 2: Introducing Windows Azure ................................................................................... 9 Azure Overview ........................................................................................................................... 9 Is Your Application a Good Fit for Windows Azure? ................................................................. 11 Understand the Benefits of Windows Azure ............................................................................. 11 Target Scenarios that Leverage the Strengths of Windows Azure ............................................ 12 Scenarios that Do Not Require the Capabilities of Windows Azure.......................................... 15 Evaluate Architecture and Development .................................................................................. 16 Summary.................................................................................................................................... 18 LECTURE 3: Main Components of Windows Azure ....................................................................... 19 Table of Contents .................................................................................................................... 19 The Components of Windows Azure .................................................................................... 19 Execution Models .................................................................................................................... 20 Data Management .................................................................................................................. 23 Networking .............................................................................................................................. 25 Business Analytics ................................................................................................................... 27 Messaging ................................................................................................................................ 29 Caching ..................................................................................................................................... 30 Identity...................................................................................................................................... 32 High-Performance Computing .............................................................................................. 33 Media ........................................................................................................................................ 33 Commerce ................................................................................................................................ 34 SDKs .......................................................................................................................................... 35 Getting Started ........................................................................................................................ 36 Lecture 4: WINDOWS AZURE COMPUTE ....................................................................................... 62 Web Sites vs Cloud Services vs Virtual Machines ...................................................................... 62 WINDOWS AZURE CLOUD SERVICES: ................................................ Error! Bookmark not defined. WEB ROLE AND WORKER ROLE ..................................................................................................... 70 THE THREE RULES OF THE WINDOWS AZURE PROGRAMMING MODEL................................... 70 A WINDOWS AZURE APPLICATION IS BUILT FROM ONE OR MORE ROLES ............................... 71

A WINDOWS AZURE APPLICATION RUNS MULTIPLE INSTANCES OF EACH ROLE ..................... 72 A WINDOWS AZURE APPLICATION BEHAVES CORRECTLY WHEN ANY ROLE INSTANCE FAILS . 73 WHAT THE WINDOWS AZURE PROGRAMMING MODEL PROVIDES ......................................... 75 IMPLICATIONS OF THE WINDOWS AZURE PROGRAMMING MODEL: WHAT ELSE CHANGES? . 78 MOVING WINDOWS SERVER APPLICATIONS TO WINDOWS AZURE......................................... 82 CONCLUSION ............................................................................................................................. 84 Cloud service concept ................................................................................................................ 85 Concepts....................................................................................... Error! Bookmark not defined. Data Management and Business Analytics .............................................................................. 88 Table of Contents .................................................................................................................... 88 Blob Storage ............................................................................................................................ 88 Running a DBMS in a Virtual Machine ................................................................................. 90 SQL Database .......................................................................................................................... 91 Table Storage........................................................................................................................... 96 Hadoop ..................................................................................................................................... 97 Lecture 6: .................................................................................................................................... 100 Windows Azure SQL Database .................................................................................................... 100 Similarities and Differences ..................................................................................................... 100 Compare SQL Server with Windows Azure SQL Database (en-US) .................................... 103 Table of Contents .................................................................................................................. 103  ............................................................................................................................................... 103 

Similarities and Differences.......................................................................................... 103



Logical Administration vs. Physical Administration .................................................. 103



Provisioning ................................................................................................................... 103



Transact-SQL Support .................................................................................................. 103



Features and Types ....................................................................................................... 103



Key Benefits of the Service ........................................................................................... 103

o

Self-Managing ............................................................................................................... 103

o

High Availability ............................................................................................................ 103

o

Scalability ....................................................................................................................... 103

o

Familiar Development Model ...................................................................................... 103

o

Relational Data Model .................................................................................................. 103



See Also .......................................................................................................................... 103



Other Languages ........................................................................................................... 103

Similarities and Differences ................................................................................................. 103 Logical Administration vs. Physical Administration .......................................................... 103 Provisioning ........................................................................................................................... 104 Transact-SQL Support .......................................................................................................... 104 Features and Types ............................................................................................................... 105 Key Benefits of the Service................................................................................................... 105 Federations in Windows Azure SQL Database (formerly SQL Azure) .......................................... 109 Federation Architecture .......................................................................................................... 109 Design Considerations ............................................................................................................. 111 LECTURE 7: ................................................................................................................................. 125 NETWORKING, CACHING AND ACCESS CONTROL IN WINDOWS AZURE ....................... 125 Windows Azure Networking .................................................................................................... 125 Table of Contents .................................................................................................................. 125 Windows Azure Virtual Network ......................................................................................... 125 Windows Azure Connect ...................................................................................................... 127 Windows Azure Traffic Manager ......................................................................................... 129 Caching in Windows Azure .......................................................................................................... 131 Caching (Preview) on Roles ..................................................................................................... 131 Shared Caching ........................................................................................................................ 131 In This Section................................................................................ Error! Bookmark not defined. Lecture 8: .................................................................................................................................... 117 WINDOWS AZURE SERVICE BUS............................................................................................. 117 Software, Services, Clouds, and Devices ................................................................................ 117 Fulfilling the Potential ............................................................................................................. 117 Feature Overview .................................................................................................................... 118 Relayed and Brokered Messaging ............................................................................................... 120 Relayed Messaging .................................................................................................................. 120 Brokered Messaging ................................................................................................................ 121 What are Service Bus Queues ................................................................................................. 121 What are Service Bus Topics and Subscriptions ...................................................................... 122

What is the Service Bus Relay ................................................................................................. 123

LECTURE 1: INTRODUCTION TO CLOUD COMPUTING (From ―The NIST Definition of Cloud Computing‖) Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.

Essential Characteristics: On-demand self-service: A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider. Broad network access: Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations). Resource pooling: The provider‘s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth. Rapid elasticity: Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time. Measured service: Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Typically this is done on a pay-per-use or charge-per-use basis. Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

A cloud infrastructure is the collection of hardware and software that enables the five essential characteristics of cloud computing. The cloud infrastructure can be viewed as containing both a physical layer and an abstraction layer. The physical layer consists of the hardware resources that are necessary to support the cloud services being provided, and typically includes server, storage and network components. The abstraction layer consists of the software deployed across the physical layer, which manifests the essential cloud characteristics. Conceptually the abstraction layer sits above the physical layer.

Service Models: Software as a Service (SaaS): The capability provided to the consumer is to use the provider‘s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings. Platform as a Service (PaaS): The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment. Infrastructure as a Service (IaaS): The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

Deployment Models:

Private cloud. The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises. Community cloud. The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises. Public cloud. The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider. Hybrid cloud. The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).

LECTURE 2: Introducing Windows Azure Azure Overview Windows Azure is an open and flexible cloud platform that enables you to quickly build, deploy and manage applications across a global network of Microsoft-managed datacenters. You can build applications using any language, tool or framework. And you can integrate your public cloud applications with your existing IT environment.

Always up. Always on. Windows Azure delivers a 99.95% monthly SLA and enables you to build and run highly available applications without focusing on the infrastructure. It provides automatic OS and service patching, built in network load balancing and resiliency to hardware failure. It supports a deployment model that enables you to upgrade your application without downtime.

Open Windows Azure enables you to use any language, framework, or tool to build applications. Features and services are exposed using open REST protocols. The Windows Azure client libraries are available for multiple programming languages, and are released under an open source license and hosted on GitHub.

Unlimited servers. Unlimited storage. Windows Azure enables you to easily scale your applications to any size. It is a fully automated self-service platform that allows you to provision resources within minutes. Elastically grow or shrink your resource usage based on your needs. You only pay for the resources your application uses. Windows Azure is available in multiple datacenters around the world, enabling you to deploy your applications close to your customers.

Powerful Capabilities Windows Azure delivers a flexible cloud platform that can satisfy any application need. It enables you to reliably host and scale out your application code within compute roles. You can store data using relational SQL databases, NoSQL table stores, and unstructured blob

stores, and optionally use Hadoop and business intelligence services to data-mine it. You can take advantage of Windows Azure‘s robust messaging capabilities to enable scalable distributed applications, as well as deliver hybrid solutions that run across a cloud and onpremises enterprise environment. Windows Azure‘s distributed caching and CDN services allow you to reduce latency and deliver great application performance anywhere in the world.

Is Your Application a Good Fit for Windows Azure? If you're considering using Windows Azure to host an application, you might wonder if your application or business requirements are best served by the platform. This topic attempts to answer this question by: Looking at the benefits Windows Azure provides to your application Applying the strengths of the platform to common scenarios Rejecting scenarios that do not leverage the strengths of the platform Examining some common architecture and development considerations The intent is to provide a framework for thinking about your application and how it relates to the capabilities of Windows Azure. In many cases, links to additional resources are provided to improve your ability to analyze your application and make a decision on how to move to the cloud.

Understand the Benefits of Windows Azure Before you can determine if your application is well-suited for Windows Azure, you must first understand some of the main benefits of the platform. A complete list of benefits can be found in the Windows Azure documentation and many articles and videos about Windows Azure. One excellent paper on this subject is Cloud Optimization – Expanding Capabilities, while Aligning Computing and Business Needs. There are several benefits to having hardware and infrastructure resources managed for you. Let's look at a few of these benefits at a high level before we discuss scenarios that take advantage of these features. Resource Management When you deploy your application and services to the cloud, Windows Azure provides the necessary virtual machines, network bandwidth, and other infrastructure resources. If machines go down for hardware updates or due to unexpected failures, new virtual machines are automatically located for your application. Because you only pay for what you use, you can start off with a smaller investment rather than incurring the typical upfront costs required for an on-premises deployment. This can be especially useful for small companies. In an on-premises scenario, these organizations might not have the data center space, IT skills, or hardware skills necessary to successfully deploy their applications. The automatic infrastructure services provided by Windows Azure offer a low barrier of entry for application deployment and management. Dynamic Scaling

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, you should understand the basic architecture of a Windows Azure application. In Windows Azure, 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, and one or more worker roles could perform necessary background tasks. Each role is hosted on one or more virtual machines, called role instances, in the Windows Azure data center. Requests are load balanced across these instances. For more information about roles, see the paper The Windows Azure Programming Model. If resource demands increase, new role instances running your application code can be provisioned to handle the load. When demand decreases, these instances can be removed so that you don't have to pay for unnecessary computing power. This is much different from an on-premises deployment where hardware must be overprovisioned to anticipate peak demands. This scaling does not happen automatically, but it is easily achieved through either the web portal or the Service Management API. The paper Dynamically Scaling an Application demonstrates one way to automatically scale Windows Azure applications. There is also an Autoscaling Application Block created by the Microsoft Patterns and Practices team. If your application requires fluctuating or unpredictable demands for computing resources, Windows Azure allows you to easily adjust your resource utilization to match the load. High Availability and Durability Windows Azure provides a platform for highly available applications that can reliably store and access backend data through storage services or Windows Azure SQL Database. First Windows Azure ensures high availability of your compute resources when you have multiple instances of each role. Role instances are automatically monitored, so it is able to respond quickly to hardware restarts or failures by automatically deploying a role to a new instance. Second, Windows Azure ensures high availability and durability for data stored through one of the storage services. Windows Azure storage services replicate all data to at least three different servers. Similarly, SQL Database replicates all data to guarantee availability and durability. Other Windows Azure services provide similar high availability guarantees. For more information, see theWindows Azure SLA.

Target Scenarios that Leverage the Strengths of Windows Azure

With an understanding of the strengths of the Windows Azure platform, you can begin to look at the scenarios that are best suited for the cloud. The following sections discuss several of these patterns and how Windows Azure is ideally suited for certain workloads and goals. The video Windows Azure Design Patterns explains many of the scenarios below and provides a good overview of the Windows Azure platform. Tip Although there is a focus on application scenarios here, understand that you can choose to use individual services of Windows Azure. For example, if you find that using blob storage solves an application problem, it is possible that the rest of your application remains outside of the Cloud. This is called a hybrid application and is discussed later in this topic.

Highly Available Services Windows Azure is well-suited to hosting highly available services. Consider an online store deployed in Windows Azure. Because an online store is a revenue generator, it is critical that it stay running. This is accomplished by the service monitoring and automatic instance management performed in the Windows Azure data center. The online store must also stay responsive to customer demand. This is accomplished by the elastic scaling ability of Windows Azure. 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. Windows Azure storage and SQL Database both provide highly available and durable storage options to hold the order details and state throughout the order lifecycle. Periodic Workloads Another good fit for Windows Azure 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. Windows Azure 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 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 Windows Azure, the business would only pay for the time that the analysis application

is running in the cloud. And assuming the architecture of the application is designed for parallel processing, the scale out features of Windows Azure could enable the company to create large numbers of worker role instances to 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. Unpredictable Growth 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. Windows Azure 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, and they do not have the money required to setup and run their own data center. By designing the web site to run on Windows Azure, they can easily deploy their solution as an ASP.NET application that uses a backend SQL Database for relational data and blob storage for pictures and videos. If the popularity of the web site grows dramatically, they can increase the number of web role instances for their front-end or increase the size of the SQL Database. The blob storage has built-in scalability features within Windows Azure. If business decreases, they can remove any unnecessary instances. Because their revenue is proportional to the traffic on the site, Windows Azure helps them to start small, grow fast, and reduce risk. With Windows Azure, you have complete control to determine how aggressively to manage your computing costs. You could decide to use the Service Management API or the Autoscaling Application Block to create an automatic scaling engine that creates and removes instances based on custom rules. You could choose to vary the number of instances based on a predetermined amount, such as four instances during business hours versus two instances during non-business hours. Or you could keep the number of instances constant and only increase them manually through the web portal as demand increases over time. Windows Azure gives you the flexibility to make the decisions that are right for your business. Workload Spikes This is another workload pattern that requires elastic scale. Consider the previous example of a sports news web site. Even as their business is steadily growing, there is still the possibility of temporary spikes or bursts of activity. For example, if they are referenced by another popular news outlet, the numbers of visitors to their 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 their 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 which is processed at the company headquarters. Since the process needs to be active only a few hours each day, it is also a candidate for elastic scaling and deployment. Windows Azure is well suited for temporarily scaling out an application to handle spikes in load and then scaling back again after the event has passed. Infrastructure Offloading As demonstrated in the previous examples, many of the most common cloud scenarios take advantage of the elastic scale of Windows Azure. However, even applications with steady workload patterns can realize cost savings in Windows Azure. It is expensive to manage your own data center, 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 Windows Azure, the goal is to reduce total costs as well as to make those costs more transparent. The paper, Cloud Optimization – Expanding Capabilities, while Aligning Computing and Business Needs, does a great job of explaining typical on-premises hosting costs and how these can be reduced with Windows Azure. Windows Azure also provides a pricing calculator for understanding specific costs and a TCO (Total Cost of Ownership) calculator for estimating the overall cost reduction that could occur by adopting Windows Azure. For links to these calculator tools and other pricing information, see the Windows Azure web site.

Scenarios that Do Not Require the Capabilities of Windows Azure Not all applications should be moved to the cloud. Only applications that benefit from Windows Azure features should be moved to the cloud. A good example of this would be a personal blog website intended for friends and family. A site like this might contain articles and photographs. Although you could use Windows Azure for this project, there are several reasons why Windows Azure is not the best choice. First, even though the site might only receive a few hits a day, one role instance would have to be continuously running to handles those few requests (note that two instances would be required to achieve the Windows Azure SLA for compute). In Windows Azure, the cost is based on the amount of time that each role instance has been deployed (this is known in Windows Azure nomenclature as compute time); suspending an application does not suspend the consumption of (and charge for) compute time. Even if this site responded to only one hit during the day, it would still be charged for 24 hours of compute time. In a sense, this is rented space on the virtual machine that is running your code. So, at the time of writing this topic, even one extra small instance of a web role would cost $30 a month. And if 20 GB of pictures were stored in blob storage, that storage plus transactions and bandwidth could add another $6 to the cost. The monthly cost of hosting this type of site on Windows Azure is higher than the cost of a simple web hosting solution from

a third party. Most importantly, this type of web site does not require resource management, dynamic scaling, high availability, and durability. Windows Azure allows you to choose only the options that are suited to your business‘ needs. For example, you might find instances in which certain data cannot be hosted in the cloud for legal or regulatory reasons. In these cases, you might consider a hybrid solution, where only certain data or specific parts of your application that are not as sensitive and need to be highly available are hosted in Windows Azure. There are other scenarios that are not well-suited to Windows Azure. By understanding the strengths of Windows Azure, 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 Windows Azure capabilities.

Evaluate Architecture and Development Of course, evaluating a move to Windows Azure involves more than just knowing that your application or business goals are well-suited for the cloud. It is also important to evaluate architectural and development characteristics of your existing or new application. A quick way to start this analysis is to use the Microsoft Assessment Tool (MAT) for Windows Azure. This tool asks questions to determine the types of issues you might have in moving to Windows Azure. Next to each question is a link called "See full consideration", which provides additional information about that specific area in Windows Azure. These questions and the additional information can help to identify potential changes to the design of your existing or new application in the cloud. In addition to the MAT tool, you should have a solid understanding of the basics of the Windows Azure platform. This includes an understanding of common design patterns for the platform. Start by reviewing the Windows Azure videos or reading some of the introductory white papers, such as The Windows Azure Programming Model. Then review the different services available in Windows Azure and consider how they could factor into your solution. For an overview of the Windows Azure services, see the MSDN documentation. It is beyond the scope of this paper to cover all of the possible considerations and mitigations for Windows Azure solutions. However, the following table lists four common design considerations along with links to additional resources. Area

Description

Hybrid Solutions

It can be difficult to move complex legacy applications to Windows Azure. There are also sometimes regulatory concerns with storing certain types of data in the cloud. However, it is possible to create hybrid solutions that

connect services hosted by Windows Azure with on-premises applications and data. There are multiple Windows Azure technologies that support this capability, including Service Bus, Access Control Service, and Windows Azure Connect. For a good video on this subject from October 2010, see Connecting Cloud & On-Premises Apps with the Windows Azure Platform. For hybrid architecture guidance based on real-world customer implementations, see Hybrid Reference Implementation Using BizTalk Server, Windows Azure, Service Bus and Windows Azure SQL Database. State Management

If you are moving an existing application to Windows Azure, one of the biggest considerations is state management. 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 your roles have access to their virtual machine's local drive space and memory, Windows Azure load balances all requests across all role instances. In addition, 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 running role instances is important for the scalability and availability features of Windows Azure. Consequently, application code in the cloud must be designed to store data and state remotely using services such as Windows Azure storage or SQL Database. For more information about storage options, see the resources in the Store and Access Data section of the Windows Azure web site.

Storage Requirements

SQL Database is the relational database solution in Windows Azure. If you currently use SQL Server, the transition to SQL Database should be easier. If you are migrating from another type of database system, there are SQL Server Migration Assistants that can help with this process. For more information on migrating data to SQL Database, see Data Migration to Windows Azure SQL Database: Tools and Techniques. Also consider Windows Azure storage for durable, highly available, and scalable data storage. One good design pattern is to effectively combine the use of SQL Database and Windows Azure storage tables, queues, and blobs. A common example is to use SQL Database to store a pointer to a blob in Windows Azure storage rather than storing the large binary object in the database itself. This is both efficient and cost-effective. For a discussion of storage options, see the article onData Storage Offerings on the Windows Azure Platform.

Interoperability

The easiest application to design or port to Windows Azure is a .NET application. The Windows Azure SDK and tools for Visual Studio greatly simplify the process of creating Windows Azure applications. But what if you are using open source software or third-party development languages and tools? The Windows Azure SDK uses a REST API that is interoperable with many other languages. Of course, there are some challenges to address depending on your technology. For some technologies, you can choose to use a stub .NET project in Visual Studio and overload the Run method for your role. Microsoft provides Windows Azure SDKs for Java and Node.js that you can use to develop and deploy applications. There are also community-created SDKs that interact with Windows Azure. A great resource in this area is the Ineroperability Bridges and Labs Center. Deploying projects that use open source software can also be a challenge. For example, the following blog post discusses options for deploying Ruby applications on Windows Azure:http://blogs.msdn.com/b/silverlining/archive/2011/08/29/deployingruby-java-python-and-node-js-applications-to-windows-azure.aspx. The important point is that Windows Azure is accessible from a variety of languages, so you should look into the options for your particular language of choice before determining whether the application is a good candidate for Windows Azure.

Beyond these issues, you can learn a lot about potential development challenges and solutions by reviewing content on migrating applications to Windows Azure. The Patterns and Practices group at Microsoft published the following guidance on migration: Moving Applications to the Cloud on the Microsoft Windows Azure Platform. You can find additional resources on migration from the Windows Azure web site: Migrate Services and Data.

Summary Windows Azure offers a platform for creating and managing highly scalable and available services. 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 Windows Azure 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. At the end of this analysis, you should have the necessary information to make an informed decision about how to most effectively use Windows Azure to reach your business goals.

LECTURE 3: Main Components of Windows Azure Windows Azure is Microsoft's application platform for the public cloud. You can use this platform in many different ways. For instance, you can use Windows Azure to build a web application that runs and stores its data in Microsoft datacenters. You can use Windows Azure just to store data, with the applications that use this data running on-premises (that is, outside the public cloud). You can use Windows Azure to create virtual machines for development and test or to run SharePoint and other applications. You can use Windows Azure to build massively scalable applications with lots and lots of users. Because the platform offers a wide range of services, all of these things-and more-are possible. To do any of them, though, you need to understand the basics. Even if you don't know anything about cloud computing, this article will walk you through the fundamentals of Windows Azure. The goal is to give you a foundation for understanding and using this cloud platform.

Table of Contents 

The Components of Windows Azure



Execution Models Data Management Networking Business Analytics

          

Messaging Caching Identity High-Performance Computing (HPC) Media Commerce SDKs Getting Started

The Components of Windows Azure To understand what Windows Azure offers, it's useful to group its services into distinct categories. Figure 1 shows one way to do this.

Figure 1: Windows Azure provides Internet-accessible application services running in Microsoft datacenters. To get started with Windows Azure, you need to know at least the basics about each of its components. The rest of this article walks through the technologies shown in the figure, describing what each one offers and when you might use it.

Execution Models One of the most basic things a cloud platform does is execute applications. Windows Azure provides three options for doing this, as Figure 2 shows.

Figure 2: Windows Azure provides Infrastructure as a Service (IaaS), web hosting, and Platform as a Service (PaaS). Each of these three approaches-Virtual Machines, Web Sites, and Cloud Services-can be used separately. You can also combine them to create an application that uses two or more of these options together. Virtual Machines The ability to create a virtual machine on demand, whether from a standard image or from one you supply, can be very useful. Add the ability to pay for this VM by the hour, and it's even more useful. This approach, commonly known as Infrastructure as a Service (IaaS), is what Windows Azure Virtual Machines provides. To create a VM, you specify which VHD to use and the VM's size. You then pay for each hour the VM is running. As Figure 2 shows, Windows Azure Virtual Machines offers a gallery of standard VHDs. These include Microsoft-provided options, such as Windows Server 2008 R2, Windows Server 2012, and Windows Server 2008 R2 with SQL Server, along with Linux images provided by Microsoft partners. You're free to upload and create VMs from your own VHDs as well. Wherever the image comes from, you can persistently store any changes made while a VM is running. The next time you create a VM from that VHD, things pick up where you left off. It's also possible to copy the changed VHD out of Windows Azure, then run it locally. Windows Azure VMs can be used in many different ways. You might use them to create an inexpensive development and test platform that you can shut down when you've finished using it. You might also create and run applications that use whatever languages and libraries you like. Those applications can use any of the data management options that

Windows Azure provides, and you can also choose to use SQL Server or another DBMS running in one or more virtual machines. Another option is to use Windows Azure VMs as an extension of your on-premises datacenter, running SharePoint or other applications. To support this, it's possible to create Windows domains in the cloud by running Active Directory in Windows Azure VMs. This quite general approach to cloud computing can be used to address many different problems. What you do is up to you. Web Sites One of the most common things that people do in the cloud is run websites and web applications. Windows Azure Virtual Machines allows this, but it still leaves you with the responsibility of administering one or more VMs. What if you just want a website where somebody else takes care of the administrative work for you? This is exactly what Windows Azure Web Sites provides. This execution model offers a managed web environment using Internet Information Services (IIS). You can move an existing IIS website into Windows Azure Web Sites unchanged, or you can create a new one directly in the cloud. Once a website is running, you can add or remove instances dynamically, relying on Web Sites to load balance requests across them. And as Figure 2 shows, Windows Azure Web Sites offers both a shared option, where your website runs in a virtual machine with other sites, and a way for a site to run in its own VM. Windows Azure Web Sites is intended to be useful for both developers and web design agencies. For development, it supports .NET, PHP, and Node.js, along with SQL Database and (from ClearDB, a Microsoft partner) MySQL for relational storage. It also provides built-in support for several popular applications, including WordPress, Joomla, and Drupal. The goal is to provide a low-cost, scalable, and broadly useful platform for creating websites and web applications in the public cloud. Cloud Services Suppose you want to build a cloud application that can support lots of simultaneous users, doesn't require much administration, and never goes down. You might be an established software vendor, for example, that's decided to embrace Software as a Service (SaaS) by building a version of one of your applications in the cloud. Or you might be a start-up creating a consumer application that you expect will grow fast. If you're building on Windows Azure, which execution model should you use? Windows Azure Web Sites allows creating this kind of web application, but there are some constraints. You don't have administrative access, for example, which means that you can't install arbitrary software. Windows Azure Virtual Machines gives you lots of flexibility, including administrative access, and you certainly can use it to build a very scalable application, but you'll have to handle many aspects of reliability and administration yourself. What you'd like is an option that gives you the control you need but also handles most of the work required for reliability and administration.

This is exactly what's provided by Windows Azure Cloud Services. This technology is designed expressly to support scalable, reliable, and low-admin applications, and it's an example of what's commonly called Platform as a Service (PaaS). To use it, you create an application using the technology you choose, such as C#, Java, PHP, Python, Node.js, or something else. Your code then executes in virtual machines (referred to as instances) running a version of Windows Server. But these VMs are distinct from the ones you create with Windows Azure Virtual Machines. For one thing, Windows Azure itself manages them, doing things like installing operating system patches and automatically rolling out new patched images. (This implies that your application shouldn't maintain state in web or worker role instances; it should instead be kept in one of the Windows Azure data management options described in the next section.) Windows Azure also monitors the VMs, restarting any that fail. As Figure 2 shows, you have two roles to choose from when you create an instance, both based on Windows Server. The main difference between the two is that an instance of a web role runs IIS, while an instance of a worker role does not. Both are managed in the same way, however, and it's common for an application to use both. For example, a web role instance might accept requests from users, then pass them to a worker role instance for processing. To scale your application up or down, you can request that Windows Azure create more instances of either role or shut down existing instances. And just like Windows Azure Virtual Machines, you're charged by the hour for each web or worker role instance. Each of the three Windows Azure execution models has its own role to play. Windows Azure Virtual Machines provides a general-purpose computing environment, Windows Azure Web Sites offers low-cost web hosting, and Windows Azure Cloud Services is the best choice for creating scalable, reliable applications with low administration costs. And as mentioned earlier, you can use these technologies separately or combine them as needed to create the right foundation for your application. The approach you choose depends on what problems you're trying to solve.

Data Management Applications need data, and different kinds of applications need different kinds of data. Because of this, Windows Azure provides several different ways to store and manage data. One of these has already been mentioned: the ability to run SQL Server or another DBMS in a VM created with Windows Azure Virtual Machines. (It's important to realize that this option isn't limited to relational systems; you're also free to run NoSQL technologies such as MongoDB and Cassandra.) Running your own database system is straightforward-it replicates what we're used to in our own datacenters-but it also requires handling the administration of that DBMS. To make life easier, Windows Azure provides three data management options that are largely managed for you. Figure 3 shows the choices.

Figure 3: For data management, Windows Azure provides relational storage, scalable NoSQL tables, and unstructured binary storage. Each of the three options addresses a different need: relational storage, fast access to potentially large amounts of simple typed data, and unstructured binary storage. In all three cases, data is automatically replicated across three different computers in a Windows Azure datacenter to provide high availability. It's also worth pointing out that all three options can be accessed either by Windows Azure applications or by applications running elsewhere, such as your on-premises datacenter, your laptop, or your phone. And however you apply them, you pay for all Windows Azure data management services based on usage, including a gigabyte-per-month charge for stored data. SQL Database For relational storage, Windows Azure provides SQL Database. Formerly called SQL Azure, SQL Database provides all of the key features of a relational database management system, including atomic transactions, concurrent data access by multiple users with data integrity, ANSI SQL queries, and a familiar programming model. Like SQL Server, SQL Database can be accessed using Entity Framework, ADO.NET, JDBC, and other familiar data access technologies. It also supports most of the T-SQL language, along with SQL Server tools such as SQL Server Management Studio. For anybody familiar with SQL Server (or another relational database), using SQL Database is straightforward. But SQL Database isn't just a DBMS in the cloud-it's a PaaS service. You still control your data and who can access it, but SQL Database takes care of the administrative grunt work, such as managing the hardware infrastructure and automatically keeping the database and operating system software up to date. SQL Database also provides a federation option that distributes data across multiple servers. This is useful for applications that work with large amounts of data or need to spread data access requests across multiple servers for better performance. If you're creating a Windows Azure application (using any of the three execution models) that needs relational storage, SQL Database can be a good option. Applications running outside the cloud can also use this service, though, so there are plenty of other scenarios. For instance, data stored in SQL Database can be accessed from different client systems,

including desktops, laptops, tablets, and phones. And because it provides built-in high availability through replication, using SQL Database can help minimize downtime. Tables Suppose you want to create a Windows Azure application that needs fast access to typed data, maybe lots of it, but doesn't need to perform complex SQL queries on this data. For example, imagine you're creating a consumer application that needs to store customer profile information for each user. Your app is going to be very popular, so you need to allow for lots of data, but you won't do much with this data beyond storing it, then retrieving it in simple ways. This is exactly the kind of scenario where Windows Azure Tables makes sense. Don't be confused by the name: this technology doesn't provide relational storage. (In fact, it's an example of a NoSQL approach called a key/value store.) Instead, Windows Azure Tables let an application store properties of various types, such as strings, integers, and dates. An application can then retrieve a group of properties by providing a unique key for that group. While complex operations like joins aren't supported, tables offer fast access to typed data. They're also very scalable, with a single table able to hold as much as a terabyte of data. And matching their simplicity, tables are usually less expensive to use than SQL Database's relational storage. Blobs The third option for data management, Windows Azure Blobs, is designed to store unstructured binary data. Like Tables, Blobs provides inexpensive storage, and a single blob can be as large as one terabyte. An application that stores video, for example, or backup data or other binary information can use blobs for simple, cheap storage. Windows Azure applications can also use Windows Azure drives, which let blobs provide persistent storage for a Windows file system mounted in a Windows Azure instance. The application sees ordinary Windows files, but the contents are actually stored in a blob.

Networking Windows Azure runs today in several datacenters spread across the United States, Europe, and Asia. When you run an application or store data, you can select one or more of these datacenters to use. You can also connect to these datacenters in various ways: 

You can use Windows Azure Virtual Network to connect your own on-premises local network to a defined set of Windows Azure VMs.



You can use Windows Azure Connect to link one or more on-premises Windows servers to a specific Windows Azure application.



If your Windows Azure application is running in multiple datacenters, you can use Windows Azure Traffic Manager to route requests from users intelligently across instances of the application.

Figure 4 illustrates these three options.

Figure 4: Windows Azure allows creating a cloud VPN, connecting a Windows Azure application to on-premises machines, and intelligently distributing user requests across different datacenters. Virtual Network One useful way to use a public cloud is to treat it as an extension of your own datacenter. Because you can create VMs on demand, then remove them (and stop paying) when they're no longer needed, you can have computing power only when you want it. And since Windows Azure Virtual Machines lets you can create VMs running SharePoint, Active Directory, and other familiar on-premises software, this approach can work with the applications you already have. To make this really useful, though, your users ought to be able to treat these applications as if they were running in your own datacenter. This is exactly what Windows Azure Virtual Network allows. Using a VPN gateway device, an administrator can set up a virtual private network (VPN) between your local network and a defined group of VMs running in Windows Azure. Because you assign your own IP v4 addresses to the cloud VMs, they appear to be on your own network. Users in your organization can access the applications those VMs contain as if they were running locally. Connect

Creating a VPN between your local network and a group of VMs in the cloud is useful, but it also requires VPN gateway hardware and the services of a network administrator. Suppose you're a developer who just wants to connect a single Windows Azure application to a specific group of Windows machines within your organization. Perhaps you've built a Cloud Services application that needs to access a database on one of those servers, for example, and you don't want to go to the trouble of configuring a VPN gateway. Windows Azure Connect is designed for this situation. Connect provides a simple way to establish a secure connection between a Windows Azure application and a group of computers running Windows. A developer just installs the Connect software on the onpremises machines-there's no need to involve a network administrator-and configures the Windows Azure application. Once this is done, the application can communicate with the onpremises computers as if they were on the same local network. Traffic Manager A Windows Azure application with users in just a single part of the world might run in only one Windows Azure datacenter. An application with users scattered around the world, however, is more likely to run in multiple datacenters, maybe even all of them. In this second situation, you face a problem: How do you intelligently assign users to application instances? Most of the time, you probably want each user to access the datacenter closest to her, since it will likely give her the best response time. But what if that copy of the application is overloaded or unavailable? In this case, it would be nice to route her request automatically to another datacenter. This is exactly what's done by Windows Azure Traffic Manager. The owner of an application defines rules that specify how requests from users should be routed to datacenters, then relies on Traffic Manager to carry out these rules. For example, users might normally be routed to the closest Windows Azure datacenter, but get sent to another one when the response time from their default datacenter exceeds a certain threshold. For globally distributed applications with many users, having a built-in service to handle problems like these is useful.

Business Analytics Analyzing data is a fundamental part of how businesses use information technology. A cloud platform provides a pool of on-demand, pay-per-use resources, which makes it a good foundation for this kind of computing. Accordingly, Windows Azure provides two options for business analytics. Figure 5 illustrates the choices.

Figure 5: For business analytics, Windows Azure provides reporting and support for big data. Analyzing data can take many forms, and so these two options are quite different. It's worth looking at each one separately. SQL Reporting One of the most common ways to use stored data is to create reports based on that data. To let you do this with data in SQL Database, Windows Azure provides SQL Reporting. A subset of the reporting services included with SQL Server, SQL Reporting lets you build reporting into applications running on Windows Azure or on premises. The reports you create can be in various formats, including HTML, XML, PDF, Excel, and others, and they can be embedded in applications or viewed via a web browser. Another option for doing analytics with SQL Database data is to use on-premises business intelligence tools. To a client, SQL Database looks like SQL Server, and so the same technologies can work with both. For example, you're free to use on-premises SQL Server Reporting Services to create reports from SQL Database data. Hadoop For many years, the bulk of data analysis has been done on relational data stored in a data warehouse built with a relational DBMS. This kind of business analytics is still important, and it will be for a long time to come. But what if the data you want to analyze is so big that relational databases just can't handle it? And suppose the data isn't relational? It might be server logs in a datacenter, for example, or historical event data from sensors, or something else. In cases like this, you have what's known as a big data problem. You need another approach. The dominant technology today for analyzing big data is Hadoop. An Apache open source project, this technology stores data using the Hadoop Distributed File System (HDFS), then

lets developers create MapReduce jobs to analyze that data. HDFS spreads data across multiple servers, then runs chunks of the MapReduce job on each one, letting the big data be processed in parallel. As Figure 5 suggests, the Apache Hadoop-based Service for Windows Azure lets HDFS distribute data across multiple virtual machines, then spreads the logic of a MapReduce job across those VMs. Just as with on-premises Hadoop, data is processed locally-the logic and the data it works on are in the same VM-and in parallel for better performance. The Apache Hadoop-based Service for Windows Azure supports other components of the technology as well, including Hive and Pig, and Microsoft has also created an Excel plug-in for issuing Hive queries.

Messaging No matter what it's doing, code frequently needs to interact with other code. In some situations, all that's needed is basic queued messaging. In other cases, more complex interactions are required. Windows Azure provides a few different ways to solve these problems. Figure 6 illustrates the choices.

Figure 6: For connecting applications, Windows Azure provides queues, publish/subscribe, and synchronous connections via the cloud. Queues Queuing is a simple idea: One application places a message in a queue, and that message is eventually read by another application. If your application needs just this straightforward service, Windows Azure Queues might be the best choice.

One common use of Queues today is to let a web role instance communicate with a worker role instance within the same Cloud Services application. For example, suppose you create a Windows Azure application for video sharing. The application consists of PHP code running in a web role that lets users upload and watch videos, together with a worker role implemented in C# that translates uploaded video into various formats. When a web role instance gets a new video from a user, it can store the video in a blob, then send a message to a worker role via a queue telling it where to find this new video. A worker role instance-it doesn't matter which one-will then read the message from the queue and carry out the required video translations in the background. Structuring an application in this way allows asynchronous processing, and it also makes the application easier to scale, since the number of web role instances and worker role instances can be varied independently. Service Bus Whether they run in the cloud, in your data center, on a mobile device, or somewhere else, applications need to interact. The goal of Windows Azure Service Bus is to let applications running pretty much anywhere exchange data. As Figure 6 shows, Service Bus provides a queuing service. This service isn't identical to the Queues just described, however. Unlike Windows Azure Queues, for example, Service Bus provides a publish-and-subscribe mechanism. An application can send messages to a topic, while other applications can create subscriptions to this topic. This allows one-to-many communication among a set of applications, letting the same message be read by multiple recipients. And queuing isn't the only option: Service Bus also allows direct communication through its relay service, providing a secure way to interact through firewalls. Applications that communicate through Service Bus might be Windows Azure applications or software running on some other cloud platform. They can also be applications running outside the cloud, however. For example, think of an airline that implements reservation services in computers inside its own datacenter. The airline needs to expose these services to many clients, including check-in kiosks in airports, reservation agent terminals, and maybe even customers' phones. It might use Service Bus to do this, creating loosely coupled interactions among the various applications.

Caching Applications tend to access the same data over and over. One way to improve performance is to keep a copy of that data closer to the application, minimizing the time needed to retrieve it. Windows Azure provides two different services for doing this: in-memory caching of data used by Windows Azure applications and a content delivery network (CDN) that caches blob data on disk closer to its users. Figure 7 shows both.

Figure 7: A Windows Azure application can cache data in memory, and copies of a blob can be cached at sites around the world. Caching Accessing data stored in any of Windows Azure's data management services-SQL Database, Tables, or Blobs-is quite fast. Yet accessing data stored in memory is even faster. Because of this, keeping an in-memory copy of frequently accessed data can improve application performance. You can use Windows Azure's in-memory Caching to do this. A Cloud Services application can store data in this cache, then retrieve it directly without needing to access persistent storage. As Figure 7 shows, the cache can be maintained inside your application's VMs or be provided by VMs dedicated solely to caching. In either case, the cache can be distributed, with the data it contains spread across multiple VMs in a Windows Azure datacenter. An application that repeatedly reads a product catalog might benefit from using this kind of caching, for example, since the data it needs will be available more quickly. The technology also supports locking, letting it be used with read/write as well as read-only data. And ASP.NET applications can use the service to store session data with just a configuration change. CDN Suppose you need to store blob data that will be accessed by users around the world. Maybe it's a video of the latest World Cup match, for instance, or driver updates, or a popular e-

book. Storing a copy of the data in multiple Windows Azure datacenters will help, but if there are lots of users, it's probably not enough. For even better performance, you can use the Windows Azure CDN. The CDN has dozens of sites around the world, each capable of storing copies of Windows Azure blobs. The first time a user in some part of the world accesses a particular blob, the information it contains is copied from a Windows Azure datacenter into local CDN storage in that geography. After this, accesses from that part of the world will use the blob copy cached in the CDN-they won't need to go all the way to the nearest Windows Azure datacenter. The result is faster access to frequently accessed data by users anywhere in the world.

Identity Working with identity is part of most applications. For example, knowing who a user is lets an application decide how it should interact with that user. To help you do this, Microsoft provides Windows Azure Active Directory. Like most directory services, Windows Azure Active Directory stores information about users and the organizations they belong to. It lets users log in, then supplies them with tokens they can present to applications to prove their identity. It also allows synchronizing user information with Windows Server Active Directory running on premises in your local network. While the mechanisms and data formats used by Windows Azure Active Directory aren‘t identical with those used in Windows Server Active Directory, the functions it performs are quite similar. It's important to understand that Windows Azure Active Directory is designed primarily for use by cloud applications. It can be used by applications running on Windows Azure, for example, or on other cloud platforms. It's also used by Microsoft's own cloud applications, such as those in Office 365. If you want to extend your datacenter into the cloud using Windows Azure Virtual Machines and Windows Azure Virtual Network, however, Windows Azure Active Directory isn't the right choice. Instead, you'll want to run Windows Server Active Directory in cloud VMs, as described earlier. To let applications access the information it contains, Windows Azure Active Directory provides a RESTful API called Windows Azure Active Directory Graph. This API lets applications running on any platform access directory objects and the relationships among them. For example, an authorized application might use this API to learn about a user, the groups he belongs to, and other information. Applications can also see relationships between users-their social graph-letting them work more intelligently with the connections among people. Another capability of this service, Windows Azure Active Directory Access Control, makes it easier for an application to accept identity information from Facebook, Google, Windows Live ID, and other popular identity providers. Rather than requiring the application to understand

the diverse data formats and protocols used by each of these providers, Access Control translates all of them into a single common format. It also lets an application accept logins from one or more Active Directory domains. For example, a vendor providing a SaaS application might use Windows Azure Active Directory Access Control to give users in each of its customers single sign-on to the application. Directory services are a core underpinning of on-premises computing. It shouldn't be surprising that they're also important in the cloud.

High-Performance Computing One of the most attractive ways to use a cloud platform is for high-performance computing (HPC), The essence of HPC is executing code on many machines at the same time. On Windows Azure, this means running many virtual machines simultaneously, all working in parallel to solve some problem. Doing this requires some way to schedule applications, i.e., to distribute their work across these instances. To allow this, Windows Azure provides the HPC Scheduler. This component can work with HPC applications built to use the industry-standard Message Passing Interface (MPI). Software that does finite element analysis, such as car crash simulations, is one example of this type of application, and there are many others. The HPC Scheduler can also be used with so-called embarrassingly parallel applications, such as Monte Carlo simulations. Whatever problem is addressed, the value it provides is the same: The HPC Scheduler handles the complex problem of scheduling parallel computing work across many Windows Azure virtual machines. The goal is to make it easier to build HPC applications running in the cloud.

Media Video makes up a large part of Internet traffic today, and that percentage will be even larger tomorrow. Yet providing video on the web isn't simple. There are lots of variables, such as the encoding algorithm and the display resolution of the user's screen. Video also tends to have bursts in demand, like a Saturday night spike when lots of people decide they'd like to watch an online movie. Given its popularity, it's a safe bet that many new applications will be created that use video. Yet all of them will need to solve some of the same problems, and making each one solve those problems on its own makes no sense. A better approach is to create a platform that provides common solutions for many applications to use. And building this platform in the cloud has some clear advantages. It can be broadly available on a pay-as-you-go basis, and it can also handle the variability in demand that video applications often face.

Windows Azure Media Services addresses this problem. It provides a set of cloud components that make life easier for people creating and running applications using video and other media. Figure 8 illustrates the technology.

Figure 8: Media Services is a platform for applications that provide video and other media to clients around the world. As the figure shows, Media Services provides a set of components for applications that work with video and other media. For example, it includes a media ingest component to upload video into Media Services (where it's stored in Windows Azure Blobs), an encoding component that supports various video and audio formats, a content protection component that provides digital rights management, a component for inserting ads into a video stream, components for streaming, and more. Microsoft partners can also provide components for the platform, then have Microsoft distribute those components and bill on their behalf. Applications that use this platform can run on Windows Azure or elsewhere. For example, a desktop application for a video production house might let its users upload video to Media Services, then process it in various ways. Alternatively, a cloud-based content management service running on Windows Azure might rely on Media Services to process and distribute video. Wherever it runs and whatever it does, each application chooses which components it needs to use, accessing them through RESTful interfaces. To distribute what it produces, an application can use the Windows Azure CDN, another CDN, or just send bits directly to users. However it gets there, video created using Media Services can be consumed by various client systems, including Windows, Macintosh, HTML 5, iOS, Android, Windows Phone, Flash, and Silverlight. The goal is to make it easier to create modern media applications.

Commerce The rise of Software as a Service is transforming how we create applications. It's also transforming how we sell applications. Since a SaaS application lives in the cloud, it makes sense that its potential customers should look for solutions online. And this change applies

to data as well as to applications. Why shouldn't people look to the cloud for commercially available datasets? Microsoft addresses both of these concerns with Windows Azure Marketplace, illustrated in Figure 9.

Figure 9: Windows Azure Marketplace lets you find and buy Windows Azure applications and commercial datasets. Potential customers can search the Marketplace to find Windows Azure applications that meet their needs, then sign up to use them either through the application's creator or directly through the Marketplace. Customers can search the Marketplace for commercial datasets as well, including demographic data, financial data, geographic data, and more. When they find something they like, they can access it either from the vendor or directly through the Marketplace. Applications can also use the Bing Search API through the Marketplace, giving them access to the results of web searches.

SDKs Back in 2008, the very first pre-release version of Windows Azure supported only .NET development. Today, however, you can create Windows Azure applications in pretty much any language. Microsoft currently provides language-specific SDKs for .NET, Java, PHP, Node.js, and Python. There's also a general Windows Azure SDK that provides basic support for any language, such as C++. These SDKs help you build, deploy, and manage Windows Azure applications. They're available either from www.windowsazure.com or GitHub, and they can be used with Visual Studio and Eclipse. Windows Azure also offers command line tools that developers can use

with any editor or development environment, including tools for deploying applications to Windows Azure from Linux and Macintosh systems. Along with helping you build Windows Azure applications, these SDKs also provide client libraries that help you create software running outside the cloud that uses Windows Azure services. For example, you might build an application running at a hoster that relies on Windows Azure blobs, or create a tool that deploys Windows Azure applications through the Windows Azure management interface.

Getting Started Now that you have the big-picture, the next step is to write your first Windows Azure application. Choose your language, get the appropriate SDK, and go for it. Cloud computing is the new default--get started now.

Failsafe: Guidance for Resilient Cloud Architectures 11 out of 11 rated this helpful - Rate this topic Authors: Marc Mercuri, Ulrich Homann, and Andrew Townhill Publish date: November 2012

Introduction Fail-safe noun. Something designed to work or function automatically to prevent breakdown of a mechanism, system, or the like. Individuals - whether in the context of employee, citizen, or consumer – demand instant access to application, compute and data services. The number of people connected and the devices they use to connect to these services are ever growing. In this world of always-on services, the systems that support them must be designed to be both available and resilient. The Fail-Safe initiative within Microsoft is intended to deliver general guidance for building resilient cloud architectures, guidance for implementing those architectures on Microsoft technologies, and recipes for implementing these architectures for specific scenarios. The authors of this document are part of Microsoft‘s Services organization, with contributions from and collaboration with members of the Customer Advisory Team (CAT) within the product group. This document focuses on the architectural considerations for designing scalable and resilient systems. This paper is organized into the following sections:



Decompose the Application by Workload: Defining how a workload-centric approach provides better controls over costs, more flexibility in choosing technologies best suited to the workload, and enables a more finely tuned approach to availability and resiliency.



Establish a Lifecycle Model: Establishing an application lifecycle model helps define the expected behavior of an application in production and will provide requirements and insight for the overall architecture.



Establish an Availability Model and Plan: The availability model identifies the level of availability that is expected for your workload. It is critical as it will inform many of the decisions you‘ll make when establishing your service.



Identify Failure Points and Failure Modes: To create a resilient architecture, it‘s important to understand and identify failure points and modes. Specifically, making a proactive effort to understand and document what can cause an outage will establish an outline that can be used in analysis and planning.



Resiliency Patterns and Considerations: This section represents the majority of the document, and contains key considerations across compute, storage, and platform services. These considerations focus on proven practices to deliver a healthy application at key considerations across compute, storage, and platform services.



Design for Operations: In a world that expects services to be ―always on‖, it‘s important that services be designed for operations. This section looks at proven practices for designing for operations that span the lifecycle, including establishing a health model to implementing telemetry to visualizing that telemetry information for the operations and developer audiences.

Decompose the Application by Workload Applications are typically composed of multiple workloads. When looking at Microsoft products, you can see that products such as SharePoint and Windows Server are designed with this principle in mind.

Different workloads can, and often do, have different requirements, different levels of criticality to the business, and different levels of financial consideration associated with them. By decomposing an application into workloads, an organization provides itself with valuable flexibility. A workload-centric approach provides better controls over costs, more flexibility in choosing technologies best suited to the workload, workload specific approaches to availability and security, flexibility and agility in adding and deploying new capabilities, etc.

Scenarios When thinking about resiliency, it‘s sometimes helpful to do so in the context of scenarios. The following are examples of typical scenarios:



Scenario 1 – Sports Data Service A customer provides a data service that provides sports information. The service has two primary workloads. The first provides statistics for the player and teams. The second provides scores and commentary for games that are currently in progress.



Scenario 2 – E-Commerce Web Site An online retailer sells goods via a website in a well-established model. The application has a number of workloads, with the most popular being ―search and browse‖ and ―checkout.‖



Scenario 3 – Social A high profile social site allows members of a community to engage in shared experiences around forums, user generated content, and casual gaming. The application has a number of workloads, including registration, search and browse, social interaction, gaming, email, etc.



Scenario 4 - Web An organization wishes to provide an experience to customers via its web site. The application needs to deliver experiences on both PC-based browsers as well as popular mobile device types (phone, tablet) The application has a number of workloads including registration, search and browse, content publishing, social commenting, moderation, gaming, etc.

Example of Decomposing by Workload Let‘s take a closer look at one of the scenarios and decompose it into its child workloads. Scenario #2, an ecommerce web site, could have a number of workloads – browse & search, checkout & management, user registration, user generated content (reviews and rating), personalization, etc. Example definitions of two of the core workloads for the scenario would be:



Browse & Search enables customers to navigate through a product catalog, search for specific items, and perhaps manage baskets or wish lists. This workload can have attributes such as anonymous user access, sub-second response times, and caching. Performance degradation may occur in the form of increased response times with unexpected user load or application-tolerant interrupts for product inventory refreshes. In those cases, the application may choose to continue to serve information from the cache.



Checkout & Management helps customers place, track, and cancel orders; select delivery methods and payment options; and manage profiles. This workload can have attributes such as secure access, queued processing, access to third-party payment gateways, and connectivity to back-end on-premise systems. While the application may tolerate increased response time, it may not tolerate loss of orders; therefore, it is designed to guarantee that customer orders are always accepted and captured, regardless of whether the application can process the payment or arrange delivery.

Establish a Lifecycle Model

An application lifecycle model defines the expected behavior of an application when operational. At different phases and times, an application will put different demands on the system whether at a functional or scale level. The lifecycle model(s) will reflect this. Workloads should have defined lifecycle models for all relevant and applicable scenarios. Services may have hourly, daily, weekly, or seasonal lifecycle differences that, when modeled, identify specific capacity, availability, performance, and scalability requirements over time. Many services will have a minimum of two applicable models, particularly if service demand bursts in a predictable fashion. Whether it‘s a spike related to peak demand during a holiday period, increased filing of tax returns just before their due date, morning and afternoon commuter time windows, or end-of-year filing of employee performance reviews, many organizations have an understanding of predictable spike in demand for a service that should be modeled.

Figure 1. A view of the lifecycle model on a month by month basis

Figure 2. A look at the lifecycle model more granularly, at the daily level

Establish an Availability Model and Plan Once a lifecycle model is identified, the next step is to establish an availability model and plan. An availability model for your application identifies the level of availability that is expected for your workload. It is critical as it will inform many of the decisions you‘ll make when establishing your service. There are a number of things consider and a number of potential actions that can be taken.

SLA Identification When developing your availability plan, it‘s important to understand what the desired availability is for your application, the workloads within that application, and the services that are utilized in the delivery of those workloads.

Defining the Desired SLA for Your Workload

Understanding the lifecycle of your workload will help you understand the desired Service Level Agreement that you‘d like to deliver. Even if an SLA is not provided for your service publicly, this is the baseline to which you‘ll aspire to meet in terms of availability. There are a number of options that can be taken that will provide scalability and resiliency. These can take varying costs and contain multiple layers. At an application level, utilizing all of these is unfeasible for most projects due to cost and implementation time. By decomposing your application to the workload level, you gain a benefit that you can make these investments at a more targeted level, the workload. Even at the workload level, you may not choose to implement every option. What you choose to implement or not is determined by your requirements. Regardless of the options you do choose, you should make a conscious choice that‘s informed and considerate of all of the options.

Autonomy Autonomy is about independence and reducing dependency between the parts which make up the service as a whole. Dependency on components, data, and external entities must be examined when designing services, with an eye toward building related functionality into autonomous units within the service. Doing so provides the agility to update versions of distinct autonomous units, finer tuned control of scaling these autonomous units, etc. Workload architectures are often composed of autonomous components that do not rely on manual intervention, and do not fail when the entities they depend upon are not available. Applications composed of autonomous parts are:



available and operational



resilient and easily fault-recoverable



lower-risk for unhealthy failure states



easy to scale through replication



less likely to require manual interventions These autonomous units will often leverage asynchronous communication, pull-based data processing, and automation to ensure continuous service. Looking forward, the market will evolve to a point where there are standardized interfaces for certain types of functionality for both vertical and horizontal scenarios. When this future vision is realized, a service provider will be able to engage with different providers and potentially different implementations that solve the designated work of the autonomous unit. For continuous services, this will be done autonomously and be based on policies. As much as autonomy is an aspiration, most services will take a dependency on a third party service – if only for hosting. It‘s imperative to understand the SLAs of these dependent services and incorporate them into your availability plan.

+Understanding the SLAs and Resiliency Options for Service Dependencies This section identifies the different types of SLAs that can be relevant to your service. For each of these service types, there are key considerations and approaches, as well as questions that should be asked. Public Cloud Platform Services Services provided by a commercial cloud computing platform, such as compute or storage, have service level agreements that are designed to accommodate a multitude of customers at significant scale. As such, the SLAs for these services are non-negotiable. A provider may provide tiered levels of service with different SLAs, but these tiers will be non-negotiable.

Questions to consider for this type of service:



Does this service allow only a certain number of calls to the Service API?



Does this service place limit on the call frequency to the Service API?



Does the service limit the number of servers that can call the Service API?



What is the publicly available information on how the service delivers on its availability promise?



How does this service communicate its health status?



What is the stated Service Level Agreement (SLA)?



What are the equivalent platform services provided by other 3rd parties? 3rd Party ―Free‖ Services Many third parties provide ―free‖ services to the community. For private sector organizations, this is largely done to help generate an ecosystem of applications around their core product or service. For public sector, this is done to provide data to the citizenry and businesses that have ostensibly have paid for its collection through the funding of the government through taxes. Most of these services will not come with service level agreements, so availability is not guaranteed. When SLAs are provided, they typically focus on restrictions that are placed on consuming applications and mechanisms that will be used to enforce them. Examples of restrictions can include throttling or blacklisting your solution if it exceeds a certain number of service calls, exceeds a certain number of calls in a given time period (x per minute), or exceeds the number of allowable servers that are calling the service. Questions to consider for this type of service:



Does this service allow only a certain number of calls to the Service API?



Does this service place limits on the call frequency to the Service API?



Does the service limit the number of servers that can call the Service API?



What is the publicly available information on how the service delivers on its availability promise?



How does this service communicate its health status?



What is the stated Service Level Agreement (SLA)?



Is this a commodity service where the required functionality and/or data are available from multiple service providers?



If a commodity service, is the interface interoperable across other service providers (directly or through an available abstraction layer)?



What are the equivalent platform services provided by other 3rd parties? 3rd Party Commercial Services Commercial services provided by third parties have service level agreements that are designed to accommodate the needs of paying customers. A provider may provide tiered levels of SLAs with different levels of availability, but these SLAs will be non-negotiable. Questions to consider for this type of service:



Does this service allow only a certain number of calls to the Service API?



Does this service place limits on the call frequency to the Service API?



Does the service limit the number of servers that can call the Service API?



What is the publicly available information on how the service delivers on its availability promise?



How does this service communicate its health status?



What is the stated Service Level Agreement (SLA)?



Is this a commodity service where the required functionality and/or data are available from multiple service providers?



If a commodity service, is the interface interoperable across other service providers (directly or through an available abstraction layer)?



What are the equivalent platform services provided by other 3rd parties? Community Cloud Services A community of organizations, such as a supply chain, may make services available to member organizations. Questions to consider for this type of service:



Does this service allow only a certain number of calls to the Service API?



Does this service place limits on the call frequency to the Service API?



Does the service limit the number of servers that can call the Service API?



What is the publicly available information on how the service delivers on its availability promise?



How does this service communicate its health status?



What is the stated Service Level Agreement (SLA)?



As a member of the community, is there a possibility of negotiating a different SLA?



Is this a commodity service where the required functionality and/or data are available from multiple service providers?



If a commodity service, is the interface interoperable across other service providers (directly or through an available abstraction layer)?



What are the equivalent platform services provided by other 3rd parties? 1st Party Internal Enterprise Wide Cloud Services An enterprise may make core services, such as stock price data or product metadata, available to its divisions and departments. Questions to consider for this type of service:



Does this service allow only a certain number of calls to the Service API?



Does this service place limits on the call frequency to the Service API?



Does the service limit the number of servers that can call the Service API?



What is the publicly available information on how the service delivers on its availability promise?



How does this service communicate its health status?



What is the stated Service Level Agreement (SLA)?



As a member of the organization, is there a possibility of negotiating a different SLA?



Is this a commodity service where the required functionality and/or data are available from multiple service providers?



If a commodity service, is the interface interoperable across other service providers (directly or through an available abstraction layer)?



What are the equivalent platform services provided by other 3rd parties? 1st Party Internal Divisional or Departmental Cloud Services An enterprise division or department may make services available to other members of their immediate organization. Questions to consider for this type of service:



Does this service allow only a certain number of calls to the Service API?



Does this service place limits on the call frequency to the Service API?



Does the service limit the number of servers that can call the Service API?



What is the publicly available information on how the service delivers on its availability promise?



How does this service communicate its health status?



What is the stated Service Level Agreement (SLA)?



As a member of the division, is there a possibility of negotiating a different SLA?



Is this a commodity service where the required functionality and/or data are available from multiple service providers?



If a commodity service, is the interface interoperable across other service providers (directly or through an available abstraction layer)?



What are the equivalent platform services provided by other 3rd parties? The ―True 9s‖ of Composite Service Availability Taking advantage of existing services can provide significant agility in delivering solutions for your organization or for commercial sale. While attractive, it is important to truly understand the impacts these dependencies have on the overall SLA for the workload. Availability is typically expressed as a percentage of uptime in a given year. This is expressed availability percentage is referred to as the number of ―9s.‖ For example, 99.9 represents a service with ―three nines‖ and 99.999 represents a service with ―five nines.‖

Availability %

Downtime per year

Downtime per month

Downtime per week

90% ("one nine")

36.5 days

72 hours

16.8 hours

95%

18.25 days

36 hours

8.4 hours

97%

10.96 days

21.6 hours

5.04 hours

98%

7.30 days

14.4 hours

3.36 hours

99% ("two nines")

3.65 days

7.20 hours

1.68 hours

99.5%

1.83 days

3.60 hours

50.4 minutes

99.8%

17.52 hours

86.23 minutes

20.16 minutes

99.9% ("three nines")

8.76 hours

43.2 minutes

10.1 minutes

99.95%

4.38 hours

21.56 minutes

5.04 minutes

99.99% ("four nines")

52.56 minutes

4.32 minutes

1.01 minutes

99.999% ("five nines")

5.26 minutes

25.9 seconds

6.05 seconds

99.9999% ("six nines")

31.5 seconds

2.59 seconds

0.605 seconds

99.99999% ("seven nines")

3.15 seconds

.259 seconds

0.0605 seconds

Figure 3. Downtime related to the more common ―9s‖ One common misconception is related to the number of ―9s‖ for a composite service provides. Specifically, it is often assumed that if a given service is composed of 5 services, each with a promised 99.999 uptime in their SLAs, that the resulting composite service has availability of 99.999. This is not the case. The percentage is actually a calculation which considers the amount of downtime per year. A service with an SLA of ―four 9s‖ (99.99%) can be offline up to 52.56 minutes. Incorporating 5 of these services into a composite introduces an identified SLA risk of 262.8 minutes or 4.38 hours. This reduces the availability to 99.95% before a single line of code is written! You generally can‘t change the availability of a third-party service; however, when writing your code, you can increase the overall availability of your application using concepts laid out in this document. When leveraging external services, the importance of understanding SLAs – both individually and their impact on the composite - cannot be stressed enough.

Identify Failure Points and Failure Modes To create a resilient architecture, it‘s important to understand it. Specifically, making a proactive effort to understand and document what can cause an outage. Understanding the failure points and failure modes for an application and its related workload services can enable you to make informed, targeted decisions on strategies for resiliency and availability.

Failure Points A failure point is a design element that can cause an outage. An important focus is on design elements that are subject to external change. Examples of failure points include –



Database connections



Website connections



Configuration files



Registry keys Categories of common failure points include –



ACLs



Database access



External web site/service access



Transactions



Configuration



Capacity



Network

Failure Modes While failure points define the areas that can result in an outage, failure modes identify the root cause of an outage at those failure points. Examples of failure modes include –



A missing configuration file



Significant traffic exceeding resource capacity



A database reaching maximum capacity

Resiliency Patterns and Considerations This document will look at key considerations across compute, storage, and platform services. Before covering these topics, it is important to recap several basic resiliency impacting topics that are often either misunderstood and/or not implemented.

Default to Asynchronous As mentioned previously, a resilient architecture should optimize for autonomy. One of the ways to achieve autonomy is by making communication asynchronous. A resilient architecture should default to asynchronous interaction, with synchronous interactions happening only as the result of an exception. Stateless web-tiers or web-tiers with a distributed cache can provide this on the front end of a solution. Queues can provide this capability for communication for interaction between workload services or for services within a workload service.

The latter allows messages to be placed on queues and secondary services can retrieve them. This can be done based on logic, time, or volume considerate logic. In addition to making the process asynchronous, it also allows scaling of tiers ―pushing‖ or ―pulling‖ from the queues as appropriate.

Timeouts A common area where transient faults will occur is where your architecture connects to a service or a resource such as a database. When consuming these services, it‘s a common practice to implement logic that introduces the concept of a time out. This logic identifies an acceptable timeframe in which a response is expected and will generate an identifiable error when exceeding that time frame. Based on the appearance of the timeout error, appropriate steps will be taken based on the context in which the error occurs. Context can include the number of times this error has occurred, the potential impact of the unavailable resource, SLA guarantees for the current time period for the given customer, etc.

Handle Transient Faults When designing the service(s) that will deliver your workload, you must accept and embrace that failures will occur and take the appropriate steps to address them. One of the common areas to address is transient faults. As no service has 100% uptime, it‘s realistic to expect that you may not be able to connect to a service that a workload has taken a dependency on. The inability to connect to or faults seen from one of these services may be fleeting (less than a second) or permanent (a provider shuts down). Degrade Gracefully Your workload service should aspire to handle these transient faults gracefully. Netflix, for example, during an outage at their cloud provider utilized an older video queue for customers when the primary data store was not available. Another example would be an ecommerce site continuing to collect orders if its payment gateway is unavailable. This provides the ability to process orders when the payment gateway is once again available or after failing over to a secondary payment gateway. When doing this, the ideal scenario is to minimize the impact to the overall system. In both cases, the service issues are largely invisible to end users of these systems. Transient Fault Handling Considerations There are several key considerations for the implementation of transient fault handling, as detailed in the following sections.



Retry logic The simplest form of transient fault handling is to retry the operation that failed. If using a commercial third party service, implementing ―retry logic‖ will often resolve this issue. It should be noted that designs should typically limit the number of times the logic will be retried. The logic will typically attempt to execute the action(s) a certain number of times, registering an error and/or utilizing a secondary service or workflow if the fault continues.



Exponential Backoff If the result of the transient fault is due to throttling by the service due to heavy load, repeated attempts to call the service will only extend the throttling and impact overall availability. It is often desirable to reduce the volume of the calls to the service to help avoid or reduce throttling. This is typically done algorithmically, such as immediately retrying after the first failure, waiting 1 second after the second failure, 5 seconds after the 3rd failure, etc. until ultimately succeeding or a hitting an application defined threshold for failures. This approach is referred to ―exponential backoff.‖



Idempotency A core assumption with connected services is that they will not be 100% available and that transient fault handling with retry logic is a core implementation approach. In cases where retry logic is implemented, there is the potential for the same message to be sent more than once, for messages to be sent out of sequence, etc. Operations should be designed to be idempotent, ensuring that sending the same message multiple times does not result in an unexpected or polluted data store. For example, inserting data from all requests may result in multiple records being added if the service operation is called multiple times. An alternate approach would be to implement the code as an intelligent ‗upsert‘. A timestamp or global identifier could be used to identify new from previously processed messages, inserting only newer ones into the database and updating existing records if the message is newer than what was received in the past.



Compensating Behavior In addition to idempotency, another area for consideration is the concept compensating behavior. In a world of an every growing set of connected systems and the emergence of composite services, the importance of understanding how to handle the compensating behavior is important. For many developers of line of business applications, the concepts of transactions are not new, but the frame of reference is often tied to the transactional functionality exposed by local data technologies and related code libraries. When looking at the concept in terms of the cloud, this mindset needs to take into new considerations related to orchestration of distributed services. A service orchestration can span multiple distributed systems and be long running and stateful. The orchestration itself is rarely synchronous, can span multiple systems and can span from seconds to years based on the business scenario. In a supply chain scenario that could tie together 25 organizations in the same workload activity, for example, there may be a set of 25 or more systems that are interconnected in one or more service orchestrations. If success occurs, the 25 systems must be made aware that the activity was successful. For each connection point in the activity, participant systems can provide a correlation ID for messages it receives from other systems. Depending on the type of activity, the receipt of that correlation ID may satisfy the party that the transaction is notionally complete. In other cases, upon the completion of the interactions of all 25 parties, and confirmation message may be sent to all parties (either directly from a single service or via the specific orchestration interaction points for each system). To handle failures in composite and/or distributed activities, each service would expose a service interface and operation(s) to receive requests to cancel a given transaction by a unique identifier. Behind the service façade, workflows would be in place to compensate for the cancellation of this activity. Ideally these would be automated procedures, but they can be as simple as routing to a person in the organization to remediate manually.

Circuit Breaker Pattern A circuit breaker is a switch that automatically interrupts the flow of electric current if the current exceeds a preset limit. Circuit breakers are used most often as a safety precaution where excessive current through a circuit could be hazardous. Unlike a fuse, a circuit breaker can be reset and re-used. The same pattern is applicable to software design, and particularly applicable for services where availability and resiliency are a key consideration.

In the case of a resource being unavailable, implementing a software circuit breaker can respond with appropriate action and respond appropriately. A common implementation of this pattern is related to accessing of databases or data services. Once an established type and level of activity fails, the circuit breaker would react. With data, this is typically caused by the inability to connect to a database or a data service in front of that database. If a call to a database resource failed after 100 consecutive attempts to connect, there is likely little value in continuing to call the database. A circuit breaker could be triggered at that threshold and the appropriate actions can be taken. In some cases, particularly when connecting to data services, this could be the result of throttling based on a client exceeding the number of allowed calls within a given time period. The circuit breaker may inject delays between calls until such time that connections are successfully established and meet the tolerance levels. In other cases, the data store may not be unavailable. If a redundant copy of the data is available, the system may fail over to that replica. If a true replica is unavailable or if the database service is down broadly across all data centers within a provider, a secondary approach may be taken. This could include sourcing data from a version of the data requested via an alternate data service provider. This alternate source could be from a cache, an alternate persistent data store type on the current cloud provider, a separate cloud provider, or an on premise data center. When such an alternate is not available, the service could also return a recognizable error that could be handled appropriately by the client. Circuit Breaker Example: Netflix Netflix, a media streaming company, is often held up as a great example of a resilient architecture. When discussing the circuit breaker pattern at Netflix, that team calls out several criteria that are included in their circuit breaker in their Netflix Tech Blog. These included: 1.

A request to the remote service times out.

2.

The thread pool and bounded task queue used to interact with a service dependency are at 100% capacity.

3.

The client library used to interact with a service dependency throws an exception. All of these contribute to the overall error rate. When that error rate exceeds their defined thresholds, the circuit breaker is ―tripped‖ and the circuit for that service immediately serves fallbacks without even attempting to connect to the remote service. In that same blog entry, the Netflix team states that the circuit breaker for each of their services implements a fallback using one of the following three approaches:

1.

Custom fallback – a service client library provides an invokable fallback method or locally available data on an API server (e.g., a cookie or local cache) is used to generate a fallback response.

2.

Fail silent – a method returns a null value to the requesting client, which works well when the data being requested is optional.

3.

Fail fast – when data is required or no good fallback is available, a 5xx response is returned to the client. This approach focuses on keeping API servers healthy and enabling a quick recovery when impacted services come back online, but does so at the expense of negatively impacting the client UX.

Handling SLA Outliers: Trusted Parties and Bad Actors To enforce an SLA, an organization should address how its data service will deal with two categories of outliers—trusted parties and bad actors. Trusted Parties and White Listing Trusted parties are organizations with whom the organization could have special arrangements, and for whom certain exceptions to standard SLAs might be made.



Third Parties with Custom Agreements There may be some users of a service that want to negotiate special pricing terms or policies. In some cases, a high volume of calls to the data service might warrant special pricing. In other cases, demand for a given data service could exceed the volume specified in standard usage tiers. Such customers should be defined as trusted parties to avoid inadvertently being flagged as bad actors.



White Listing The typical approach to handling trusted parties is to establish a white list. A white list, which identifies a list of trusted parties, is used by the service when it determines which business rules to apply when processing customer usage. White listing is typically done by authorizing either an IP address range or an API key. When establishing a consumption policy, an organization should identify if white listing is supported; how a customer would apply to be on the white list; how to add a customer to the white list; and under what circumstances a customer is removed from the white list.



Handling Bad Actors If trusted parties stand at one end of the customer spectrum, the group at the opposite end is what is referred to as ―bad actors.‖ Bad actors place a burden on the service, typically from attempted ―overconsumption.‖ In some cases bad behavior is genuinely accidental. In other cases it is intentional, and, in a few situations, it is malicious. These actors are labeled ―bad‖, as their actions – intentional or otherwise – have the ability to impact the availability of one or more services. The burden of bad actors can introduce unnecessary costs to the data service provider and compromise access by consumers who faithfully follow the terms of use and have a reasonable expectation of service, as spelled out in an SLA. Bad actors must therefore be dealt with in a prescribed, consistent way. The typical responses to bad actors are throttling and black listing.



Throttling Organizations should define a strategy for dealing with spikes in usage by data service consumers. Significant bursts of traffic from any consumer can put an unexpected load on the data service. When such spikes occur, the organization might want to throttle access for that consumer for a certain period of time. In this case the service refuses all requests from the consumer for a certain period of time, such as one minute, five minutes, or ten minutes. During this period, service requests from the targeted consumer result in an error message advising that they are being throttled for overuse. The consumer making the requests can respond accordingly, such as by altering its behavior. The organization should determine whether it wants to implement throttling and set the related business rules. If it determines that consumers can be throttled, the organization will also need to decide what behaviors should trigger the throttling response.



Black listing Although throttling should correct the behavior of bad actors, it might not always be successful. In cases in which it does not work, the organization might want to ban a consumer. The opposite of a white list, a black list identifies consumers that are barred from access to the service. The service will respond to access requests from black-listed customers appropriately, and in a fashion that minimizes the use of data service resources. Black listing, as with white listing, is typically done by using either an API key or with an IP address range. When establishing a consumption policy, the organization should specify what behaviors will place a

consumer on the black list; how black listing can be appealed; and how a consumer can be removed from the black list.

“Automate All the Things” People make mistakes. Whether it‘s a developer making a code change that could have unexpected consequences, a DBA accidentally dropping a table in a database, or an operations person who makes a change but doesn‘t document it, there are multiple opportunities for a person to inadvertently make a service less resilient. To reduce human error, a logical approach is to reduce the amount of humans in the process. Through the introduction of automation, you limit the ability for ad hoc, inadvertent deltas from expected behavior to jeopardize your service. There is a meme in the DevOps community with a cartoon character saying ―Automate All the Things.‖ In the cloud, most services are exposed with an API. From development tools to virtualized infrastructure to platform services to solutions delivered as Software as a Service, most things are scriptable. Scripting is highly recommended. Scripting makes deployment and management consistent and predictable and pays significant dividends for the investment. Automating Deployment One of the key areas of automation is in the building and deployment of a solution. Automation can make it easy for a developer team to test and deploy to multiple environments. Development, test, staging, beta, and production can all be deployed readily and consistently through automated builds. The ability to deploy consistently across environments works toward ensuring that what‘s in production is representative of what‘s been tested. Establish and Automating a Test Harness Testing is another area that can be automated. Like automated deployment, establishing automated testing is valuable in ensuring that your system is resilient and stays resilient over time. As code and usage of your service evolves it‘s important to remain that all appropriate testing is done, both functionally and at scale. Automating Data Archiving and Purging One of the areas that gets little attention is that of data archiving and purging. Data volume is growing and continues to grow at a higher volume and in greater variety than any time in history. Depending on the database technology and the types of queries required, unnecessary data can reduce the response time of your system and increase costs unnecessarily. For resiliency plans that include one or more replicas of a data store, removing all but the necessary data can expedite management activities such as backing up and restoring data. Identify the requirements for your solution related to data needed for core functionality, data needed for compliance purposes but can be archived, and data that is no longer necessary and can be purged. Utilize the APIs available from the related products and services to automate the implementation of these requirements.

Understand Fault Domains and Upgrade Domains When building a resilient architecture, it‘s also important to understand the concepts of fault domains and upgrade domains. Fault Domains Fault domains constrain the placement of services based on known hardware boundaries and the likelihood that a particular type of outage will affect a set of machines. A fault domain is defined as a series of machines can fail simultaneously, and are usually defined by physical properties (a particular rack of machines, a series of machines sharing the same power source, etc). Upgrade Domains

Upgrade domains are similar to fault domains. Upgrade domains define a physical set of services that are updated by the system at the same time. The load balancer at the cloud provider must be aware of upgrade domains in order to ensure that if a particular domain is being updated that the overall system remains balanced and services remain available. Depending on the cloud provider and platform services utilized, fault domains and upgrade domains may be provided automatically, be something your service can opt-in to via APIs, or require a 1st or 3rd party solution.

Identify Compute Redundancy Strategies On-premises solutions have often relied on redundancy to help them with availability and scalability. From an availability standpoint, redundant data centers provided the ability to increase likelihood of business continuity in the face of infrastructure failures in a given data center or part of a data center. For applications with geo-distributed consumers, traffic management and redundant implementations routed users to local resources, often with reduced latency.

Note Data resiliency, which includes redundancy, is covered as a separate topic in the section titled Establishing a Data Resiliency Approach. Redundancy and the Cloud On-premises, redundancy has historically been achieved through duplicate sets of hardware, software, and networking. Sometimes this is implemented in a cluster in a single location or distributed across multiple data centers. When devising a strategy for the cloud, it is important to rationalize the need for redundancy across three vectors. These vectors include deployed code within a cloud provider‘s environment, redundancy of providers themselves, and redundancy between the cloud and on premises. Deployment Redundancy When an organization has selected a cloud provider, it is important to establish a redundancy strategy for the deployment within the provider. If deployed to Platform as a Service (PaaS), much of this may be handled by the underlying platform. In an Infrastructure as a Service (IaaS) model, much of this is not.



Deploy n number of roles with in a data center The simplest form of redundancy is deploying your solution to multiple compute nodes within a single cloud provider. By deploying to multiple nodes, the solution can limit downtime that would occur when only a single node is deployed. In many Platform as a Service environments, the state of the virtual machine hosting the code is monitored and virtual machines detected to be unhealthy can be automatically replaced with a healthy node.



Deploy Across Multiple Data Centers While deploying multiple nodes in a single data center will provide benefits, architectures must consider that an entire data center could potentially be unavailable. While not a common occurrence, events such as natural disasters, war, etc. could result in a service disruption in a particular geo-location.

To achieve your SLA, it may be appropriate for you to deploy your solution to multiple data centers for your selected cloud provider. There are several approaches to achieving this, as identified below. 1.

Fully Redundant Deployments in Multiple Data Centers The first option is a fully redundant solution in multiple data centers done in conjunction with a traffic management provider. A key consideration for this approach will be impact to the compute-related costs for this type of redundancy, which will increase 100% for each additional data center deployment.

2.

Partial Deployment in Secondary Data Center(s) for Failover Another approach is to deploy a partial deployment to a secondary data center of reduced size. For example, if the standard configuration utilized 12 compute nodes, the secondary data center would contain a deployment containing 6 compute nodes. This approach, done in conjunction with traffic management, would allow for business continuity with degraded service after an incident that solely impacted the primary center. Given the limited number of times a data center goes offline entirely, this is often seen as a cost-effective approach for compute – particularly if a platform allows the organization to readily onboard new instances in the second data center.

3.

Divided Deployments across Multiple Data Centers with Backup Nodes For certain workloads, particularly those in the financial services vertical, there is a significant amount of data that must be processed within a short, immovable time window. In these circumstances, work is done in shorter bursts and the costs of redundancy are warranted to deliver results within that window. In these cases, code is deployed to multiple data centers. Work is divided and distributed across the nodes for processing. In the instance that a data center becomes unavailable, the work intended for that node is delivered to the backup node which will complete the task.

4.

Multiple Data Center Deployments with Geography Appropriate Sizing per Data Center This approach utilizes redundant deployments that exist in multiple data centers but are sized appropriately for the scale of a geo-relevant audience. Provider Redundancy While data-center-centric redundancy is good, Service Level Agreements are at the Service Level vs. the data center. There is the possibility that the services delivered by a provider could become unavailable across multiple or all data centers. Based on the SLAs for a solution, it may be desirable to also incorporate provider redundancy. To realize this, cloud-deployable products or cloud services that will work across multiple cloud platforms must be identified. Microsoft SQL Server, for example, can be deployed in a Virtual Machine inside of Infrastructure as a Service offerings from most vendors. For cloud provided services, this is more challenging as there are no standard interfaces in place, even for core services such as compute, storage, queues, etc. If provider redundancy is desired for these services, it is often achievable only thorugh an abstraction layer. An abstraction layer may provide enough functionality for a solution, but it will not be innovated as fast as the underlying services and may inhibit an organization from being able to readily adopt new features delivered by a provider. If redundant provider services may are warranted, it can be at one of several levels--an entire application, a workload, or an aspect of a workload. At the appropriate level, evaluate the need for compute, data, and platform services and determine what must truly be redundant and what can be handled via approaches to provide graceful degradation.

On-Premises Redundancy While taking a dependency on a cloud provider may make fiscal sense, there may be certain business considerations that require on-premises redundancy for compliance and/or business continuity. Based on the SLAs for a solution, it may be desirable to also incorporate on-premises redundancy. To realize this, private cloud-deployable products or cloud services that will work across multiple cloud types must be identified. As with the case of provider redundancy, Microsoft SQL Server is a good example of a product that can be deployed on-premises or in an IaaS offering. For cloud provided services, this is more challenging as there are often no on-premises equivalents with interface and capability symmetry. If redundant provider services are required on premises, this can be at one of several levels--an entire application, a workload, or an aspect of a workload. At the appropriate level, evaluate the need for compute, data, and platform services and determine what must truly be redundant and what can be handled via approaches to provide graceful degradation. Redundancy Configuration Approaches When identifying your redundancy configuration approaches, classifications that existed pre-cloud also apply. Depending on the types of services utilized in your solution, some of this may be handled by the underlying platform automatically. In other cases, this capability is handled through technologies like Windows Fabric. 1.

Active/active — Traffic intended for a failed node is either passed onto an existing node or load balanced across the remaining nodes. This is usually only possible when the nodes utilize a homogeneous software configuration.

2.

Active/passive — Provides a fully redundant instance of each node, which is only brought online when its associated primary node fails. This configuration typically requires the most extra hardware.

3.

N+1 — Provides a single extra node that is brought online to take over the role of the node that has failed. In the case of heterogeneous software configuration on each primary node, the extra node must be universally capable of assuming any of the roles of the primary nodes it is responsible for. This normally refers to clusters which have multiple services running simultaneously; in the single service case, this degenerates to active/passive.

4.

N+M — In cases where a single cluster is managing many services, having only one dedicated failover node may not offer sufficient redundancy. In such cases, more than one (M) standby servers are included and available. The number of standby servers is a tradeoff between cost and reliability requirements.

5.

N-to-1 — Allows the failover standby node to become the active one temporarily, until the original node can be restored or brought back online, at which point the services or instances must be failed-back to it in order to restore high availability.

6.

N-to-N — A combination of active/active and N+M, N to N redistributes the services, instances or connections from the failed node among the remaining active nodes, thus eliminating (as with active/active) the need for a 'standby' node, but introducing a need for extra capacity on all active nodes.

Traffic Management Whether traffic is always geo-distributed or routed to different data centers to satisfy business continuity scenarios, traffic management functionality is important to ensure that requests to your solution are being routed to the appropriate instance(s). It is important to note that taking a dependence on a traffic management service introduces a single point of failure. It is important to investigate the SLA of your application‘s primary traffic management service and determine if alternate traffic management functionality is warranted by your requirements.

Establish a Data Partitioning Strategy While many high scale cloud applications have done a fine job of partitioning their web tier, they are less successful in scaling their data tier in the cloud. With an ever growing diversity of connected devices, the level of data generated and queried is growing at levels not seen before in history. The need to be able to support 500,000 new users per day, for example, is now considered reasonable. Having a partitioning strategy is critically important across multiple dimensions, including storing, querying, or maintaining that data. Decomposition and Partitioning Because of the benefits and tradeoffs of different technologies, it is common to leverage technologies that are most optimal for the given workload. Having a solution that is decomposed by workloads provides you with the ability to choose data technologies that are optimal for a given workload. For example, a website may utilize table storage for content for an individual, utilizing partitions at the user level for a response experience. Those table rows may be aggregated periodically into a relational database for reporting and analytics. Partitioning strategies may, and often will, vary based on the technologies chosen. Understanding the 3 Vs To properly devise a partitioning strategy, an organization must first understand it. The 3 Vs, made popular by Gartner, look at three different aspects of data. Understanding how the 3 Vs relate to your data will assist you in making an informed decision on partitioning strategies.



Volume Volume refers to the size of the data. Volume has very real impacts on the partitioning strategy. Volume limitations on a particular data technology may force partitioning due to size limitations, query speeds at volume, etc.



Velocity Velocity refers to the rate at which your data is growing. You will likely devise a different partitioning strategy for a slow growing data store vs. one that needs to accommodate 500,000 new users per day.



Variety Variety refers to the different types of data that are relevant to the workload. Whether it‘s relational data, key-value pairs, social media profiles, images, audio files, videos, or other types of data, it‘s important to understand it. This is both to choose the right data technology and make informed decisions for your partitioning strategy. Horizontal Partitioning Likely the most popular approach to partitioning data is to partition it horizontally. When partitioning horizontally, a decision is made on criteria to partition a data store into multiple shards. Each shard contains the entire schema, with the criteria driving the placement of data into the appropriate shards. Based on the type of data and the data usage, this can be done in different ways. For example, an organization could choose to partition their data based on a customer last name. In another case, the partition could be date centric, partitioning on the relevant calendar interval of hour, day, week, or month.

Figure 4. An example of horizontal partitioning by last name Vertical Partitioning Another approach is vertical partitioning. This optimizes the placement of data in different stores, often tied to the variety of the data. Figure 5 shows an example where metadata about a customer is placed in one store while thumbnails and photos are placed in separate stores. Vertical partitioning can result in optimized storage and delivery of data. In Figure 5, for example, if the photo is rarely displayed for a customer, returning 3 megabytes per records can add unnecessary costs in a pay as you go model.

Figure 5. An example of vertical partitioning. Hybrid Partitioning In many cases it will be appropriate to establish a hybrid partitioning strategy. This approach provides the efficiencies of both approaches in a single solution. Figure 6 shows an example of this, where the vertical partitioning seen earlier is now augmented to take advantage of horizontal partitioning of the customer metadata.

Figure 6. An example of horizontal partitioning. Cloud computing == network computing

At the heart of cloud computing is the network. The network is crucial as it provides the fabric or backbone for devices to connect to services as well as services connecting to other services. There are three network boundaries to consider in any FailSafe application. Those network boundaries are detailed below with Windows Azure used as an example to provide context: 1.

Role boundaries are traditionally referred to as tiers. Common examples are a web tier or a business logic tier. If we look at Windows Azure as an example, it formally introduced roles as part of its core design to provide infrastructure support the multi-tier nature of modern, distributed applications. Windows Azure guarantees that role instances belonging t the same service are hosted within the scope of a single network environment and managed by a single fabric controller.

2.

Service boundaries represent dependencies on functionality provided by other services. Common examples are a SQL environment for relational database access and a Service Bus for pub/sub messaging support. Within Windows Azure, for example, service boundaries are enforced through the network: no guarantee will be given that a service dependency will be part of the same network or fabric controller environment. That might happen, but the design assumption for any responsible application has to be that any service dependency is on a different network managed by a different fabric controller.

3.

Endpoint boundaries are external to the cloud. They include any consuming endpoint, generally assumed to be a device, connecting to the cloud in order to consume services. You must make special considerations in this part of the design due to the variable and unreliable nature of the network. Role boundaries and service boundaries are within the boundaries of the cloud environment and one can assume a certain level of reliability and bandwidth. For the external dependencies, no such assumptions can be made and extra care has to be given to the ability of the device to consume services, meaning data and interactions. The network by its very nature introduces latency as it passes information from one point of the network to another. In order to provide a great experience for both users and as dependent services or roles, the application architecture and design should look for ways to reduce latency as much as sensible and manage unavoidable latency explicitly. One of the most common ways to reduce latency is to avoid services calls that involve the network--local access to data and services is a key approach to reduce latency and introduce higher responsiveness Using local data and services also provides another layer of failure security; as long as the requests of the user or application can be served from the local environment, there is no need to interact with other roles or services, removing the possibility of dependent component unavailability as a failure point.

Introducing caching Caching is a technique that can be used to improve data access speeds when it‘s not possible to store data locally. Caching is utilized to great effect in most cloud service operating at scale today. As the definition provided by Wikipedia outlines, a cache provides local access to data that is repeatedly asked for by applications. Caching relies on two things:



Usage patterns for the data by users and dependent applications are predominantly read-only. In certain scenarios such as ecommerce websites, the percentage of read-only access (sometimes referred to as browsing) is up to 95% of all user interactions with the site.



The application‘s information model provides an additional layer of semantic information that supports the identification of stable, singular data that is optimal for caching. Device caching While not the focus for the FailSafe initiative, device caching is one of the most effective ways to increase the usability and robustness of any devices + services application. Numerous ways exist to provide caching services on the device or client tier, ranging from the HTML5 specification providing native caching capabilities implemented in all the standard browsers to local database instances such as SQL Server Compact Edition or similar. Distributed caching Distributed caching is a powerful set of capabilities, but its purpose is not to replace a relational database or other persistent store; rather, its purpose is to increase the responsiveness of distributed applications that by nature are network centric and thus latency sensitive. A side benefit of introducing caching is the reduction of traffic to the persistent data store, which drives the interactions with your data service to a minimum.



Information models optimized for caching Cached data by its very nature is stale data, i.e. data that is not necessarily up-to-date anymore. A great example of cached data although from a very different domain is a product catalog that is being sent to thousands of households. The data used to produce the product catalog was up-to-date when the catalog was created. Once the printing presses were going, the data, by the very nature of time passing during the catalog production process, went stale. Due to cached data being stale, the attributes of data with respect to stability and singularity are critical to the caching design:

o

Stability - Data that has an unambiguous interpretation across space and time. This often means data values that do not change. For example, most enterprises never recycle customer identifications or SKU numbers. Another technique to create stable data is the addition of expiration dates to the existing data. The printed product catalog example above is a great example. Generally retailers accept orders from any given catalog for 2 periods of publication. If one publishes a catalog four times a year, the product catalog data is stable for 6 months and can be utilized for information processing such as placing and fulfilling orders. Stable data is often referenced as master or reference data. In the FailSafe initiative we will utilize the term reference data as it is a semantically more inclusive term than master data. In a lot of enterprises, master data has a very specific meaning and is narrower than reference data.

o

Singularity - Data that can be isolated through association with uniquely identifiable instances with no or low concurrent updates. Take the example of a shopping basket. While the shopping basket will clearly be updated, the updates occur relatively infrequently and can be completely isolated from the storage as well as the processing perspective. Isolatable data as described above is referenced as activity data or session data. With these two attributes in mind, the following schema emerges:



Managing the cache Caching the right information at the right time is a key part of a successful caching strategy. Numerous techniques exist for loading the cache: a good overview is described here. In addition, the sections below outline a few considerations for FailSafe application design that is dependent upon distributed caching.

o

Reference data - If the hosting environment (fabric controller or datacenter) encounters a disaster, your application will be moved to another environment. In the case where an active instance of your application is already active (active-active design), the likelihood that your cache already contains a lot of the relevant information (especially reference data) is high. In the case that a new instance of your application gets spun up, no information will be in the cache nodes. You should design your application so that on a cache miss, it automatically loads the desired data. In the case of a new instance, you can have a startup routine that bulk loads reference data into the cache. A combination of the two is desirable as users might be active as soon as the application is being served by the cloud infrastructure.

o

Activity data - The basic techniques described for reference data hold true for activity data as well. However, there is a specific twist to activity data. Reference data is assumed to be available in any persistent store of the application. As it will change on a less frequent basis, synchronization ought not to be a problem, although it needs to be considered. However, activity data, albeit being updated in isolation and with low frequency, will be more volatile than reference data. Ideally the distributed cache persists activity data on a frequent basis and replicates the data between the various instances of the application. Take care to ensure that the persistence and synchronization intervals are spaced far enough to avoid contention but close enough to keep possible data loss at a minimum.

Establishing a Data Resiliency Approach A common misunderstanding is the relationship, specifically the areas of responsibility, between platform and application. One of the areas where this is most troublesome is in respect to data. While a platform such as Windows Azure will deliver on promises of storing multiple copies of the data (and in some services even going so far as to provide geo-redundancy), the data that is stored is driven by the application, workload, and its component services. If the application takes an action that corrupts its application data, the platform stores multiple copies of it. When establishing your failure modes and failure points it‘s important to identify areas of the application that could potentially cause data corruption. While the point of origin could vary from bad code or poison messages to your service, it‘s important to identify the related failure modes and failure points. Application Level Remediation



Idempotency A core assumption with connected services is that they will not be 100% available and that transient fault handling with retry logic is a core implementation approach. In cases where retry logic is implemented, there is the potential for the same message to be sent more than once, for messages to be sent out of sequence, etc. Operations should be designed to be idempotent, ensuring that sending the same message multiple times does not result in an unexpected or polluted data store.

For example, inserting data from all requests may result in multiple records being added if the service operation is called multiple times. An alternate approach would be to implement the code as an intelligent ―upsert‖ which performs an update if a record exists or an insert if it does not. A timestamp or global identifier could be used to identify new vs. previously processed messages, inserting only newer ones into the database and updating existing records if the message is newer than what was received in the past.



Workload Activities and Compensating Behavior In addition to idempotency, another area for consideration is the concept of compensating behavior. A real world example of compensating behavior is seen when returning of a product which was paid for with a credit card. In this scenario, a consumer visits a retailer, provides a credit card and a charge is applied to the consumers credit card account. If the consumer returns the product to the retailer, a policy is evaluated and if the return conforms to the policy, the retailer issues a credit for the amount of the purchase to the consumers credit card account. In a world of an every growing set of connected systems and the emergence of composite services, the importance of understanding how to handle the compensating behavior is important. For many developers of line-of-business applications, the concepts of transactions are not new, but the frame of reference is often tied to the transactional functionality exposed by local data technologies and related code libraries. When looking at the concept in terms of the cloud, this mindset needs to take into account new considerations related to orchestration of distributed services. A service orchestration can span multiple distributed systems and be long running and stateful. The orchestration itself is rarely synchronous and it can span from seconds to years based on the business scenario. In a supply chain scenario, that could tie together 25 organizations in the same workload activity. For example, there may be a set of 25 or more systems that are interconnected in one or more service orchestrations. If success occurs, the 25 systems must be made aware that the activity was successful. For each connection point in the activity, participant systems can provide a correlation ID for messages it receives from other systems. Depending on the type of activity, the receipt of that correlation ID may satisfy the party that the transaction is notionally complete. In other cases, upon the completion of the interactions of all 25 parties, a confirmation message may be sent to all parties (either directly from a single service or via the specific orchestration interaction points for each system). To handle failures in composite and/or distributed activities, each service would expose a service interface and operation(s) to receive requests to cancel a given transaction by a unique identifier. Behind the service façade, workflows would be in place to compensate for the cancellation of this activity. Ideally these would be automated procedures, but they can be as simple as routing to a person in the organization to remediate manually. Backups In addition to application-level remediation to avoid data corruption, there is also remediation that is put in place to provide options if application remediation is not successful. Processes for both creating and restoring backup copies of your data store – either in whole or in part – should be part of your resiliency plan. While the concepts of backing up and restoring data are not new, there are new twists to this in the cloud. Your backup strategy should be defined with a conscious understanding of the business requirements for restoring data. If a data store is corrupted or taken offline due a disaster scenario, you need to know what type of data must be restored, what volume must be restored, and what pace is required for the business. This will impact your overall availability plan and should drive your backup and restore planning.



Relational Databases Backing up of relational databases is nothing new. Many organization have tools, approaches, and processes in place for the backing up of data to either satisfy disaster recovery or compliance needs. In many cases traditional backup tools, approaches, and processes may work with little or no modification. In addition, there are new or variant alternatives, such as backing up data and storing a copy in cloud-based blob storage, that can be considered. When evaluating existing processes and tools, it‘s important to evaluate which approach is appropriate for the cloud based solution. In many cases, one or more of the approaches listed below will be applied to remediate different failure modes.

1.

Total Backup - This is a backup of a data store in its entirety. Total backups should occur based on a schedule dictated by your data volume and velocity. A total backup is the complete data set needed to deliver on the service level agreement for your service. Mechanisms for this type of backup are generally available either by the database / database service provider or its vendor ecosystem.

2.

Point in Time - A point in time backup is a backup that reflects a given point in time in the databases existence. If an error were to occur in the afternoon that corrupted the data store, for example, a point in time backup done at noon could be restored to minimize business impact. Given the ever-growing level of connectivity of individuals, the expectation to engage with your service at any time of day makes the ability to quickly restore to a recent point in time a necessity.

3.

Synchronization - In addition to traditional backups, another option is synchronization of data. Data could be stored in multiple data centers, for example, with a periodic synchronization of data from one datacenter to another. In addition to providing synchronized data in solutions that utilize traffic management as part of a normal availability plan, this can also be used to fail over to a second data center if there is a business continuity issue. Given the constant connectivity of individuals consuming services, downtime becomes less and less acceptable for a number of scenarios and synchronization can be a desirable approach. Patterns for synchronization can include: - data center to data center of a given cloud provider - data center to data center across cloud providers - data center to data center from on premise to a given cloud provider - data center to device synchronization for consumer specific data slices



Sharded Relational Databases For many, the move to the cloud is driven by a need to facilitate large numbers of users and high traffic scenarios such as those related to mobile or social applications. In these scenarios, the application pattern often involves moving away from a single database model to a number of database shards that contain a portion of the overall data set and are optimized for large scale engagement. One recent social networking project built on Windows Azure launched with a total of 400 database shards. Each shard is a standalone database and your architecture and management should facilitate total backups, point in time backups, and restoration of backups for both individual shards and a complete data set including all shards.



NoSQL Data Stores

In addition to relational data stores, backup policies should be considered for ―Not only SQL‖ or NoSQL data stores as well. The most popular form of NoSQL databases provided by major cloud providers would be a form of high availability key-value pair store, often referred to as a table store. NoSQL stores may be highly available. In some cases they will also be geo-redundant, which can help prevent loss in the case of a catastrophic failure in a specific data center. These stores typically do not provide protections from applications overwriting or deleting content unintentionally. Application or user errors are not handled automatically by platform services such as blob storage and a backup strategy should be evaluated. While relational databases typically have existing and well-established tools for performing backups, many NoSQL stores do not. A popular architectural approach is to create a duplicate copy of the data in a replica NoSQL store and use a lookup table of some kind to identify which rows from the source store have been placed in the replica store. To restore data, this same table would be utilized, reading from the table to identify content in the replica store available to be restored. Depending on the business continuity concerns, the placement of this replica could be hosted with the same cloud provider, in the same data center, and/or the same No SQL data store. It could also reside in a different data center, a different cloud provider, and/or a different variant of NoSQL data store. The driver for placement will be largely influence by the desired SLA of your workload service and any related regulatory compliance considerations. A factor to consider when making this determination is cost, specifically as it relates to data ingress and egress. Cloud providers may provide free movement of data within their data center(s) and allow free passage of data into their environment. No cloud provider offers free data egress, and the cost of moving data to a secondary cloud platform provider could introduce significant costs at scale.



Blob Storage Like relational and NoSQL data stores, a common misconception is that the availability features implemented for a blob storage offering will remove the need to consider implementing a backup policy. Blob storage also may be geo-redundant, but, as discussed earlier, this does not guard against application errors. Application or user errors are not handled automatically by platform services such as blob storage and a backup strategy should be evaluated. Backup strategies could be very similar to those used for NoSQL stores. Due to the potentially large size of blobs, cost and time to move data will be important parts of a backup and restore strategy.



Restoring Backups By now, most people have heard the cautionary tale of the organization that established and diligently followed backup policies but never tested restoring the data. On that fateful day when a disaster did occur, they went to restore their database backup only to discover they had configured their backup incorrectly and the tapes they‘d been sending offsite for years didn‘t have the information they needed on them. Whatever back up processes are put into place, it‘s important to establish testing to verify that data can be restored correctly and to ensure that restoration occurs in a timely fashion and with minimal business impact.

Content Delivery Networks Content Delivery Networks (CDNs) are a popular way to provide availability and enhanced user experience for frequently requested files. Content in a CDN is copied to a local node on its first use, and then served up from that local node for subsequent requests. The content will expire after a designated time period, after which content must be re-copied to the local node upon the next request.

Utilizing a CDN provides a number of benefits but it also adds a dependency. As is the case with any dependency, remediation of a service failure should be proactively reviewed. Appropriate Use of a CDN A common misconception is that CDNs are a cure all for scale. In one scenario, a customer was confident it was the right solution for an online ebook store. It was not. Why? In a catalog of a million books, there is a small subset of books that would be frequently requested (the ―hits‖) and a very long tail of books that would be requested with very little predictability. Frequently requested titles would be copied to the local node on the first request and provide cost effective local scale and a pleasant user experience. For the long tail, almost every request is copied twice – once to the local node, then to the customer – as the infrequent requests result in content regularly expiring. This is evidence that a CDN improperly will have the opposite of the intended effect – a slower, more costly solution.

Design for Operations In many cases, operations of a solution may not be planned until further along in the lifecycle. To build truly resilient applications, they should be designed for operations. Designing for operations typically will include key activities such as establishing a health model, capturing telemetry information, incorporating health monitoring services and workflows, and making this data actionable by both operations and developers.

Lecture 4: WINDOWS AZURE COMPUTE Web Sites vs Cloud Services vs Virtual Machines

With its recent expansion, Windows Azure (Microsoft‘s public cloud platform) now supports 3 modes of cloud computing. In this article, we‘ll explain the rules of the road using a highway metaphor. Which lane of this 3-way highway should you drive in, and what kind of vehicles are permitted in each lane?

Traditionally, there was one way to use Windows Azure: Platform-as-a-Service (now called Cloud Services). Recently, the platform was greatly expanded to also provide Infrastructure-as-a-Service capability (Virtual Machines) and a special mode for web sites (Windows Azure Web Sites). Let‘s point out here and now that although one area of the platform has ―web sites‖ in its name, you can in fact host web sites at all three levels. The table below will give you a quick idea of what kind of apps belong where, after which we‘ll take a look at each of these ways to use Windows Azure and compare them.

Windows Azure Web Sites

2-Tier Simple Web Sites • Web sites using open source frameworks • Web sites using SQL DB or MySQL • Web sites that run on IIS: ASP.NET, PHP, node.js

Cloud Services

Multi-Tier Modern Solutions • Stateless VM farms • Run on Windows Server • Where automated management is required • Require advanced functionality such as service bus, identity federation, CDN, traffic management

Virtual Machines

Legacy Solutions • Stateful single VM or VM farms • Run on Windows Server or Linux • Legacy LOB applications • Enterprise server products • Where portability between cloud and on-premises is required

Windows Azure Web Sites: The Fast Lane Windows Azure Web Sites provides an accelerated way to work in the cloud for modern web sites. It has the automated management benefits normally associated with Platform-as-a-Service and the portability of workload normally associated with Infrastructure-as-a-Service. Unlike the other two modes for using Windows Azure, which support a great diversity of solution types, WAWS is limited to simple 2-tier web sites that can run on a standard IIS configuration. At the time of this writing, WAWS is in preview and does not yet come with an SLA. A certain level of use is free before charges apply.

Why do we call WAWS the fast lane? First of all, provisioning is lightning-quick: you can provision a web site and accompanying SQL or MySQL database in well under a minute—far less than the 10-15 minutes of provisioning time other segments of the platform require. Second, you have high productivity from the get-go because your web developers don‘t have to learn anything new or change the way they work. Your web site can run as-is in the cloud. Deployment is a beautiful thing in WAWS: you can use Web Deploy, FTS, Git or TFS. Moreover, you only have to deploy to a single server regardless of how many VMs your site runs on: Windows Azure takes care of distributing deployments out to all instances. Lastly, one other nice speedy aspect of WAWS is that you can provision web sites ready to go with your favorite web framework by choosing from a gallery that includes DotNetNuke, Drupal, Joomla, Orchard, Umbraco, and WordPress.

The reason WAWS deployment is so fast is that it uses a pre-allocated pool of VMs for web serving. By default, you are working in shared mode, which means you are using this pool and sharing your VMs with other tenants. That might sound a little dangerous, but virtual directory isolation keeps your work and that of other tenants walled off from each other. At a higher cost, you can choose to switch over toreserved mode, in which your VMs are dedicated to you alone. In either mode, you can scale the number of instances using the Windows Azure management portal.

What kind of web technologies can you run in WAWS? Anything compatible with IIS, including ASP.NET, classic ASP, PHP, and node.js. WAWS does come with some limitations. Architecturally, you are limited to simple 2-tier web sites that run on IIS with a standard configuration. However, you cannot change the IIS configuration, remote desktop to the VM, or otherwise make changes that might affect other tenants. If you need more than this, such as a third tier for web services, you should look at Cloud Services or Virtual Machines instead.

From a VM persistence standpoint, disk file changes are persistently saved in Windows Azure Storage. However, all VM instances for a site are sharing common storage—so you need to consider file overwrites. The bottom line: Windows Azure Web Sites provide a fast lane for web sites in the cloud, offering the best attributes of PaaS (automated management) and IaaS (portability) without requiring web developers to change the way the work—but they can only be used with simple 2-tier web sites that can run on IIS in a default configuration.

See my post Reintroducing Windows Azure: Web Sites for a detailed walk-through of this feature.

Cloud Services: Leave the Driving to Us Cloud Services are the Platform-as-a-Service (PaaS) way to use Windows Azure. PaaS gives you automated management and a large toolbox of valuable services to compose solutions from.

PaaS can be controversial: some see it as the modern way to design applications that leverage the differences and advantages of cloud computing environments; others view PaaS with concerns about vendor/platform lock-in. Keep in mind, the expense

of preserving full cloud/on-prem portability is limiting yourself to the least common denominator of both; that is, not taking advantage of the special functionality available in the cloud.

The cornerstone Windows Azure Compute service which hosts applications uses a declarative model to specify the shape and size of your solution. Although many kinds of software can run in the cloud at this level, including complex multi-tier solutions, this model must be adhered to. Your solution consists of one of more roles, where each role is a VM farm. There are several kinds of roles, including web roles for Internet-facing software and worker roles for everything else. You can connect your roles to each other or to the outside world using loadbalanced endpoints or alternative methods such as queues. The VM instances that make up a role are not persistent, meaning you cannot rely on VM state changes (such as disk file updates) to stay around; for persistence you must use a storage or database service. You‘ll need at least 2 VM instances per role in order for the 99.95% (3½ 9‘s) Compute SLA to apply. Most of the other cloud services give you a 99.9% (3 9‘s) SLA.

There are many other cloud services to choose from that provide storage, relational data, identity, communication, caching, traffic management, and more. Many of these services provide extremely valuable functionality for pennies such as federating identity or brokering messages—and they‘re managed for you. Most PaaS solutions leverage a combination of cloud services.

The automated management in Cloud Services is very attractive. For the Compute service, this includes automated patching and orchestrated software updates across your VMs. Storage and database services store data with triple-redundancy and have automatic fail-over. The traffic management service can check the health of your applications and fail over from one data center to another when necessary. VM instances and storage units are spread across fault domains in the data center to maintain availability in the event of a data center failure.

Cloud Services do require you to adhere to its model, and sometimes that means designing for the cloud or adapting existing applications to fit the cloud. Sometimes this is a small effort and sometimes it is not. Modern SOA applications based on tiers

of stateless VM farms are generally very straightforward to move to Cloud Services. Solutions that have a single-server model, or depend on local VM state, usually require moderate-to-significant changes. These changes can sacrifice portability of your application, especially if you are highly dependent on cloud service functionality not available elsewhere.

Cloud Services provide an SDK and a simulation environment that allow you to develop and test locally before deploying to a cloud data center. To deploy, you must package your solution and publish it to the cloud to a Staging slot or a Production slot. You can promote a cloud deployment from Staging to Production in a fast, one-click operation.

The bottom line: cloud services provide automated management, valuable functionality, and architectural versatility—but apps may need to be adapted to fit its model, and strong dependence on platform-specific cloud services can result in apps that are no longer portable to other environments.

See my post Reintroducing Windows Azure: Cloud Services for highlights of what‘s new in this area.

Virtual Machines: Self-Service Virtual Machines are the Infrastructure-as-a-Service (IaaS) level of Windows Azure. You stand up virtual machines, configure them yourself, and manage them yourself. If you value portability of workload (the ability to move your IT assets between the cloud and on-premises seamlessly) and are fine managing your systems yourself, this lane might be for you. At the time of this writing, Virtual Machines are in preview; however, they do come with an SLA and are not free despite the pre-release status.

Although it comes at the cost of self-management, Virtual Machines provide great versatility. You provision Linux or Windows Server VMs and either compose the VM images in the cloud or upload a VHD you‘re previously created using Hyper-V. You can capture a VM and add it your image gallery for easy reuse. In Virtual Machines, individual VMs are persistent. It‘s fine to run just one instance of a VM, you don‘t have to worry about losing VM state, and you get a 99.9% SLA. This makes virtual machines the right choice for single-server solutions and server products that use local disk files. You can‘t run a product like Active Directory or SQL Server or SharePoint Server successfully in Cloud Services, but you can in Virtual Machines. Virtual machines are also often the best fit for legacy applications.

You can group your virtual machines in a common availability set, which will spread instances across fault domains in the data center for high availability in the event of a data center failure. You can provision load-balanced endpoints to direct Internet traffic to your availability set.

The bottom line: Virtual Machines are for the do-it-yourself IT person (like a driving enthusiast who also likes to work on their car and do their own tuning and maintenance). It's also the only way to run certain kinds of applications, such as single-server stateful solutions and some server products. See my post Reintroducing Windows Azure: Virtual Machines for a detailed walkthrough of this feature.

WAWS, Cloud Services, & VMs Compared The table below contrasts Windows Azure, Web Sites, Cloud Services, and Virtual Machines.

Level (PaaS/IaaS)

WAWS

Cloud Services

Virtual Machines

PaaS with the portability of

PaaS

IaaS

Fully portable

Design or adapt for cloud

Fully portable

Automated

Automated

Customer Responsibility

IaaS Portability Management

Architecture

2-tier IIS web sites only

Versatile

Versatile

Web Site

Cloud Service

Virtual Machine

Persistence

VMs share persistence

VMs are not persistent

Each VM is persistent

Provisioning

Under a minute

10-15 minutes

10-15 minutes

Windows Server / IIS

Windows Server

Windows Server, Linux

Web Deploy, FTP, Git, TFS

Package and Publish

Compose VMs or upload

Unit of Management

Technology platform Deployment

VHDs Gallery

Common web frameworks

Microsoft Guest OS images

Microsoft-provided and usersaved VM images

SLA

None during preview

3 9‘s / (3½ 9‘s Compute)

3 9‘s (single VM)

requires 2+ VMs per role

Let‘s contrast three characteristics that you might care about when using the cloud: automated management, portability of workload between cloud and on-premises, and architectural versatility. As you can see from the magic triangle below, each mode will give you two of the three.

Choice is good, but it comes with the responsibility to choose well. I hope the above has helped to characterize the 3-lane highway that is Windows Azure. Drive safely!

INTRODUCTION TO WINDOWS AZURE CLOUD SERVICES

Millions of developers around the world know how to create applications using the Windows Server programming model. Yet applications written for Windows Azure, Microsoft’s cloud platform, don’t exactly use this familiar model. While most of a Windows developer’s skills still apply, Windows Azure provides its own programming model. Why? Why not just exactly replicate the familiar world of Windows Server in the cloud? Many vendors’ cloud platforms do just this, providing virtual machines (VMs) that act like on-premises VMs. This approach, commonly called Infrastructure as a Service (IaaS), certainly has value, and it’s the right choice for some applications. Yet cloud platforms are a new world, offering the potential for solving today’s problems in new ways. Instead of IaaS, Windows Azure offers a higher-level abstraction that’s typically categorized as Platform as a Service (PaaS). While it’s similar in many ways to the on-premises Windows world, this abstraction has its own programming model meant to help developers build better applications. The Windows Azure programming model focuses on improving applications in three areas: Administration: In PaaS technologies, the platform itself handles the lion’s share of administrative tasks. With Windows Azure, this means that the platform automatically takes care of things such as applying Windows patches and installing new versions of system software. The goal is to reduce the effort—and the cost—of administering the application environment. Availability: Whether it’s planned or not, today’s applications usually have down time for Windows patches, application upgrades, hardware failures, and other reasons. Yet given the redundancy that cloud platforms make possible, there’s no longer any reason to accept this. The Windows Azure programming model is designed to let applications be continuously available, even in the face of software upgrades and hardware failures. Scalability: The kinds of applications that people want to write for the cloud are often meant to handle lots of users. Yet the traditional Windows Server programming model wasn’t explicitly designed to support Internet-scale applications. The Windows Azure programming model, however, was intended from the start to do this. Created for the cloud era, it’s designed to let developers build the scalable applications that massive cloud data centers can support. Just as important, it also allows applications to scale down when necessary, letting them use just the resources they need. Whether a developer uses an IaaS technology or a PaaS offering such as Windows Azure, building applications on cloud platforms has some inherent benefits. Both approaches let you pay only for the computing resources you use, for example, and both let you avoid waiting for your IT department to deploy servers. Yet important as they are, these benefits aren’t the topic here. Instead, the focus is entirely on making clear what the Windows Azure programming model is and what it offers.

THE THREE RULES OF THE WINDOWS AZURE PROGRAMMING MODEL To get the benefits it promises, the Windows Azure programming model imposes three rules on

applications: A Windows Azure application is built from one or more roles. A Windows Azure application runs multiple instances of each role. A Windows Azure application behaves correctly when any role instance fails. It’s worth pointing out that Windows Azure can run applications that don’t follow all of these rules—it doesn’t actually enforce them. Instead, the platform simply assumes that every application obeys all three. Still, while you might choose to run an application on Windows Azure that violates one or more of the rules, be aware that this application isn’t actually using the Windows Azure programming model. Unless you understand and follow the model’s rules, the application might not run as you expect it to.

A WINDOWS AZURE APPLICATION IS BUILT FROM ONE OR MORE ROLES Whether an application runs in the cloud or in your data center, it can almost certainly be divided into logical parts. Windows Azure formalizes these divisions into roles. A role includes a specific set of code, such as a .NET assembly, and it defines the environment in which that code runs. Windows Azure today lets developers create three different kinds of roles: Web role: As the name suggests, Web roles are largely intended for logic that interacts with the outside world via HTTP. Code written as a Web role typically gets its input through Internet Information Services (IIS), and it can be created using various technologies, including ASP.NET, Windows Communication Foundation (WCF), PHP, and Java. Worker role: Logic written as a Worker role can interact with the outside world in various ways—it’s not limited to HTTP. For example, a Worker role might contain code that converts videos into a standard format or calculates the risk of an investment portfolio or performs some kind of data analysis. Virtual Machine (VM) role: A VM role runs an image—a virtual hard disk (VHD)—of a Windows Server 2008 R2 virtual machine. This VHD is created using an on-premises Windows Server machine, then uploaded to Windows Azure. Once it’s stored in the cloud, the VHD can be loaded on demand into a VM role and executed. From January 2012 onwards the Virtual Machine (VM) role is replaced by Windows Azure Virtual Machine. All three roles are useful. The VM role was made available quite recently, however, and so it’s fair to say that the most frequently used options today are Web and Worker roles. Figure 1 shows a simple Windows Azure application built with one Web role and one Worker role.

This application might use a Web role to accept HTTP requests from users, then hand off the work these users request, such as reformatting a video file and making it available for viewing, to a Worker role. A

primary reason for this two-part breakdown is that dividing tasks in this way can make an application easier to scale.

It’s also fine for a Windows Azure application to consist of just a single Web role or a single Worker role— you don’t have to use both. A single application can even contain different kinds of Web and Worker roles. For example, an application might have one Web role that implements a browser interface, perhaps built using ASP.NET, and another Web role that exposes a Web services interface implemented using WCF. Similarly, a Windows Azure application that performed two different kinds of data analysis might define a distinct Worker role for each one. To keep things simple, though, we’ll assume that the example application described here has just one Web role and one Worker role. As part of building a Windows Azure application, a developer creates a service definition file that names and describes the application’s roles. This file can also specify other information, such as the ports each role can listen on. Windows Azure uses this information to build the correct environment for running the application.

A WINDOWS AZURE APPLICATION RUNS MULTIPLE INSTANCES OF EACH ROLE Every Windows Azure application consists of one or more roles. When it executes, an application that conforms to the Windows Azure programming model must run at least two copies—two distinct instances—of each role it contains. Each instance runs as its own VM, as Figure 2 shows.

Figure 2: A Windows Azure application runs multiple instances of each role. As described earlier, the example application shown here has just one Web role and one Worker role. A developer can tell Windows Azure how many instances of each role to run through a service configuration file (which is distinct from the service definition file mentioned in the previous section). Here, the developer has requested four instances of the application’s Web role and three instances of its Worker role. Every instance of a particular role runs the exact same code. In fact, with most Windows Azure applications, each instance is just like all of the other instances of that role—they’re interchangeable. For example, Windows Azure automatically load balances HTTP requests across an application’s Web role instances. This load balancing doesn’t support sticky sessions, so there’s no way to direct all of a client’s requests to the same Web role instance. Storing client-specific state, such as a shopping cart, in a particular Web role instance won’t work, because Windows Azure provides no way to guarantee that all of a client’s requests will be handled by that instance. Instead, this kind of state must be stored externally, as described later.

A WINDOWS AZURE APPLICATION BEHAVES CORRECTLY WHEN ANY ROLE INSTANCE FAILS An application that follows the Windows Azure programming model must be built using roles, and it must run two or more instances of each of those roles. It must also behave correctly when any of those role instances fails. Figure 3 illustrates this idea.

Figure 3: A Windows Azure application behaves correctly even when a role instance fails. Here, the application shown in Figure 2 has lost two of its Web role instances and one of its Worker role instances. Perhaps the computers they were running on failed, or maybe the physical network connection to these machines has gone down. Whatever the reason, the application’s performance is

likely to suffer, since there are fewer instances to carry out its work. Still, the application remains up and functioning correctly

If all instances of a particular role fail, an application will stop behaving as it should—this can’t be helped. Yet the requirement to work correctly during partial failures is fundamental to the Windows Azure programming model. In fact, the service level agreement (SLA) for Windows Azure requires running at least two instances of each role. Applications that run only one instance of any role can’t get the guarantees this SLA provides. The most common way to achieve this is by making every role instance equivalent, as with load-balanced Web roles accepting user requests. This isn’t strictly required, however, as long as the failure of a single role instance doesn’t break the application. For example, an application might use a group of Worker role instances to cache data for Web role instances, with each Worker role instance holding different data. If any Worker role instance fails, a Web role instance trying to access the cached data it contained behaves just as it would if the data wasn’t found in the cache (e.g., it accesses persistent storage to locate that data). The failure might cause the application to run more slowly, but as seen by a user, it still behaves correctly. One more important point to keep in mind is that even though the sample application described so far contains only Web and Worker rules, all of these rules also apply to applications that use VM roles. Just like the others, every VM role must run at least two instances to qualify for the Windows Azure SLA, and the application must continue to work correctly if one of these instances fails. Even with VM roles, Window Azure still provides a form of PaaS—it’s not traditional IaaS.

WHAT THE WINDOWS AZURE PROGRAMMING MODEL PROVIDES The Windows Azure programming model is based on Windows, and the bulk of a Windows developer’s skills are applicable to this new environment. Still, it’s not the same as the conventional Windows Server programming model. So why bother to understand it? How does it help create better applications? To answer these questions, it’s first worth explaining a little more about how Windows Azure works. Once this is clear, understanding how the Windows Azure programming model can help create better software is simple.

SOME BACKGROUND: THE FABRIC CONTROLLER Windows Azure is designed to run in data centers containing lots of computers. Accordingly, every Windows Azure application runs on multiple machines simultaneously. Figure 4 shows a simple example of how this looks.

Figure 4: The Windows Azure fabric controller creates instances of an application’s roles on different machines, then monitors their execution. As Figure 4 shows, all of the computers in a particular Windows Azure data center are managed by an application called the fabric controller. The fabric controller is itself a distributed application that runs across multiple computers. When a developer gives Windows Azure an application to run, he provides the code for the application’s roles together with the service definition and service configuration files for this application. Among other things, this information tells the fabric controller how many instances of each role it should create. The fabric controller chooses a physical machine for each instance, then creates a VM on that machine and starts the instance running. As the figure suggests, the role instances for a single application are spread across different machines within this data center. Once it’s created these instances, the fabric controller continues to monitor them. If an instance fails for any reason—hardware or software—the fabric controller will start a new instance for that role. While failures might cause an application’s instance count to temporarily drop below what the developer requested, the fabric controller will always start new instances as needed to maintain the target number for each of the application’s roles. And even though Figure 4 shows only Web and Worker roles, VM roles are handled in the same way, with each of the role’s instances running on a different physical machine.

THE BENEFITS: IMPROVED ADMINISTRATION, AVAILABILITY, AND SCALABILITY Applications built using the Windows Azure programming model can be easier to administer, more available, and more scalable than those built on traditional Windows servers. These three attributes are worth looking at separately.

The administrative benefits of Windows Azure flow largely from the fabric controller. Like every operating system, Windows must be patched, as must other system software. In on-premises environments, doing this typically requires some human effort. In Windows Azure, however, the process is entirely automated: The fabric controller handles updates for Web and Worker role instances (although not for VM role instances). When necessary, it also updates the underlying Windows servers those VMs run on. The result is lower costs, since administrators aren’t needed to handle this function. Lowering costs by requiring less administration is good. Helping applications be more available is also good, and so the Windows Azure programming model helps improve application availability in several ways. They are the following: Protection against hardware failures. Because every application is made up of multiple instances of each role, hardware failures—a disk crash, a network fault, or the death of a server machine—won’t take down the application. To help with this, the fabric controller doesn’t choose machines for an application’s instances at random. Instead, different instances of the same role are placed in different fault domains. A fault domain is a set of hardware—computers, switches, and more—that share a single point of failure. (For example, all of the computers in a single fault domain might rely on the same switch to connect to the network.) Because of this, a single hardware failure can’t take down an entire application. The application might temporarily lose some instances, but it will continue to behave correctly. Protection against software failures. Along with hardware failures, the fabric controller can also detect failures caused by software. If the code in an instance crashes or the VM in which it’s running goes down, the fabric controller will start either just the code or, if necessary, a new VM for that role. While any work the instance was doing when it failed will be lost, the new instance will become part of the application as soon as it starts running. The ability to update applications with no application downtime. Whether for routine maintenance or to install a whole new version, every application needs to be updated. An application built using the Windows Azure programming model can be updated while it’s running—there’s no need to take it down. To allow this, different instances for each of an application’s roles are placed in different update domains (which aren’t the same as the fault domains described earlier). When a new version of the application needs to be deployed, the fabric controller can shut down the instances in just one update domain, update the code for these, then create new instances from that new code. Once those instances are running, it can do the same thing to instances in the next update domain, and so on. While users might see different versions of the application during this process, depending on which instance they happen to interact with, the application as a whole remains continuously available. The ability to update Windows and other supporting software with no application downtime. The fabric controller assumes that every Windows Azure application follows the three rules listed earlier, and so it knows that it can shut down some of an application’s instances whenever it likes, update the underlying system software, then start new instances. By doing this in chunks, never shutting down all of a role’s instances at the same time, Windows and other software can be updated beneath a continuously running application.

Availability is important for most applications—software isn’t useful if it’s not running when you need it— but scalability can also matter. The Windows Azure programming model helps developers build more scalable applications in two main ways: Automatically creating and maintaining a specified number of role instances. As already described, a developer tells Windows Azure how many instances of each role to run, and the fabric controller creates and monitors the requested instances. This makes application scalability quite straightforward: Just tell Windows Azure what you need. Because this cloud platform runs in very large data centers, getting whatever level of scalability an application needs isn’t generally a problem. Providing a way to modify the number of executing role instances for a running application: For applications whose load varies, scalability is more complicated. Setting the number of instances just once isn’t a good solution, since different loads can make the ideal instance count go up or down significantly. To handle this situation, Windows Azure provides both a Web portal for people and an API for applications to allow changing the desired number of instances for each role while an application is running. Making applications simpler to administer, more available, and more scalable is useful, and so using the Windows Azure programming model generally makes sense. But as mentioned earlier, it’s possible to run applications on Windows Azure that don’t follow this model. Suppose, for example, that you build an application using a single role (which is permitted) but then run only one instance of that role (violating the second and third rules). You might do this to save money, since Windows Azure charges separately for each running instance. Anybody who chooses this option should understand, however, that the fabric controller won’t know that his application doesn’t follow all three rules. It will shut down this single instance at unpredictable times to patch the underlying software, then restart a new one. To users, this means that the application will go down from time to time, since there’s no other instance to take over. This isn’t a bug in Windows Azure; it’s a fundamental aspect of how the technology works. Getting all of the benefits that Windows Azure offers requires conforming to the rules of its programming model. Moving existing applications from Windows Server to Windows Azure can require some work, a topic addressed in more detail later in this paper. For new applications, however, the argument for using the Windows Azure model is clear. Why not build an application that costs less to administer? Why not build an application that need never go down? Why not build an application that can easily scale up and down? Over time, it’s reasonable to expect more and more applications to be created using the Windows

Azure programming model.

IMPLICATIONS OF THE WINDOWS AZURE PROGRAMMING MODEL: WHAT ELSE CHANGES? Building applications for Windows Azure means following the three rules of its programming model. Following these rules isn’t enough, though—other parts of a developer’s world must also adjust. The changes the Windows Azure programming model brings to the broader development environment can be grouped into three areas: How role instances interact with the operating system. How role instances interact with persistent storage.

How role instances interact with other role instances. This section looks at all three.

INTERACTIONS WITH THE OPERATING SYSTEM For an application running on a typical Windows Server machine, the administrator of that machine is in control. She can reboot VMs or the machine they run on, install Windows patches, and do whatever else is required to keep that computer available. In Windows Azure, however, all of the servers are owned by the fabric controller. It decides when VMs or machines should be rebooted, and for Web and Worker roles (although not for VM roles), the fabric controller also installs patches and other updates to the system software in every instance. This approach has real benefits, as already described. It also creates restrictions, however. Because the fabric controller owns the physical and virtual machines that Windows Azure applications use, it’s free to do whatever it likes with them. This implies that letting a Windows Azure application modify the system it runs on—letting it run in administrator mode rather than user mode—presents some challenges. Since the fabric controller can modify the operating system at will, there’s no guarantee that changes a role instance makes to the system it’s running on won’t be overwritten. Besides, the specific virtual (and physical) machines an application runs in change over time. This implies that any changes made to the default local environment must be made each time a role instance starts running. In its first release, Windows Azure simply didn’t allow applications to modify the systems they ran on— applications only ran in user mode. This restriction has been relaxed—both Web and Worker roles now give developers the option to run applications in admin mode—but the overall programming model hasn’t changed. Anybody creating a Windows Azure application needs to understand what the fabric controller is doing, then design applications accordingly.

INTERACTIONS WITH PERSISTENT STORAGE Applications aren’t just code—they also use data. And just as the programming model must change to make applications more available and more scalable, the way data is stored and accessed must also change. The big changes are these: Storage must be external to role instances. Even though each instance is its own VM with its own file system, data stored in those file systems isn’t automatically made persistent. If an instance fails, any data it contains may be lost. This implies that for applications to work correctly in the face of failures, data must be stored persistently outside role instances. Another role instance can now access data that otherwise would have been lost if that data had been stored locally on a failed instance. Storage must be replicated. Just as a Windows Azure application runs multiple role instances to allow for failures, Windows Azure storage must provide multiple copies of data. Without this, a single failure would make data unavailable, something that’s not acceptable for highly available applications. Storage must be able to handle very large amounts of data. Traditional relational systems aren’t necessarily the best choice for very large data sets. Since Windows Azure is designed in part for massively scalable applications, it must provide storage mechanisms for handling data at this scale.

To allow this, the platform offers blobs for storing binary data along with a non-SQL approach called tables for storing large structured data sets. Figure 5 illustrates these three characteristics, showing how Windows Azure storage looks to an application.

Figure 5: While applications see a single copy, Windows Azure storage replicates all blobs and tables three times. In this example, a Windows Azure application is using two blobs and one table from Windows Azure storage. The application sees each blob and table as a single entity, but under the covers, Windows Azure storage actually maintains three instances of each one. These copies are spread across different physical machines, and as with role instances, those machines are in different fault domains. This improves the application’s availability, since data is still accessible even when some copies are unavailable. And because persistent data is stored outside any of the application’s role instances, an instance failure loses only whatever data it was using at the moment it failed. The Windows Azure programming model requires an application to behave correctly when a role instance fails. To do this, every instance in an application must store all persistent data in Windows Azure storage or another external storage mechanism (such as SQL Azure, Microsoft’s cloud-based service for relational data). There’s one more option worth mentioning, however: Windows Azure drives. As already described, any data an application writes to the local file system of its own VM can be lost when that VM stops running. Windows Azure drives change this, using a blob to provide persistent storage for the file system of a particular instance. These drives have some limitations—only one instance at a time is allowed to

both read from and write to a particular Windows Azure drive, for example, with all other instances in this application allowed only read access—but they can be useful in some situations.

INTERACTIONS AMONG ROLE INSTANCES When an application is divided into multiple parts, those parts commonly need to interact with one another. In a Windows Azure application, this is expressed as communication between role instances. For example, a Web role instance might accept requests from users, then pass those requests to a Worker role instance for further processing. The way this interaction happens isn’t identical to how it’s done with ordinary Windows applications. Once again, a key fact to keep in mind is that, most often, all instances of a particular role are equivalent—they’re interchangeable. This means that when, say, a Web role instance passes work to a Worker role instance, it shouldn’t care which particular instance gets the work. In fact, the Web role instance shouldn’t rely on instance-specific things like a Worker role instance’s IP address to communicate with that instance. More generic mechanisms are required. The most common way for role instances to communicate in Windows Azure applications is through Windows Azure queues. Figure 6 illustrates the idea.

Figure 6: Role instances can communicate through queues, each of which replicates the messages it holds three times. In the example shown here, a Web role instance gets work from a user of the application, such as a person making a request from a browser (step 1). This instance then creates a message containing this work and writes it into a Windows Azure queue (step 2). These queues are implemented as part of Windows Azure storage, and so like blobs and tables, each queue is replicated three times, as the figure

shows. As usual, this provides fault-tolerance, ensuring that the queue’s messages are still available if a failure occurs. Next, a Worker role instance reads the message from the queue (step 3). Notice that the Web role instance that created this message doesn’t care which Worker role instance gets it—in this application, they’re all equivalent. That Worker role instance does whatever work the message requires (step 4), then deletes the message from the queue (step 5). This last step—explicitly removing the message from the queue—is different from what on-premises queuing technologies typically do. In Microsoft Message Queuing (MSMQ), for example, an application can do a read inside an atomic transaction. If the application fails before completing its work, the transaction aborts, and the message automatically reappears on the queue. This approach guarantees that every message sent to an MSMQ queue is delivered exactly once in the order in which it was sent.

Windows Azure queues don’t support transactional reads, and so they don’t guarantee exactly-once, in-order delivery. In the example shown in Figure 6, for instance, the Worker role instance might finish processing the message, then crash just before it deletes this message from the queue. If this happens, the message will automatically reappear after a configurable timeout period, and another Worker role instance will process it. Unlike MSMQ, Windows Azure queues provide at-least-once semantics: A message might be read and processed one or more times. This raises an obvious question: Why don’t Windows Azure queues support transactional reads? The answer is that transactions require locking, and so they necessarily slow things down (especially with the message replication provided by Windows Azure queues). Given the primary goals of the platform, its designers opted for the fastest, most scalable approach. Most of the time, queues are the best way for role instances within an application to communicate. It’s also possible for instances to interact directly, however, without going through a queue. To allow this, Windows Azure provides an API that lets an instance discover all other instances in the same application that meet specific requirements, then send a request directly to one of those instances. In the most common case, where all instances of a particular role are equivalent, the caller should choose a target instance randomly from the set the API returns. This isn’t always true—maybe a Worker role implements an in-memory cache with each role instance holding specific data, and so the caller must access a particular one. Most often, though, the right approach is to treat all instances of a role as interchangeable.

MOVING WINDOWS SERVER APPLICATIONS TO WINDOWS AZURE Anybody building a new Windows Azure application should follow the rules of the Windows Azure programming model. To move an existing application from Windows Server to Windows Azure, however, that application should also be made to follow the same rules. In addition, the application might need to change how it interacts with the operating system, how it uses persistent storage, and the way its components interact with each other. How easy it is to make these changes depends on the application. Here are a few representative examples:

An ASP.NET application with multiple load-balanced instances that share state stored in SQL Server. This kind of application typically ports easily to Windows Azure, with each instance of the original application becoming an instance of a Web or Worker role. Applications like this don’t use sticky sessions, which helps make them a good fit for Windows Azure. (Using ASP.NET session state is acceptable, however, since Windows Azure provides an option to store session state persistently in Windows Azure Storage tables.) And moving an on-premises SQL Server database to SQL Azure is usually straightforward. An ASP.NET application with multiple instances that maintains per-instance state and relies on sticky sessions. Because it maintains client-specific state in each instance between requests, this application will need some changes. Windows Azure doesn’t support sticky sessions, and so making the application run on this cloud platform will require redesigning how it handles state. A Silverlight or Windows Presentation Foundation (WPF) client that accesses WCF services running in a middle tier. If the services don’t maintain per-client state between calls, moving them to Windows Azure is straightforward. The client will continue to run on user desktops, as always, but it will now call services running on Windows Azure. If the current services do maintain per-client state, however, they’ll need to be redesigned. An application with a single instance running on Windows Server that maintains state on its own machine. Whether the clients are browsers or something else, many enterprise applications are built this way today, and they won’t work well on Windows Azure without some redesign. It might be possible to run this application unchanged in a single VM role instance, but its users probably won’t be happy with the results. For one thing, the Windows Azure SLA doesn’t apply to applications with only a single instance. Also, recall that the fabric controller can at any time reboot the machine on which this instance runs to update that machine’s software. The application has no control over when this happens; it might be smack in the middle of a workday. Since there’s no second instance to take over—the application wasn’t built to follow the rules of the Windows Azure programming model—it will be unavailable for some period of time, and so anybody using the application will have their work interrupted while the machine reboots. Even though the VM role makes it easy to move a Windows Server binary to Windows Azure, this doesn’t guarantee that the application will run successfully in its new home. The application must also conform to the rules of the Windows Azure programming model. A Visual Basic 6 application that directly accesses a SQL Server database, i.e., a traditional client/server application. Making this application run on Windows Azure will most likely require rewriting at least the client business logic. While it might be possible to move the database (including any stored procedures) to SQL Azure, then redirect the clients to this new location, the application’s desktop component won’t run as is on Windows Azure. Windows Azure doesn’t provide a local user interface, and it also doesn’t support using Remote Desktop Services (formerly Terminal Services) to provide remote user interfaces. Windows Azure can help developers create better applications. Yet the improvements it offers require change, and so moving existing software to this new platform can take some effort. Making good decisions requires understanding both the potential business value and any technical challenges that moving an application to Windows Azure might bring.

CONCLUSION Cloud platforms are a new world, and they open new possibilities. Reflecting this, the Windows Azure programming model helps developers create applications that are easier to administer, more available, and more scalable than those built in the traditional Windows Server environment. Doing this requires following three rules: A Windows Azure application is built from one or more roles. A Windows Azure application runs multiple instances of each role. A Windows Azure application behaves correctly when any role instance fails. Using this programming model successfully also requires understanding the changes it brings to how applications interact with the operating system, use persistent storage, and communicate between role instances. For developers willing to do this, however, the value is clear. While it’s not right for every scenario, the Windows Azure programming model can be useful for anybody who wants to create easier to administer, more available, and more scalable applications.

FOR FURTHER READING Introducing Windows Azure: http://go.microsoft.com/?linkid=9682907 Introducing the Windows Azure Platform: http://go.microsoft.com/?linkid=9752185

Cloud service concept When you create an application and run it in Windows Azure, the code and configuration together are called a Windows Azure cloud service (known as a hosted service in earlier Windows Azure releases). By creating a cloud service, you can deploy a multi-tier application in Windows Azure, defining multiple roles to distribute processing and allow flexible scaling of your application. A cloud service consists of one or more web roles and/or worker roles, each with its own application files and configuration. For a cloud service, Windows Azure maintains the infrastructure for you, performing routine maintenance, patching the operating systems, and attempting to recover from service and hardware failures. If you define at least two instances of every role, most maintenance, as well as your own service upgrades, can be performed without any interruption in service. A cloud service must have at least two instances of every role to qualify for the Windows Azure Service Level Agreement, which guarantees external connectivity to your Internet-facing roles at least 99.95 of the time. Each cloud service has two environments to which you can deploy your service package and configuration. You can deploy a cloud service to the staging environment to test it before you promote it to production. Promoting a staged cloud service to production is a simple matter of swapping the virtual IP addresses (VIPs) that are associated with the two environments. 

cloud service role: A cloud service role is comprised of application files and a configuration. A cloud service can have two types of role: 

web role:A web role provides a dedicated Internet Information Services (IIS) web-server used for hosting front-end web applications.



worker role: Applications hosted within worker roles can run asynchronous, long-running or perpetual tasks independent of user interaction or input.



role instance: A role instance is a virtual machine on which the application code and role configuration run. A role can have multiple instances, defined in the service configuration file.



guest operating system: The guest operating system for a cloud service is the operating system installed on the role instances (virtual machines) on which your application code runs.



cloud service components: Three components are required in order to deploy an application as a cloud service in Windows Azure:



service definition file: The cloud service definition file (.csdef) defines the service model, including the number of roles.



service configuration file: The cloud service configuration file (.cscfg) provides configuration settings for the cloud service and individual roles, including the number of role instances.



service package: The service package (.cspkg) contains the application code and the service definition file.



cloud service deployment: A cloud service deployment is an instance of a cloud service deployed to the Windows Azure staging or production environment. You can maintain deployments in both staging and production.



deployment environments: Windows Azure offers two deployment environments for cloud services: astaging environment in which you can test your deployment before you promote it to the production environment. The two environments are distinguished only by the virtual IP addresses (VIPs) by which the cloud service is accessed. In the staging environment, the cloud service's globally unique identifier (GUID) identifies it in URLs (GUID.cloudapp.net). In the production environment, the URL is based on the friendlier DNS prefix assigned to the cloud service (for example, myservice.cloudapp.net).



swap deployments: To promote a deployment in the Windows Azure staging environment to the production environment, you can "swap" the deployments by switching the VIPs by which the two deployments are accessed. After the deployment, the DNS name for the cloud service points to the deployment that had been in the staging environment.



minimal vs. verbose monitoring: Minimal monitoring, which is configured by default for a cloud service, uses performance counters gathered from the host operating systems for role instances (virtual machines).Verbose monitoring gathers additional metrics based on performance data within the role instances to enable closer analysis of issues that occur during application processing. For more information, see How to Monitor Cloud Services.



Windows Azure Diagnostics: Windows Azure Diagnostics is the API that enables you to collect diagnostic data from applications running in Windows Azure. Windows Azure Diagnostics must be enabled for cloud service roles in order for verbose monitoring to be turned on.



link a resource: To show your cloud service's dependencies on other resources, such as a Windows Azure SQL Database instance, you can "link" the resource to the cloud service. In the Preview Management Portal, you can view linked resources on the Linked Resources page, view their status on the dashboard, and scale a linked SQL Database instance along with the service roles on the Scale page. Linking a resource in this sense does not connect the resource to the application; you must configure the connections in the application code.



scale a cloud service: A cloud service is scaled out by increasing the number of role instances (virtual machines) deployed for a role. A cloud service is scaled in by decreasing role instances. In the Preview Management Portal, you can also scale a linked SQL Database instance, by changing the SQL Database edition and the maximum database size, when you scale your service roles.



Windows Azure Service Level Agreement (SLA): The Windows Azure Compute SLA guarantees that, when you deploy two or more role instances for every role, access to your cloud service will be maintained at least 99.95 percent of the time. Also, detection and corrective action will be initiated 99.9 percent of the time when a role instance‘s process is not running. For more information, see Service Level Agreements.

LECTURE 5: Data Management and Business Analytics Managing and analyzing data in the cloud is just as important as it is anywhere else. To let you do this, Windows Azure provides a range of technologies for working with relational and non-relational data. This article introduces each of the options.

Table of Contents 

Blob Storage



Running a DBMS in a Virtual Machine SQL Database SQL Data Sync

 o o  

SQL Data Reporting Table Storage Hadoop

Blob Storage The word "blob" is short for "Binary Large OBject", and it describes exactly what a blob is: a collection of binary information. Yet even though they‘re simple, blobs are quite useful. Figure 1 illustrates the basics of Windows Azure Blob Storage.

Figure 1: Windows Azure Blob Storage stores binary data—blobs—in containers. To use blobs, you first create a Windows Azure storage account. As part of this, you specify the Windows Azure datacenter that will store the objects you create using this account. Wherever it lives, each blob you create belongs to some container in your storage account. To access a blob, an application provides a URL with the form: http://.blob.core.windows.net// is a unique identifier assigned when a new storage account is created, while and are the names of a specific container and a blob within that container. Windows Azure provides two different kinds of blobs. The choices are: 

Block blobs, each of which can contain up to 200 gigabytes of data. As its name suggests, a block blob is subdivided into some number of blocks. If a failure occurs while transferring a block blob, retransmission can resume with the most recent block rather than sending the entire blob again. Block blobs are a quite general approach to storage, and they‘re the most commonly used blob type today.



Page blobs, which can be as large at one terabyte each. Page blobs are designed for random access, and so each one is divided into some number of pages. An application is free to read and write

individual pages at random in the blob. In Windows Azure Virtual Machines, for example, VMs you create use page blobs as persistent storage for both OS disks and data disks. Whether you choose block blobs or page blobs, applications can access blob data in several different ways. The options include the following:  



Directly through a RESTful (i.e., HTTP-based) access protocol. Both Windows Azure applications and external applications, including apps running on premises, can use this option. Using the Windows Azure Storage Client library, which provides a more developer-friendly interface on top of the raw RESTful blob access protocol. Once again, both Windows Azure applications and external applications can access blobs using this library. Using Windows Azure drives, an option that lets a Windows Azure application treat a page blob as a local drive with an NTFS file system. To the application, the page blob looks like an ordinary Windows file system accessed using standard file I/O. In fact, reads and writes are sent to the underlying page blob that implements the Windows Azure Drive. To guard against hardware failures and improve availability, every blob is replicated across three computers in a Windows Azure datacenter. Writing to a blob updates all three copies, so later reads won‘t see inconsistent results. You can also specify that a blob‘s data should be copied to another Windows Azure datacenter in the same region but at least 500 miles away. This copying, called georeplication, happens within a few minutes of an update to the blob, and it‘s useful for disaster recovery. Data in blobs can also be made available via the Windows Azure Content Delivery Network (CDN). By caching copies of blob data at dozens of servers around the world, the CDN can speed up access to information that‘s accessed repeatedly. Simple as they are, blobs are the right choice in many situations. Storing and streaming video and audio are obvious examples, as are backups and other kinds of data archiving. Developers can also use blobs to hold any kind of unstructured data they like. Having a straightforward way to store and access binary data can be surprisingly useful.

Running a DBMS in a Virtual Machine Many applications today rely on some kind of database management system (DBMS). Relational systems such as SQL Server are the most frequently used choice, but non-relational approaches, commonly known as NoSQLtechnologies, get more popular every day. To let cloud applications use these data management options, Windows Azure Virtual Machines allows you to run a DBMS (relational or NoSQL) in a VM. Figure 2 shows how this looks with SQL Server.

Figure 2: Windows Azure Virtual Machines allows running a DBMS in a VM, with persistence provided by blobs. To both developers and database administrators, this scenario looks much like running the same software in their own datacenter. In the example shown here, for instance, nearly all of SQL Server‘s capabilities can be used, and you have full administrative access to the system. You also have the responsibility of managing the database server, of course, just as if it were running locally. As Figure 2 shows, your databases appear to be stored on the local disk of the VM the server runs in. Under the covers, however, each of those disks is written to a Windows Azure blob. (It‘s similar to using a SAN in your own datacenter, with a blob acting much like a LUN.) As with any Windows Azure blob, the data it contains is replicated three times within a datacenter and, if you request it, geo-replicated to another datacenter in the same region. It‘s also possible to use options such as SQL Server database mirroring for improved reliability. Another way to use SQL Server in a VM is to create a hybrid application, where the data lives on Windows Azure while the application logic runs on-premises. For example, this might make sense when applications running in multiple locations or on various mobile devices must share the same data. To make communication between the cloud database and on-premises logic simpler, an organization can use Windows Azure Virtual Network to create a virtual private network (VPN) connection between a Windows Azure datacenter and its own on-premises datacenter.

SQL Database For many people, running a DBMS in a VM is the first option that comes to mind for managing structured data in the cloud. It‘s not the only choice, though, nor is it always the best choice. In some cases, managing data using a Platform as a Service (PaaS) approach makes more sense. Windows Azure provides a PaaS technology called SQL Database that lets you do this for relational data. Figure 3 illustrates this option.

Figure 3: SQL Database provides a shared PaaS relational storage service. SQL Database doesn‘t give each customer its own physical instance of SQL Server. Instead, it provides a multi-tenant service, with a logical SQL Database server for each customer. All customers share the compute and storage capacity that the service provides. And as with Blob Storage, all data in SQL Database is stored on three separate computers within a Windows Azure datacenter, giving your databases built-in high availability (HA). To an application, SQL Database looks much like SQL Server. Applications can issue SQL queries against relational tables, use T-SQL stored procedures, and execute transactions across multiple tables. And because applications access SQL Database using the Tabular Data Stream (TDS) protocol, the same protocol used to access SQL Server, they can work with data using Entity Framework, ADO.NET, JDBC, and other familiar data access interfaces. But because SQL Database is a cloud service running in Windows Azure data centers, you don‘t need to manage any of the system‘s physical aspects, such as disk usage. You also don‘t need to worry about updating software or handling other low-level administrative tasks. Each customer organization still controls its own databases, of course, including their schemas and user logins, but many of the mundane administrative tasks are done for you. While SQL Database looks much like SQL Server to applications, it doesn‘t behave exactly the same as a DBMS running on a physical or virtual machine. Because it runs on shared hardware, its performance will vary with the load placed on that hardware by all of its customers. This means that the performance of, say, a stored procedure in SQL Database might vary from one day to the next.

Today, SQL Database lets you create a database holding up to 150 gigabytes. If you need to work with larger databases, the service provides an option called Federation. To do this, a database administrator creates two or more federation members, each of which is a separate database with its own schema. Data is spread across these members, something that‘s often referred to as sharding, with each member assigned a unique federation key. An application issues SQL queries against this data by specifying the federation key that identifies the federation member the query should target. This allows using a traditional relational approach with large amounts of data. As always, there are trade-offs; neither queries nor transactions can span federation members, for instance. But when a relational PaaS service is the best choice and these trade-offs are acceptable, using SQL Federation can be a good solution. SQL Database can be used by applications running on Windows Azure or elsewhere, such as in your on-premises datacenter. This makes it useful for cloud applications that need relational data, as well as on-premises applications that can benefit from storing data in the cloud. A mobile application might rely on SQL Database to manage shared relational data, for instance, as might an inventory application that runs at multiple dealers around the world. Thinking about SQL Database raises an obvious (and important) issue: When should you run SQL Server in a VM, and when is SQL Database a better choice? As usual, there are trade-offs, and so which approach is better depends on your requirements. One simple way to think about it is to view SQL Database as being for new applications, while SQL Server in a VM is a better choice when you‘re moving an existing on-premises application to the cloud. It can also be useful to look at this decision in a more fine-grained way, however. For example, SQL Database is easier to use, since there‘s minimal setup and administration. But running SQL Server in a VM can have more predictable performance—it‘s not a shared service—and it also supports larger non-federated databases than SQL Database. Still, SQL Database provides built-in replication of both data and processing, effectively giving you a high-availability DBMS with very little work. While SQL Server gives you more control and a somewhat broader set of options, SQL Database is simpler to set up and significantly less work to manage. Finally, it‘s important to point out that SQL Database isn‘t the only PaaS data service available on Windows Azure. Microsoft partners provide other options as well. For example, ClearDB offers a MySQL PaaS offering, while Cloudant sells a NoSQL option. PaaS data services are the right solution in many situations, and so this approach to data management is an important part of Windows Azure. SQL Data Sync While SQL Database does maintain three copies of each database within a single Windows Azure datacenter, it doesn‘t automatically replicate data between Windows Azure datacenters. Instead, it provides SQL Data Sync, a service that you can use to do this. Figure 4 shows how this looks.

Figure 4: SQL Data Sync synchronizes data in SQL Database with data in other Windows Azure and on-premises datacenters. As the diagram shows, SQL Data Sync can synchronize data across different locations. Suppose you‘re running an application in multiple Windows Azure datacenters, for instance, with data stored in SQL Database. You can use SQL Data Sync to keep that data synchronized. SQL Data Sync can also synchronize data between a Windows Azure datacenter and an instance of SQL Server running in an on-premises datacenter. This might be useful for maintaining both a local copy of data used by onpremises applications and a cloud copy used by applications running on Windows Azure. And although it‘s not shown in the figure, SQL Data Sync can also be used to synchronize data between SQL Database and SQL Server running in a VM on Windows Azure or elsewhere. Synchronization can be bi-directional, and you determine exactly what data is synchronized and how frequently it‘s done. (Synchronization between databases isn‘t atomic, however—there‘s always at least some delay.) And however it‘s used, setting up synchronization with SQL Data Sync is entirely configuration-driven; there‘s no code to write. SQL Data Reporting

Once a database contains data, somebody will probably want to create reports using that data. To let you do this with data stored in SQL Database, Windows Azure provides SQL Reporting. This cloud service provides a subset of the functionality in SQL Server Reporting Services (SSRS), the reporting technology included with SQL Server. In its initial incarnation, SQL Reporting is aimed primarily at independent software vendors (ISVs) who need to embed reports in their applications. Figure 5 shows how the process works.

Figure 5: Windows Azure SQL Reporting provides reporting services for data in SQL Database. Before a user can see a report, someone defines what that report should look like (step 1). With SQL Reporting, this can be done using either of two tools: SQL Server Data Tools, part of SQL Server 2012, or its predecessor, Business Intelligence (BI) Development Studio. As with SSRS, these report definitions are expressed in the Report Definition Language (RDL). After the RDL files for a report have been created, they are uploaded to SQL Reporting in the cloud (step 2). The report definition is now ready to use. Next, a user of the application accesses the report (step 3). The application passes this request to SQL Reporting (step 4), which contacts SQL Database to get the data it needs (step 5). SQL Reporting uses this data and the relevant RDL files to render the report (step 6), then returns the report to the application (step 7), which displays it to the user (step 8). Embedding a report in an application, the scenario shown here, isn‘t the only option. It‘s also possible to view reports in a SQL Reporting portal or in other ways. Reports can also be combined, with one report containing a link to another.

Like SQL Database, SQL Reporting is a multi-tenant PaaS service. You can use it immediately—there‘s nothing to install—and it requires minimal management. Microsoft monitors the service, provides patches, handles scaling, and does the other work needed to keep the service available. While it‘s possible to run reports on SQL Database tables using the on-premises version of SSRS, SQL Reporting is typically a better alternative for adding reporting to Windows Azure applications.

Table Storage Relational data is useful in many situations, but it‘s not always the right choice. If your application needs fast, simple access to very large amounts of loosely structured data, for instance, a relational database might not work well. A NoSQL technology is likely to be a better option. Windows Azure Table Storage is an example of this kind of NoSQL approach. Despite its name, Table Storage doesn‘t support standard relational tables. Instead, it provides what‘s known as a key/value store, associating a set of data with a particular key, then letting an application access that data by providing the key. Figure 6illustrates the basics.

Figure 6: Windows Azure Table Storage is a key/value store that provides fast, simple access to large amounts of data. Like blobs, each table is associated with a Windows Azure storage account. Tables are also named much like blobs, with a URL of the form http://.table.core.windows.net/ As the figure shows, each table is divided into some number of partitions, each of which can be stored on a separate machine. (This is a form of sharding, as with SQL Federation.) Both Windows Azure applications and applications running elsewhere can access a table using either the RESTful OData protocol or the Windows Azure Storage Client library.

Each partition in a table holds some number of entities, each containing as many as 255 properties. Every property has a name, a type (such as Binary, Bool, DateTime, Int, or String), and a value. Unlike relational storage, these tables have no fixed schema, and so different entities in the same table can contain properties with different types. One entity might have just a String property containing a name, for example, while another entity in the same table has two Int properties containing a customer ID number and a credit rating. To identify a particular entity within a table, an application provides that entity‘s key. The key has two parts: apartition key that identifies a specific partition and a row key that identifies an entity within that partition. InFigure 6, for example, the client requests the entity with partition key A and row key 3, and Table Storage returns that entity, including all of the properties it contains. This structure lets tables be big—a single table can contain up to 100 terabytes of data—and it allows fast access to the data they contain. It also brings limitations, however. For example, there‘s no support for transactional updates that span tables or even partitions in a single table. A set of updates to a table can only be grouped into an atomic transaction if all of the entities involved are in the same partition. There‘s also no way to query a table based on the value of its properties, nor is there support for joins across multiple tables. And unlike relational databases, tables have no support for stored procedures. Windows Azure Table Storage is a good choice for applications that need fast, cheap access to large amounts of loosely structured data. For example, an Internet application that stores profile information for lots of users might use tables. Fast access is important in this situation, and the application probably doesn‘t need the full power of SQL. Giving up this functionality to gain speed and size can sometimes make sense, and so Table Storage is just the right solution for some problems.

Hadoop Organizations have been building data warehouses for decades. These collections of information, most often stored in relational tables, let people work with and learn from data in many different ways. With SQL Server, for instance, it‘s common to use tools such as SQL Server Analysis Services to do this. But suppose you want to do analysis on non-relational data. Your data might take many forms: information from sensors or RFID tags, log files in server farms, clickstream data produced by web applications, images from medical diagnostic devices, and more. This data might also be really big, too big to be used effectively with a traditional data warehouse. Big data problems like this, rare just a few years ago, have now become quite common.

To analyze this kind of big data, our industry has largely converged on a single solution: the opensource technology Hadoop. Hadoop runs on a cluster of physical or virtual machines, spreading the data it works on across those machines and processing it in parallel. The more machines Hadoop has to use, the faster it can complete whatever work it‘s doing. This kind of problem is a natural fit for the public cloud. Rather than maintaining an army of onpremises servers that might sit idle much of the time, running Hadoop in the cloud lets you create (and pay for) VMs only when you need them. Even better, more and more of the big data that you want to analyze with Hadoop is created in the cloud, saving you the trouble of moving it around. To help you exploit these synergies, Microsoft provides a Hadoop service on Windows Azure. Figure 7 shows the most important components of this service.

Figure 7: Hadoop on Windows Azure runs MapReduce jobs that process data in parallel using multiple virtual machines. To use Hadoop on Windows Azure, you first ask this cloud platform to create a Hadoop cluster, specifying the number of VMs you need. Setting up a Hadoop cluster yourself is a non-trivial task, and so letting Windows Azure do it for you makes sense. When you‘re done using the cluster, you shut it down. There‘s no need to pay for compute resources that you aren‘t using. A Hadoop application, commonly called a job, uses a programming model known as MapReduce. As the figure shows, the logic for a MapReduce job runs simultaneously across many VMs. By processing data in parallel, Hadoop can analyze data much more rapidly than single-machine solutions.

On Windows Azure, the data a MapReduce job works on is typically kept in blob storage. In Hadoop, however, MapReduce jobs expect data to be stored in the Hadoop Distributed File System (HDFS). HDFS is similar to Blob Storage in some ways; it replicates data across multiple physical servers, for example. Rather than duplicate this functionality, Hadoop on Windows Azure instead exposes Blob Storage through the HDFS API, as the figure shows. While the logic in a MapReduce job thinks it‘s accessing ordinary HDFS files, the job is in fact working with data streamed to it from blobs. And to support the case where multiple jobs are run over the same data, Hadoop on Windows Azure also allow copying data from blobs into full HDFS running in the VMs. MapReduce jobs are commonly written in Java today, an approach that Hadoop on Windows Azure supports. Microsoft has also added support for creating MapReduce jobs in other languages, including C#, F#, and JavaScript. The goal is to make this big data technology more easily accessible to a larger group of developers. Along with HDFS and MapReduce, Hadoop includes other technologies that let people analyze data without writing a MapReduce job themselves. For example, Pig is a high-level language designed for analyzing big data, while Hive offers a SQL-like language called HiveQL. Both Pig and Hive actually generate MapReduce jobs that process HDFS data, but they hide this complexity from their users. Both are provided with Hadoop on Windows Azure. Microsoft also provides a HiveQL driver for Excel. Using an Excel add-in, business analysts can create HiveQL queries (and thus MapReduce jobs) directly from Excel, then process and visualize the results using PowerPivot and other Excel tools. Hadoop on Windows Azure includes other technologies as well, such as the machine learning libraries Mahout, the graph mining system Pegasus, and more. Big data analysis is important, and so Hadoop is also important. By providing Hadoop as a managed service on Windows Azure, along with links to familiar tools such as Excel, Microsoft aims at making this technology accessible to a broader set of users. More broadly, data of all kinds is important. This is why Windows Azure includes a range of options for data management and business analytics. Whatever application you‘re trying to create, it‘s likely that you‘ll find something in this cloud platform that will work for you.

Lecture 6: Windows Azure SQL Database 9 out of 13 rated this helpful - Rate this topic Microsoft Windows Azure SQL Database is a cloud-based relational database service that is built on SQL Server technologies and runs in Microsoft data centers on hardware that is owned, hosted, and maintained by Microsoft. This topic provides an overview of Windows Azure SQL Database and describes some ways in which it is different from SQL Server.

Similarities and Differences Similar to an instance of SQL Server on your premises, Windows Azure SQL Database exposes a tabular data stream (TDS) interface for Transact-SQL-based database access. This allows your database applications to use Windows Azure SQL Database in the same way that they use SQL Server. Because Windows Azure SQL Database is a service, administration in Windows Azure SQL Database is slightly different. Unlike administration for an on-premise instance of SQL Server, Windows Azure SQL Database abstracts the logical administration from the physical administration; you continue to administer databases, logins, users, and roles, but Microsoft administers the physical hardware such as hard drives, servers, and storage. This approach helps Windows Azure SQL Database provide a large-scale multi-tenant database service that offers enterprise-class availability, scalability, security, and self-healing. Because Microsoft handles all of the physical administration, there are some differences between Windows Azure SQL Database and an on-premise instance of SQL Server in terms of administration, provisioning, Transact-SQL support, programming model, and features. For more information, seeTransact-SQL Support (Windows Azure SQL Database) and Tools and Utilities Support (Windows Azure SQL Database).

Logical Administration and Physical Administration Although Windows Azure SQL Database plays an active role in managing the physical resources of the database, the DBA plays a very important role in administering SQL Database-based database applications. Using Windows Azure SQL Database, DBAs manage schema creation, statistics management, index tuning, query optimization, and security administration (logins, users, roles, and so on). For more information about security administration in Windows Azure SQL Database, see Managing Databases and Logins in Windows Azure SQL Database. Database administration in Windows Azure SQL Database differs most from SQL Server in terms of physical administration. Windows Azure SQL Database automatically replicates all data to provide high availably. Windows Azure SQL Database also manages load balancing and, in case of a server failure, transparent fail-over.

To provide this level of physical administration, you cannot control the physical resources of Windows Azure SQL Database. For example, you cannot specify the physical hard drive or file group where a database or index will reside. Because the computer file system is not accessible and all data is automatically replicated, SQL Server backup and restore commands are not applicable to Windows Azure SQL Database.

Note

SQL Database allows you to back up your database by copying it to a new database in SQL Database. For more information, see Copying Databases in Windows Azure SQL Database. Although backup and restore commands are not available, you can also use SQL Server Integration Services and the SQLCMD utility to bulk copy data. For more information about using SQLCMD with Windows Azure SQL Database, see How to: Connect to Windows Azure SQL Database Using sqlcmd.

Provisioning When preparing an on-premises SQL Server deployment, it may be the role of the DBA or IT department to prepare and configure the required hardware and software. When using Windows Azure SQL Database, these tasks are performed by the SQL Database provisioning process. You can begin provisioning your SQL Databases after you create a Windows Azure platform account. This account allows you to access all the services, such as Windows Azure, Windows Azure AppFabric, and Windows Azure SQL Database, and is used to set up and manage your subscriptions. Each SQL Database subscription may be bound to one or more SQL Database servers at the Microsoft data center. Your SQL Database server is an abstraction that defines a grouping of databases. To enable load balancing and high availability, databases associated with your SQL Database server may reside on separate physical computers at the Microsoft data center. For more information about provisioning, see Windows Azure SQL Database Provisioning Model.

Transact-SQL Support Many SQL Server Transact-SQL statements have parameters that allow you to specify file groups or physical file paths. These types of parameters are not supported in Windows Azure SQL Database because they have dependencies on the physical configuration. In such cases, the command is considered partially supported. For more information about Transact-SQL support, see Transact-SQL Support (Windows Azure SQL Database).

Features and Types Windows Azure SQL Database does not support all of the features and data types found in SQL Server. Analysis Services, Replication, and Service Broker are not currently provided as services on the Windows Azure platform.

Because Windows Azure SQL Database performs the physical administration, any statements and options that attempt to directly manipulate physical resources will be blocked, such as Resource Governor, file group references, and some physical server DDL statements. It is also not possible to set server options and SQL trace flags or use the SQL Server Profiler or the Database Tuning Advisor utilities. Windows Azure SQL Database supports many SQL Server 2008 data types; it does not support data types that have been deprecated from SQL Server 2008. For more information about data type support in Windows Azure SQL Database, see Data Types (Windows Azure SQL Database). For more information about SQL Server 2008 deprecated types, see Deprecated Database Engine Features in SQL Server 2008.

Compare SQL Server with Windows Azure SQL Database (en-US) Windows Azure SQL Database is a cloud-based relational database service from Microsoft. SQL Database provides relational database functionality as a utility service. Cloud-based database solutions such as SQL Database can provide many benefits, including rapid provisioning, cost-effective scalability, high availability, and reduced management overhead. This paper provides an architectural overview of SQL Database, and describes how you can use SQL Database to augment your existing on-premises data infrastructure or as your complete database solution. Last Reviewed: 8/26/2011

Table of Contents       o o o o o  

Similarities and Differences Logical Administration vs. Physical Administration Provisioning Transact-SQL Support Features and Types Key Benefits of the Service Self-Managing High Availability Scalability Familiar Development Model Relational Data Model See Also Other Languages

Similarities and Differences Similar to an instance of SQL Server on your premises, SQL Database exposes a tabular data stream (TDS) interface for Transact-SQL-based database access. This allows your database applications to use SQL Database in the same way that they use SQL Server. Since SQL Database is a service, administration in SQL Database is slightly different. Unlike administration for an on-premise instance of SQL Server, SQL Database abstracts the logical administration from the physical administration; you continue to administer databases, logins, users, and roles, but Microsoft administers and configures the physical hardware such as hard drives, servers, and storage. This approach helps SQL Database provide a large-scale multi-tenant database service that offers enterprise-class availability, scalability, security, and self-healing. Since Microsoft handles all of the physical administration, there are some differences between SQL Database and an on-premise instance of SQL Server in terms of administration, provisioning, Transact-SQL support, programming model, and features. For more information, see Guidelines and Limitations (Windows Azure SQL Database) .

Logical Administration vs. Physical Administration

Although SQL Database plays an active role in managing the physical resources of the database, the DBA plays a very important role in administering SQL Database-based database applications. Using SQL Database, DBAs manage schema creation, statistics management, index tuning, query optimization, and security administration (logins, users, roles, etc.). For more information about security administration in SQL Database, see Managing Databases and Logins in Windows Azure SQL Database . Database administration in SQL Database differs most from SQL Server in terms of physical administration. SQL Database automatically replicates all data to provide high availability. SQL Database also manages load balancing and, in case of a server failure, transparent fail-over to a healthy machine hosting one of the backup copies of your database. To provide this level of physical administration, you cannot control the physical resources of SQL Database. For example, you cannot specify the physical hard drive or file group where a database or index will reside. Because the computer file system is not accessible and all data is automatically replicated, SQL Server backup and restore commands are not applicable to SQL Database. The SQL Database service still backs up all databases; however they are not accessible to regular users. This is a feature that may be offered in future. Starting with SQL Database Service Update 4, SQL Database allows you to back up your database by copying it to a new database in SQL Database. For more information, see Copying Databases in Windows Azure SQL Database . For more information on the available options to transfer data to SQL Database, see Migrating Databases to Windows Azure SQL Database .

Provisioning When preparing an on-premises SQL Server deployment, it may be the role of the DBA or IT department to prepare and configure the required hardware and software. When using SQL Database, these tasks are performed by the SQL Database provisioning process. You can begin provisioning your SQL Databases after you create a Windows Azure Platform account. This account allows you to access all the services, such as Windows Azure, AppFabric, and SQL Database, and is used to set up and manage your subscriptions. Each SQL Database subscription is bound to one SQL Database server within one of the Microsoft data centers. Your SQL Database server is an abstraction that defines a grouping of databases. To enable load-balancing and high availability, databases associated with your SQL Database server may reside on separate physical computers within the Microsoft data center. For more information about provisioning, see Windows Azure SQL Database Provisioning Model

.

Transact-SQL Support Transact-SQL is a language that contains commands used to administer instances of SQL Server including creating and managing all objects in an instance of SQL Server, and inserting, retrieving, modifying, and deleting all data in tables. Applications can communicate with an instance of SQL Server by sending Transact-SQL statements to the server. Windows Azure SQL Database supports a subset of Transact-SQL for SQL Server. For more information about Transact-SQL support, see Transact-SQL Support (Windows Azure SQL Database) .

Features and Types SQL Database does not support all of the features and data types found in SQL Server. Analysis Services, Replication, and Service Broker are not currently provided as services on the SQL Database. You can connect from on-premises Analysis Server to SQL Database and SQL Database can be used either as a data source or destination. When this article is being updated, the Customer Technology Preview of Windows Azure SQL Reporting is also available. SQL Reporting is a cloud-based reporting service built on SQL Database, SQL Server, and SQL Server Reporting Services technologies. You can publish, view, and manage reports that display data from SQL Database data sources. Because SQL Database performs the physical administration, any statements and options that attempt to directly manipulate physical resources will be blocked, such as Resource Governor, file group references, and some physical server DDL statements. It is also not possible to set server options and SQL trace flags or use the SQL Server Profiler or the Database Tuning Advisor utilities.

Key Benefits of the Service The benefits of using SQL Database include manageability, high availability, scalability, a familiar development model, and a relational data model.

Self-Managing SQL Database offers the scale and functionality of an enterprise data center without the administrative overhead that is associated with on-premise instances of SQL Server. This self-managing capability enables organizations to provision data services for applications throughout the enterprise without adding to the support burden of the central IT department or distracting technology-savvy employees from their core tasks in order to maintain a departmental database application. With SQL Database, you can provision your data storage in minutes. This reduces the initial costs of data services by enabling you to provision only what you need. When your needs change, you can easily extend your cloud-based data storage to meet those needs.

High Availability SQL Database is built on proven Windows Server and SQL Server technologies, and is flexible enough to cope with any variations in usage and load. The service replicates multiple redundant copies of your data to multiple physical servers to maintain data availability and business continuity. In the case of a hardware failure, SQL Database provides automatic failover to ensure availability for your application.

Scalability A key advantage of SQL Database is the ease with which you can scale your solution. As data grows, databases need to either scale up or scale out. Scale up always has a ceiling whereas scale out has no virtual limits. A common scale out technique is data-partitioning. After partitioning your data, the service scales as your data grows. A pay-as-yougrow pricing model makes sure that you only pay for the storage that you use, so that you can also scale down the service when you do not need it.

Familiar Development Model

When developers create on-premise applications that use SQL Server, they use client libraries like ADO.NET, ODBC that use the tabular data stream (TDS) protocol to communicate between client and server. SQL Database provides the same TDS interface as SQL Server so that you can use the same tools and libraries to build client applications for data that is stored in SQL Database. For more about TDS, see Network Protocols and TDS Endpoints .

Relational Data Model SQL Database will seem very familiar to developers and administrators because data is stored in SQL Database just like it is stored in SQL Server, by using Transact-SQL. Conceptually similar to an on-premise instance of SQL Server, a SQL Database server is logical group of databases that acts as an authorization boundary. Within each SQL Database server, you can create multiple databases that have tables, views, stored procedures, indices, and other familiar database objects. This data model makes good use of your existing relational database design and Transact-SQL programming skills, and simplifies the process of migrating existing on-premise database applications to SQL Database. For more about Transact-SQL and its relationship to SQL Database, see Transact-SQL Support (Windows Azure SQL Database) . SQL Database servers and databases are virtual objects that do not correspond to physical servers and databases. By insulating you from the physical implementation, SQL Database enables you to spend time on your database design and adding additional value to the business. The following table provides a high-level comparison between SQL Database and SQL Server. Feature Data Storage

SQL Server (On-premise) No size limits as such

SQL Database * The Web Edition Database is best suited for small Web applications and workgroup or departmental applications. This edition supports a database with a maximum size of 1 or 5 GB of data.

Mitigation · An archival process can be created where older data can be migrated to another database in SQL Database or on premise.

· Because of above size constraints, one of the recommendations is to partition the data across * The Business Edition Database is best suited for databases. Creating multiple databases will independent software vendors (ISVs), line-ofallow you take maximum advantage of the business (LOB) applications, and enterprise computing power of multiple nodes. The applications. This edition supports a database of biggest value in the Azure model is the up to 150 GB of data, in increments of 10 GB. elasticity of being able to create as many databases as you need, when your demand peaks and delete/drop the databases as your Exact size and pricing information can be demand subsides. The biggest challenge is obtained atPricing Overview . writing the application to scale across multiple databases. Once this is achieved, the logic can be extended to scale across N number of databases. Edition

· Express

* Web Edition

· Workgroup

* Business Edition

· Standard

For more information, seeAccounts and Billing in Windows Azure SQL Database .

· Enterprise Connectivity

· SQL Server Management

* The SQL Server Management Studio from SQL Server 2008 R2 and SQL Server 2008 R2 Express can be used to access, configure, manage and

Studio · SQLCMD

administer SQL Database. Previous versions of SQL Server Management Studio are not supported. *The Management portal for Windows Azure SQL Database * SQLCMD For more information, see Tools and Utilities Support .

Data Migration

For more information, seeMigrating Databases to Windows Azure SQL Database .

Authentication * SQL SQL Server Authentication only Authentication

Use SQL Server authentication

* Windows Authentication Schema

No such limitation

TSQL Supportability

SQL Database does not support heaps. ALL tables Check all scripts to make sure all table creation must have a clustered index before data can be scripts include a clustered index. If a table is inserted. created without a clustered constraint, a clustered index must be created before an insert operation is allowed on the table. Certain Transact-SQL commands are fully supported; some are partially supported while others are unsupported. * Supported TransactSQL:http://msdn.microsoft.com/enus/library/ee336270.aspx * Partially Supported TransactSQL:http://msdn.microsoft.com/enus/library/ee336267.aspx * Unsupported TransactSQL:http://msdn.microsoft.com/enus/library/ee336253.aspx

―USE‖ command Supported

In SQL Database, the USE statement does not In SQL Database, each of the databases created switch between databases. To change databases, by the user may not be on the same physical you must directly connect to the database. server. So the application has to retrieve data separately from multiple databases and consolidate at the application level.

Transactional Replication

Supported

Not supported

Log Shipping

Supported

Not supported

Database Mirroring

Supported

Not supported

SQL Agent

Supported

Cannot run SQL agent or jobs on SQL Database

You can use BCP or SSIS to get the data out ondemand into an on premise SQL Server. When this article is being updated, the Customer Technology Preview of SQL Data Sync is also available. You can use it to keep on-premise SQL Server and SQL Database in sync, as well as two or more SQL Database servers. For more information on available migration options, seeMigrating Databases to Windows Azure SQL Database .

You can run SQL Server Agent on your on-

premise SQL Server and connect to SQL Database. Server options

Supported

Some system views are supported For more information, seeSystem Views (Windows Azure SQL Database) on MSDN.

Connection Limitations

N/A

In order to provide a good experience to all SQL Database customers, your connection to the service may be closed. For more information, see General Guidelines and Limitations on MSDN and SQL Database Connection Management.

SQL Server Integration Services (SSIS)

Can run SSIS on-premise

SSIS service not available on Azure platform

The idea is most system level metadata is disabled as it does not make sense in a cloud model to expose server level information

Run SSIS on site and connect to SQL Database with ADO.NET provider

Federations in Windows Azure SQL Database (formerly SQL Azure) Federations in SQL Database are a way to achieve greater scalability and performance from the database tier of your application through horizontal partitioning. One or more tables within a database are split by row and portioned across multiple databases (Federation members). This type of horizontal partitioning is often referred to as ‗sharding‘. The primary scenarios in which this is useful are where you need to achieve scale, performance, or to manage capacity. SQL Database can deliver scale, performance, and additional capacity through federation, and can do so dynamically with no downtime; client applications can continue accessing data during repartitioning operations with no interruption in service.

Federation Architecture A federation is a collection of database partitions that are defined by a federation distribution scheme, known as the federation scheme. The federation scheme defines a federation distribution key, which determines the distribution of data to partitions within the federation. The federation distribution key must be an INT, BIGINT, UNIQUEIDENTIFIER, or VARBINARY (up to 900 bytes) and specifies a range value. There can only be one federation scheme and one federation distribution key for a federation. The database partitions within a federation are known as federation members, and each member covers a part, or all, of the range of values covered by the data type of the federation distribution key. Federated tables are tables which are spread across federation members. Each federation member has its own schema, and contains the federated table rows that correspond to the federation member‘s range. The collection of all rows in a federation member that match a specific federation key value is called afederation atomic unit. Each federation member contains many federation atomic units. A federation member may also contain reference tables, which are tables that are not federation aware. Reference tables are fully contained within a member, and often contain reference information that is retrieved in combination with federated data. A federation member provides physical separation between the data it contains and data stored in other members. Each federation member has its own schema, which may temporarily diverge from the schema of other members due to member specific processing such as performing a rolling schema upgrade across all members. While federation members are physically implemented as databases, they are logically referenced at the application layer as a range of federation key values. For example, a federation member database that contains rows associated with federation key values 50-100 would be logically accessed by specifying a key value within that range rather than specifying the database name. Federations are accessed through a federation root database, which represents the application boundary of the federation. It functions as the logical endpoint for applications to connect to a federation by routing connections to the appropriate federation member based on the specified federation key value.

Each root database may contain multiple federations, each with its own federation schema. It may also contain global data, such as users, passwords, roles, or other application specific data. The following diagrams illustrate the logical and physical model for federations:

Design Considerations When designing a federation, one of the most important design decisions is what value to federate on. Ideally you want to select a key that allows you to federate data from multiple, related tables so related rows are stored together. For example, in the case of a multi-tenant application you might select the tenant_id. The rows within each federated table that specify the same tenant_id value would be stored in the same federation atomic unit. You must also consider how to insert new records in such a way that all federation members are equally utilized, instead of storing all new records in one member. Determining how to distribute new data among federation members must be handled at the application layer. Since there is a physical separation of data contained in different federation members and SQL Database doesn‘t support join operations across databases, your application must implement the logic for joining data from multiple federation members or multiple federations. For example, a query that needs to join data from a two federations would need to perform separate queries against each and join the data within the application. The same holds true for aggregating data across multiple shards within a single federation, such as obtaining a count of all rows contained within the federation.

Identity: Windows Azure Active Directory Windows Azure Active Directory (Windows Azure AD) is a modern, REST-based service that provides identity management and access control capabilities for your cloud applications. Now you have one identity service across Windows Azure, Microsoft Office 365, Dynamics CRM Online, Windows Intune and other 3rd party cloud services. Windows Azure Active Directory provides a cloud-based identity provider that easily integrates with your on-premises AD deployments and full support of third party identity providers. Use Windows Azure AD to: Integrate with your on-premises active directory Quickly extend your existing on-premises Windows Azure AD to apply policy and control and authenticate users with their existing corporate credentials to Windows Azure and other cloud services. Offer access control for you applications Easily manage access to your applications based on centralized policy and rules. Ensure consistent and appropriate access to your organizations applications is maintained to meet critical internal security and compliance needs. Windows Azure AD Access Control provides developers centralized authentication and authorization for applications in Windows Azure using either consumer identity providers or your on-premises Windows Server Active Directory Build social connections across the enterprise Windows Azure AD Graph is an innovative social enterprise graph providing an easy RESTful interface for accessing objects such as Users, Groups, and Roles with an explorer view for easily discovering information and relationships. Provide single sign-on across your cloud applications Provide your users with a seamless, single sign-on experience across Microsoft Online Services, third party cloud services and applications built on Windows Azure with popular web identity providers like Windows Live ID, Google, Yahoo!, and Facebook.

Windows Azure AppFabric Access Control Access Control is part of the AppFabric set of middleware services in Windows Azure. It provides a central point for handling federated security and access control to your services and applications, running in the cloud or on premise. AppFabric Access Control has built in support for federating against AD FS 2.0 – or any custom identity provider that supports the WSFederation protocol. In addition to supporting web based and SOAP based federation scenarios, Access Control also support federation using the OAuth protocol and REST based services. It has a web based management portal as well as OData based management services for configuring and managing the service. The Access Control service has a rule engine that can be used to transform the incoming claims, thus being able to translate from a certain set of claims to another set of claims. It can also translate token formats to/from SAML 1.0, SAML 2.0 and Simple Web Token (SWT) formats. Using the Access Control service you set up trust between the service and every STS that you want to federate with, including your own AD FS 2.0 STS:

Federated Identity through Windows Azure AppFabric Access Control In this case your application running in Windows Azure still only has one point to point trust - to

the Access Control service – and all the dependencies to the business partners are managed by this service. Below is a sequence diagram showing the generic flow for single sign on using the Access Control service. The terms used in the diagram maps to our example as: Client – the client in our domain or our business partner‘s domain. Identity Provider – our Active Directory + AD FS2 or our business partner‘s STS. Relying party – our application running in Windows Azure

The above diagram shows the flow when the application is a web application and the client is a web browser client (also known as a ‗passive client‘). If the application would expose web services that a locally installed smart client (an ‗active client‘) would consume, for example WCF services consumed by a WPF client – the first step in the sequence would be to directly login to the identity provider – instead of being redirected to a login page. Federation with public Identity Providers

Windows Azure Access Control also let you use some of the largest public Internet services as Identity Providers. Out of the box there is built in support for using Windows Live ID, Facebook, Yahoo and Google as identity providers. The Access Control service handles all protocol transitions between the different providers, including Open ID 2.0 for Google and Yahoo, Facebook Graph for Facebook, and WS-Federation for Windows Live ID. The service then delivers a single SAML 1.1, SAML 2.0, or SWT token to your web application using the WSFederation protocol once a user is signed in. This is of course a really interesting feature when you are building public facing consumer oriented services, but could also be really useful in business to business scenarios. If for example you are building a SAAS solution, using the public identity providers like Facebook and Windows Live ID could be the option for smaller businesses while your enterprise customers could use their own STS for federation.

Lecture 8: WINDOWS AZURE SERVICE BUS The Service Bus securely relays messages to and from any Web service regardless of the device or computer on which they are hosted, or whether that device is behind a firewall or NAT router. It provides direct one-way or request/response (relayed) messaging as well as brokered, or asynchronous, messaging patterns. The Service Bus and Access Control together make hybrid, connected applications—applications that communicate from behind firewalls, across the Internet, from hosted cloud servers, between rich desktops and smart devices—easier to build, secure, and manage. Although you can build hybrid, connected applications today, doing this often means you have to build important infrastructure components before you can build the applications themselves. The Service Bus and Access Control provide several important infrastructure elements so that you can more easily begin making your connected applications work now.

Software, Services, Clouds, and Devices Today‘s business infrastructure is more feature-rich, connected, and interoperable than ever. People access applications and data through stunning graphical programs running on traditional operating systems; powerful Web applications that are running in browsers; and very small, intelligent computers such as cell phones, netbooks, and other smart devices. Applications run locally, often on powerful servers and server farms, and critical data is stored in performant databases, on desktops, and in the cloud. The Internet connects people, applications, devices, and data across the world. Clouds of computing power—such as Windows Azure—can help us reduce costs and increase scalability and manageability. Web services can expose functionality to any caller safely and securely. With these technologies, platforms, and devices, you can build significantly distributed, interactive applications that can reach almost anyone, use almost any useful data, and do both securely and robustly regardless of where the user is at the moment. Such hybrid, connected programs – including those often referred to as ―Software plus Services‖ -- could use proprietary or private data behind a firewall and return only the appropriate results to a calling device, or notify that device when a particular event occurs.

Fulfilling the Potential However, building these distributed applications currently is very, very hard—and it should not be. There are many reasons why, without a platform that solves these problems for you, it remains difficult to take advantage of these wonderful technologies that could make a business more efficient, more productive, and your customers happier. 

Operating systems are still located—trapped is often a better word—on a local computer, typically behind a firewall and perhaps network address translation (NAT) of some sort. This problem is true of smart devices and phones, too.



As ubiquitous as Web browsers are, their reach into data is limited to an interactive exchange in a format they understand.



Heterogeneous platforms, such as server applications, desktop or portable computers, smart devices, and advanced cell phones, often interoperate at a rudimentary level, if at all. They can rarely share the same code base or benefit from feature or component reuse.



Much of the most valuable data is stored in servers and embedded in applications that will not be replaced immediately—sometimes referred to as ―legacy‖ systems. The data in these systems are trapped by technical limitations, security concerns, or privacy restrictions.



The Internet is not always the network being used. Private networks are an important part of the application environment, and their insulation from the Internet is a simple fact of information technology (IT) life. Service Bus and Access Control are built to overcome these kinds of obstacles; they provide the ―fabric‖ that you can use to build, deploy, and manage the distributed applications that can help make the promise of ―Software + Services‖ become real. The Service Bus and Access Control services together are highly-scalable services that are running in Microsoft data centers that can be used by applications anywhere to securely bridge the gap between local applications behind a firewall, applications that are running in the cloud, and client applications of any kind around the world. Another way of saying this is that the Service Bus and Access Control are the glue that makes ―Software‖ and ―Services‖ work together.

Feature Overview The Service Bus connects local, firewalled applications and data with applications in the cloud, rich desktop applications, and smart, Web-enabled devices anywhere in the world. Access Control Service is a claims-based access control service that can be used on most Web-enabled devices to build interoperable, federated authentication and authorization into any connected application. The following diagram illustrates this architecture.

Service Bus Features 

Securely exposes to external callers Windows Communication Foundation (WCF)-based Web services that are running behind firewalls and NAT routers -- without requiring you to open any inbound ports or otherwise change firewall and router configurations.



Enables secure inbound communication from devices outside the firewall.



Provides a global namespace system that is location-independent: the name of a service in the Service Bus provides no information about the final destination of the communication.



Provides a service registry for publishing and discovering service endpoint references in a service namespace.



Provides relayed messaging capabilities: the relay service supports direct one-way messaging, request/response messaging, and peer-to-peer messaging.



Provides brokered (or asynchronous) messaging capabilities: Senders and receivers do not have to be online at the same time. The messaging infrastructure reliably stores messages until the receiving party is ready to receive them. The core components of the brokered messaging infrastructure are Queues, Topics, and Subscriptions.



Builds and hosts service endpoints that support:

o

Exposing a Web service to remote users. Expose and secure a local Web service in the cloud without managing any firewall or NAT settings.

o

Eventing behavior. Listen for notifications on any device, anywhere in the world.

o

Tunneling between any two endpoints to enable bidirectional streams. The following diagram illustrates the capabilities of the Service Bus.

Relayed and Brokered Messaging 2 out of 2 rated this helpful - Rate this topic The messaging pattern associated with the initial releases of the Windows Azure Service Bus is referred to as relayed messaging. The latest version of the Service Bus adds another type of messaging option known as brokered messaging. The brokered messaging scheme can also be thought of as asynchronous messaging.

Relayed Messaging The central component of the Service Bus is a centralized (but highly load-balanced) relay service that supports a variety of different transport protocols and Web services standards. This includes SOAP, WS-*, and even REST. The relay service provides a variety of different relay connectivity options and can even help negotiate direct peer-to-peer connections when it is possible. The Service Bus is optimized for .NET developers who use the Windows Communication Foundation (WCF), both with regard to performance and usability, and provides full access to its relay service through SOAP and REST interfaces. This makes it possible for any SOAP or REST programming environment to integrate with it. The relay service supports traditional one-way messaging, request/response messaging, and peer-to-peer messaging. It also supports event distribution at Internet-scope to enable publish/subscribe scenarios and bi-directional socket communication for increased point-to-point efficiency. In the relayed messaging pattern, an on-premise service connects to the relay service through an outbound port and creates a bidirectional socket for communication tied to a particular rendezvous address. The client can then communicate with the on-premises service by sending messages to the relay service targeting the rendezvous address. The relay service will then ―relay‖ messages to the on-premises service through the

bi-directional socket already in place. The client does not need a direct connection to the on-premises service nor is it required to know where the service resides, and the on-premises service does not need any inbound ports open on the firewall. You must initiate the connection between your on-premise service and the relay service, using a suite of WCF ―relay‖ bindings. Behind the scenes, the relay bindings map to new transport binding elements designed to create WCF channel components that integrate with the Service Bus in the cloud. Relayed messaging provides many benefits, but requires the server and client to both be online at the same time in order to send and receive messages. This is not optimal for HTTP-style communication, in which the requests may not be typically long lived, nor for clients that connect only occasionally, such as browsers, mobile applications, and so on. Brokered messaging supports decoupled communication, and has its own advantages; clients and servers can connect when needed and perform their operations in an asynchronous manner.

Brokered Messaging In contrast to the relayed messaging scheme, brokered messaging can be thought of as asynchronous, or ―temporally decoupled.‖ Producers (senders) and consumers (receivers) do not have to be online at the same time. The messaging infrastructure reliably stores messages until the consuming party is ready to receive them. This allows the components of the distributed application to be disconnected, either voluntarily; for example, for maintenance, or due to a component crash, without affecting the whole system. Furthermore, the receiving application may only have to come online during certain times of the day, such as an inventory management system that only is required to run at the end of the business day. The core components of theService Bus brokered messaging infrastructure are Queues, Topics, and Subscriptions. These components enable new asynchronous messaging scenarios, such as temporal decoupling, publish/subscribe, and load balancing. For more information about these structures, see the next section. As with the relayed messaging infrastructure, the brokered messaging capability is provided for WCF and .NET Framework programmers and also via REST.

What are Service Bus Queues Service Bus Queues support a brokered messaging communication model. When using queues, components of a distributed application do not communicate directly with each other, they instead exchange messages via a queue, which acts as an intermediary. A message producer (sender) hands off a message to the queue and then continues its processing. Asynchronously, a message consumer (receiver) pulls the message from the queue and processes it. The producer does not have to wait for a reply from the consumer in order to continue to process and send further messages. Queues offer First In, First Out (FIFO) message delivery to one or more competing consumers. That is, messages are typically received and processed by the receivers in the order in which they were added to the queue, and each message is received and processed by only one message consumer.

Service Bus queues are a general-purpose technology that can be used for a wide variety of scenarios:   

Communication between web and worker roles in a multi-tier Windows Azure application Communication between on-premises apps and Windows Azure hosted apps in a hybrid solution Communication between components of a distributed application running on-premises in different organizations or departments of an organization Using queues can enable you to scale out your applications better, and enable more resiliency to your architecture.

What are Service Bus Topics and Subscriptions Service Bus topics and subscriptions support a publish/subscribe messaging communication model. When using topics and subscriptions, components of a distributed application do not communicate directly with each other, they instead exchange messages via a topic, which acts as an intermediary.

In contrast to Service Bus queues, where each message is processed by a single consumer, topics and subscriptions provide a one-to-many form of communication, using a publish/subscribe pattern. It is possible to register multiple subscriptions to a topic. When a message is sent to a topic, it is then made available to each subscription to handle/process independently. A topic subscription resembles a virtual queue that receives copies of the messages that were sent to the topic. You can optionally register filter rules for a topic on a per-subscription basis, which allows you to filter/restrict which messages to a topic are received by which topic subscriptions. Service Bus topics and subscriptions enable you to scale to process a very large number of messages across a very large number of users and applications.

What is the Service Bus Relay The Service Bus Relay service enables you to build hybrid applications that run in both a Windows Azure datacenter and your own on-premises enterprise environment. The Service Bus relay facilitates this by enabling you to securely expose Windows Communication Foundation (WCF) services that reside within a corporate enterprise network to the public cloud, without having to open up a firewall connection or requiring intrusive changes to a corporate network infrastructure.

The Service Bus relay allows you to host WCF services within your existing enterprise environment. You can then delegate listening for incoming sessions and requests to these WCF services to the Service Bus running within Windows Azure. This enables you to expose these services to application code running in Windows Azure, or to mobile workers or extranet partner environments. The Service Bus allows you to securely control who can access these services at a fine-grain level. It provides a powerful and secure way to expose application functionality and data from your existing enterprise solutions and take advantage of it from the cloud.

LECTURE 7: NETWORKING AND CACHING IN WINDOWS AZURE Windows Azure Networking The easiest way to connect to Windows Azure applications and data is through an ordinary Internet connection. But this simple solution isn‘t always the best approach. Windows Azure also provides three more technologies for connecting users to Windows Azure datacenters:   

Virtual Network Connect Traffic Manager This article takes a look at each of these.

Table of Contents   

Windows Azure Virtual Network Windows Azure Connect Windows Azure Traffic Manager

Windows Azure Virtual Network Windows Azure lets you create virtual machines (VMs) that run in Microsoft datacenters. Suppose your organization wants to use those VMs to run enterprise applications or other software that will be used by your firm‘s employees. Maybe you want to create a SharePoint farm in the cloud, for example, or run an inventory management application. To make life as easy as possible for your users, you‘d like these applications to be accessible just as if they were running in your own datacenter. There‘s a standard solution to this kind of problem: create a virtual private network (VPN). Organizations of all sizes do this today to link, say, branch office computers to the main company datacenter. This same approach can work with Windows Azure VMs, as Figure 1 shows.

Figure 1: Windows Azure Virtual Network allows creating a virtual network in the cloud that’s connected to your on-premises datacenter. As the figure shows, Windows Azure Virtual Network lets you create a logical boundary around a group of VMs, called a virtual network or VNET, in a Windows Azure datacenter. It then lets you establish an IPsec connection between this VNET and your local network. The VMs in a VNET can be created using Windows Azure Virtual Machines, Windows Azure Cloud Services, or both. In other words, they can be VMs created using either Windows Azure‘s Infrastructure as a Service (IaaS) technology or its Platform as a Service (PaaS) technology. Whatever choice you make, creating the IPsec connection requires a VPN gateway device, specialized hardware that‘s attached to your local network, and it also requires the services of your network administrator. Once this connection is in place, the Windows Azure VMs running in your VNET look like just another part of your organization‘s network. As Figure 1 suggests, you allocate IP addresses for the Windows Azure VMs from the same IP address space used in your own network. In the scenario shown here, which uses private IP addresses, the VMs in the cloud are just another IP subnet. Software running on your local network will see these VMs as if they were local, just as they do with traditional VPNs. And it‘s important to note that because this connection happens at the IP level, the virtual and physical machines on both sides can be running any operating system. Windows Azure VMs running Windows Server or Linux can interact with on-premises machines running Windows, Linux, or other systems. It‘s also possible

to use mainstream management tools, including System Center and others, to manage the cloud VMs and the applications they contain. Using Windows Azure Virtual Network makes sense in many situations. As already mentioned, this approach lets enterprise users more easily access cloud applications. An important aspect of this ease of use is the ability to make the Windows Azure VMs part of an existing on-premises Active Directory domain to give users single sign-on to the applications they run. You can also create an Active Directory domain in the cloud if you prefer, then connect this domain to your on-premises network. Creating a VNET in a Windows Azure datacenter effectively gives you access to a large pool of ondemand resources. You can create VMs on demand, pay for them while they‘re running, then remove them (and stop paying) when you no longer need them. This can be useful for scenarios that need fast access to a preconfigured machine, such as development teams building new software. Rather than wait for a local administrator to set up the resources they need, they can create these resources themselves in the public cloud. And just as Virtual Network makes Windows Azure VMs appear local to on-premises resources, the reverse is also true: Software running in your local network now appears to be local to applications running in your Windows Azure VNET. Suppose you‘d like to move an existing on-premises application to Windows Azure, for example, because you‘ve determined that it will be less expensive to operate in the cloud. But what if the data that application uses is required by law to be stored on premises? In a situation like this, using Virtual Network lets the cloud application see an on-premises database system as if it were local—accessing it becomes straightforward. Whatever scenario you choose, the result is the same: Windows Azure becomes an extension of your own datacenter.

Windows Azure Connect Sometimes, connecting your entire on-premises network to a group of Windows Azure VMs is the right thing to do. Windows Azure Virtual Network is designed to solve this problem. But what if you don‘t need a solution that‘s this general? Suppose instead that all you‘d like to do is connect a single Windows Azure application—or even a single VM—to a specific group of computers on your local network. Addressing this problem is the goal of Windows Azure Connect, as Figure 2 shows.

Figure 2: Windows Azure Connect links one or more VMs in Windows Azure with a group of on-premises machines running Windows. Unlike Virtual Network, Connect doesn‘t require using a VPN gateway device, nor does it require the services (or approval) of a network administrator. Instead, anybody with administrative access to a Windows machine in the local network can install the required Windows Azure Connect software on that machine. Once this is done, the software can create an IPsec link with designated Windows Azure VMs. As the figure shows, Connect doesn‘t link two networks together; the Windows Azure VMs retain whatever IP addresses they already have. Instead, it creates direct IPsec connections between specific on-premises Windows computers and specific Windows Azure VMs. (To work with existing firewall settings, Connect actually sends IPsec on top of an SSL connection.) For Cloud Services applications, you can choose one or more roles to connect to, and Windows Azure will make it possible to communicate with each instance in those roles. For VMs created using Windows Azure Virtual Machines, you can install the same Windows Azure Connect software used for on-premises computers. Windows Azure Connect is useful in a variety of situations. An application running on Windows Azure might use Connect to link to an on-premises database system, for example, or a developer on the local network might use Connect to domain-join a cloud VM to an on-premises environment. While

Connect isn‘t as general a solution as Virtual Network, it is significantly easier to set up. Developers can do it without bothering their network admins and with no extra hardware. Which approach is right for you depends on exactly what problems you need to solve.

Windows Azure Traffic Manager Imagine that you‘ve built a successful Windows Azure application. Your app is used by many people in many countries around the world. This is a great thing, but as is so often the case, success brings new problems. Here, for instance, your application most likely runs in multiple Windows Azure datacenters in different parts of the world. How can you intelligently route traffic across these datacenters so that your users always get the best experience? Windows Azure Traffic Manager is designed to solve this problem. Figure 3 shows how.

Figure 3: Windows Azure Traffic Manager intelligently directs requests from users across instances of an application running in different Windows Azure datacenters. In this example, your application is running in VMs spread across four datacenters: two in the US, one in Europe, and one in Asia. Suppose a user in Berlin wishes to access the application. If you‘re using Traffic Manager, here‘s what happens. As usual, the user‘s system looks up the DNS name of the application (step 1). This query is redirected to the Windows Azure DNS system (step 2), which then looks up the Traffic Manager policy for this application. Each policy is created by the owner of a particular Windows Azure

application, either through a graphical interface or a REST API. However it‘s created, the policy specifies one of three options:  



Performance: All requests are sent to the closest datacenter. Failover: All requests are sent to the datacenter specified by the creator of this policy, unless that datacenter is unavailable. In this case, requests are routed to other datacenters in the priority order defined by the policy‘s creator. Round Robin: All requests are spread equally across all datacenters in which the application is running. Once it has the right policy, Traffic Manager figures out which datacenter this request should go to based on which of the three options is specified (step 3). It then returns the location of the chosen datacenter to the user (step 4), who accesses that instance of the application (step 5). For this to work, Traffic Manager must have a current picture of which instances of the application are up and running in each datacenter. To make this possible, Traffic Manager periodically pings each copy of the application via an HTTP GET, then records whether it receives a response. If an application instance stops responding, Traffic Manager will stop sending traffic to that instance until it resumes responding to pings. Not every application is big enough or global enough to need Traffic Manager. For those that do, however, this can be a quite useful service.

Caching in Windows Azure 3 out of 5 rated this helpful - Rate this topic Windows Azure Caching enables you to provision a cache in the cloud, to be used from any applications or services that could benefit from Caching. ASP.NET applications can use Caching for the common scenario of session state and output caching. Caching increases performance by temporarily storing information from other backend sources. High performance is achieved by maintaining this cache inmemory across multiple cache servers. For a Windows Azure solution, Caching can reduce the costs and increase the scalability of other storage services such as SQL Database or Azure storage. There are two main ways to use Caching: 

Caching (Preview) where Caching is deployed on web/worker roles of your application



Shared Caching where Caching is consumed as a managed service

Caching (Preview) on Roles Windows Azure Caching (Preview) allows you to host Caching within your Azure roles. This capability is also referred to as role-based Caching. There are two main deployment topologies for this type of Caching: dedicated and co-located. In the dedicated topology, you define a worker role that is dedicated to Caching. This means that all of the worker role's available memory is used for the Caching and operating overhead. In a co-located topology, you use a percentage of available memory on application roles for Caching. For example, you could assign 20% of the physical memory for Caching on each web role instance. In both cases, you only pay for the Compute services required for the running role instances. For more information, see Windows Azure Caching (Preview) FAQ.

Note

Caching (Preview) role-based Caching is not supported in production at this time.

Shared Caching Windows Azure Shared Caching enables you to register a cache through the Windows Azure Management Portal. Theses caches do not reside on your own roles. Instead, they reside on a group of servers in a multitenant environment. You can access your cache with a Service URL and Authentication token from the Management Portal. In this model, you pay for one of several cache offerings that vary in memory, bandwidth, transactions, and client connections. For more information, see Windows Azure Shared Caching FAQ.

Note

Windows Azure Caching features are a subset of the features of the on-premise caching solution of Windows Server AppFabric. For more information, see Differences Between Caching On-Premises and in the Cloud.

Important

Windows Azure Caching is designed for Windows Azure applications hosted in the cloud. This architecture achieves the best throughput at the lowest latency. With Shared Caching, it is possible to test on-premises code that accesses a Windows Azure cache, but this design is not supported for production. On-premises applications can instead rely on an on-premises cache cluster that uses Windows Server AppFabric.

LECTURE 8: OTHER TOPICS MEDIA SERVICES What are Media Services? Windows Azure Media Services form an extensible media platform that integrates the best of the Microsoft Media Platform and third-party media components in Windows Azure. Media Services provide a media pipeline in the cloud that enables industry partners to extend or replace component technologies. ISVs and media providers can use Media Services to build end-to-end media solutions. This overview describes the general architecture and common development scenarios for Media Services. The following diagram illustrates the basic Media Services architecture.

Media Services Feature Support The current release of Media Services provides the following feature set for developing media applications in the cloud. For information on future releases, see Media Services Upcoming Releases: Planned Feature Support.

 

Ingest. Ingest operations bring assets into the system, for example by uploading them and encrypting them before they are placed into Windows Azure Storage. By the RTM release, Media Services will offer integration with partner components to provide fast UDP (User Datagram Protocol) upload solutions. Encode. Encode operations include encoding, transforming and converting media assets. You can run encoding tasks in the cloud using the Media Encoder that is included in Media Services. Encoding options include the following:

o o o o





Use the Windows Azure Media Encoder and work with a range of standard codecs and formats, including industry-leading IIS Smooth Streaming, MP4, and conversion to Apple HTTP Live Streaming. Convert entire libraries or individual files with total control over input and output. A large set of supported file types, formats, and codecs (see Supported File Types for Media Services). Supported format conversions. Media Services enable you to convert ISO MP4 (.mp4) to Smooth Streaming File Format (PIFF 1.3) (.ismv; .isma). You can also convert Smooth Streaming File Format (PIFF) to Apple HTTP Live Streaming (.msu8, .ts).

Protect. Protecting content means encrypting live streaming or on demand content for secure transport, storage, and delivery. Media Services provide a DRM technology-agnostic solution for protecting content. Currently supported DRM technologies are Microsoft PlayReady Protection and MPEG Common Encryption. Support for additional DRM technologies will be available. Stream. Streaming content involves sending it live or on demand to clients, or you can retrieve or download specific media files from the cloud. Media Services provide a format-agnostic solution for streaming content. Media Services provide streaming origin support for Smooth Streaming, Apple HTTP Live Streaming, and MP4 formats. Support for additional formats will be available. You can also seamlessly deliver streaming content by using Windows Azure CDN or a third-party CDN, which enables the option to scale to millions of users. Media Services Development Scenarios Media Services support several common media development scenarios as described in the following table. Scenario

Description

Building end-toend workflows

Build comprehensive media workflows entirely in the cloud. From uploading media to distributing content, Media Services provide a range of components that can be combined to handle specific application workflows. Current capabilities include upload, storage, encoding, format conversion, content protection, and on-demand streaming delivery.

Building hybrid workflows

You can integrate Media Services with existing tools and processes. For example, encode content on-site then upload to Media Services for transcoding into multiple formats and deliver through Windows Azure CDN, or a third-party CDN. Media Services can be called individually via standard REST APIs for integration with external applications and services.

Providing cloud support for media players

You can create, manage, and deliver media across multiple devices (including iOS, Android, and Windows devices) and platforms.

Media Services Client Development Extend the reach of your Media Services solution by using SDKs and player frameworks to build media client applications. These clients are for developers who want to build Media Services applications that offer compelling user experiences across a range of devices and platforms. Depending on the devices that you want to build client applications for, there are options for SDKs and player frameworks available from Microsoft and other third-party partners.

Setting up a Windows Azure account for Media Services To set up your Media Services account, use the Windows Azure Management Portal (recommended). See the topic How to Create a Media Services Account. After creating your account in the Management Portal, you are ready to set up your computer for Media Services development.

CONTENT DELIVERY NETWORK (CDN) The Windows Azure Content Delivery Network (CDN) caches Windows Azure blobs and the static content output of compute instances at strategically placed locations to provide maximum bandwidth for delivering content to users. You can enable CDN delivery for your content providers using the Windows Azure Platform Management Portal. CDN is an add-on feature to your subscription and has a separate billing plan. The CDN offers developers a global solution for delivering high-bandwidth content by caching the content at physical nodes in the United States, Europe, Asia, Australia and South America. For a current list of CDN node locations, see Windows Azure CDN Node Locations. The benefits of using CDN to cache Windows Azure data include:



Better performance and user experience for end users who are far from a content source, and are using applications where many ‗internet trips‘ are required to load content



Large distributed scale to better handle instantaneous high load, say, at the start of an event such as a product launch To use the Windows Azure CDN you must have a Windows Azure subscription and enable the feature on the storage account or hosted service in the Windows Azure Management Portal. Note Enabling the CDN may take up to 60 minutes to propagate worldwide.

When a request for an object is first made to the CDN, the object is read retrieved directly from the Blob service or from the hosted service. When a request is made using the CDN syntax, the request is redirected to the CDN endpoint closest to the location from which the request was made to provide access to the object. If the object is not found at that endpoint, then it is retrieved from the service and cached at the endpoint, where a time-to-live setting is maintained for the cached object.

Caching content from Windows Azure blobs

Once the CDN is enabled on a Windows Azure storage account, any blobs that are in public containers and are available for anonymous access will be cached via the CDN. Only blobs that are publically available can be cached with the Windows Azure CDN. To make a blob publically available for anonymous access, you must denote its container as public. Once you do so, all blobs within that container will be available for anonymous read access. You have the option of making container data public as well, or restricting access only to the blobs within it. See Setting Access Control for Containers for information on managing access control for containers and blobs. For best performance, use CDN edge caching for delivering blobs less than 10 GB in size. When you enable CDN access for a storage account, the Management Portal provides you with a CDN domain name in the following format: http://.vo.msecnd.net/. This domain name can be used to access blobs in a public container. For example, given a public container namedmusic in a storage account named myaccount, users can access the blobs in that container using either of the following two URLs:  

Windows Azure Blob service URL:http://myaccount.blob.core.windows.net/music/ Windows Azure CDN URL:http:// .vo.msecnd.net/music/

Caching content from hosted services

You can cache objects to the CDN that are provided by a Windows Azure hosted service. CDN for hosted services has the following constraints:



Should be used to cache static content.

Warning Caching of highly volatile or truly dynamic content may adversely affect your performance or cause content problems, all at increased cost.



The hosted service must be deployed to in a production deployment.



The hosted service must provide the object on port 80 using HTTP.



The hosted service must place the content to be cached in, or delivered from, the /cdn folder on the hosted service.

When you enable CDN access for on a hosted service, the Management Portal provides you with a CDN domain name in the following format: http://.vo.msecnd.net/. This domain name can be used to retrieve objects from a hosted service . For example, given a hosted service named myHostedService and an ASP.NET web page called music.aspx that delivers content, users can access the object using either of the following two URLs:  

Windows Azure hosted service URL:http://myHostedService.cloudapp.net/cdn/music.aspx Windows Azure CDN URL:http://.vo.msecnd.net/music.aspx

Accessing cached content over HTTPS Windows Azure allows you to retrieve content from the CDN using HTTPS calls. This allows you to incorporate content cached in the CDN into secure web pages without receiving warnings about mixed security content types. Accessing CDN content using HTTPS has the following constraints:   

You must use the certificate provided by the CDN. Third party certificates are not supported. You must use the CDN domain to access content. HTTPS support is not available for custom domain names (CNAMEs) since the CDN does not support custom certificates at this time. HTTPS is from the CDN to the client only. Requests from the CDN to the content provider (Storage Account or hosted service) are still made using HTTP.

Even when HTTPS is enabled, content from the CDN can be retrieved using both HTTP and HTTPS. For more information on enabling HTTPS for CDN content, see How to Enable CDN for Windows Azure.

Accessing cached content with custom domains You can map the CDN HTTP endpoint to a custom domain name and use that name to request objects from the CDN. For more information on mapping a custom domain, see How to Map CDN Content to a Custom Domain.

Introduction to Hadoop on Windows Azure Overview Apache™ Hadoop™-based Services for Windows Azure is a service that deploys and provisions clusters in the cloud, providing a software framework designed to manage, analyze and report on big data.

Data is described as "big data" to indicate that is being collection is in ever escalating volumes, at increasingly high velocities, and for a widening variety of unstructured formats and variable semantic contexts. Big data collection does not provide value to an enterprise. For big data to provide value in the form of actionable intelligence or insight, it must be accessible, cleaned, analyzed, and then presented in a useful way, often in combination with data from various other sources. Apache Hadoop is a software framework that facilitates big data management and analysis. Apache Hadoop core provides reliable data storage with the Hadoop Distributed File System (HDFS), and a simple MapReduce programming model to process and analyze in parallel the data stored in this distributed system. HDFS uses data replication to address hardware failure issues that arise when deploying such highly distributed systems. To simplify the complexities of analyzing unstructured data from various sources, the MapReduce programming model provides a core abstraction that provides closure for map and reduce operations. The MapReduce programming model views all of its jobs as computations over key-value pair datasets. So both input and output files must contain such key-value pair datasets. Other Hadoop-related projects such as Pig and Hive are built on top of HDFS and the MapReduce framework, providing higher abstraction levels such as data flow control and querying, as well as additional functionality such as warehousing and mining, required to integrate big data analysis and end-to-end management. Implementing Hadoop on Windows Azure as a service in the cloud makes the HDFS/MapReduce software framework and related projects available in a simpler, more scalable, and cost efficient environment. To simplify configuring and running Hadoop jobs and interacting with the deployed clusters, Microsoft provides JavaScript and Hive consoles. This simplified JavaScript approach enables IT professionals and a wider group of developers to deal with big data management and analysis by providing an accessible path into the Hadoop framework. It addition to the available Hadoop-related ecosystem projects, it also provides Open Database Connectivity (ODBC) drivers to integrate Business Intelligence (BI) tools such as Excel, SQL Server Analysis Services, and Reporting Services, facilitating and simplifying end-to-end data analysis. This topic describes the Hadoop ecosystem on Windows Azure, the main scenarios for Hadoop on Windows Azure cases, and provides a tour around the Hadoop on Windows Azure portal. It contains the following sections: 

Big Data: Volume, Velocity, Variety and Variability. - The qualities of big data that render it best managed by NoSQL systems like Hadoop, rather than by conventional Relational Database Management System (RDBMS).



The Hadoop Ecosystem on Windows Azure - Hadoop on Windows Azure provides Pig, Hive, Mahout, Pegasus, Sqoop, and Flume implementations, and supports other BI tools such as Excel, SQL Server Analysis Services and Reporting Services that are integrated with HDFS and the MapReduce framework.



Big Data Scenarios for Hadoop on Windows Azure - The types of jobs appropriate for using Hadoop on Windows Azure.



Getting Started with Microsoft Hadoop on Windows Azure - Get Community Technical Preview (CTP) access and an introduction to the Apache™ Hadoop™-based Services for Windows Azure Portal.



Tour of the Portal - Deploying clusters, managing your account, running samples, and the interactive JavaScript console.



Resources for Hadoop on Windows Azure - Where to find resources with additional information.

Big data: volume, velocity, variety, and variability You cannot manage or process big data by conventional RDBMS because big data volumes are too large, or because the data arrives at too high a velocity, or because the data structures variety and semantic variability do not fit relational database architectures.

Volume The Hadoop big data solution is a response to two divergent trends. On the one hand, because the capacity of hard drives has continued to increase dramatically over the last 20 years, vast amounts of new data generated by web sites and by new device and instrumentation generations connected to the Internet, can be stored. In addition, there is automated tracking of everyone's online behavior. On the other hand, data access speeds on these larger capacity drives have not kept pace, so reading from and writing to very large disks is too slow. The solution for this network bandwidth bottleneck has two principal features. First, HDFS provides a type of distributed architecture that stores data on multiple disks with enabled parallel disk reading. Second, move any data processing computational requirements to the data-storing node, enabling access to the data as local as possible. The enhanced MapReduce performance depends on this design principle known as data locality. The idea saves bandwidth by moving programs to the data, rather than data to programs, resulting in the MapReduce programming model scaling linearly with the data set size. For an increase in the cluster size proportionately with the data processed volume, the job executes in more or less the same amount of time.

Velocity The rate at which data is becoming available to organizations has followed a trend very similar to the previously described escalating volume of data, and is being driven by increased ecommerce clickstream consumer behavior logging and by data associated social networking such as Facebook and Twitter. Smartphones and tablets device proliferation has dramatically increased the online data generation rate. Online gaming and scientific instrumentation are also generating streams of data at velocities with which traditional RDBMS are not able to cope. Insuring a competitive advantage in commercial and gaming activities requires quick responses as well as quick data analysis results. These high velocity data streams with tight feedback loops require a NoSQL approach like Hadoop's optimized for fast storage and retrieval.

Variety Most generated data is messy. Diverse data sources do not provide a static structure enabling traditional RDBMS timely management. Social networking data, for example, is typically text-based taking a wide variety of forms that may not remain fixed over time. Data from images and sensors

feeds present similar challenges. This sort of unstructured data requires a flexible NoSQL system like Hadoop that enables providing sufficient structure to incoming data, storing it without requiring an exact schema. Cleaning up unstructured data is a significant processing part required to prepare unstructured data for use in an application. To make clean high-quality data more readily available, data marketplaces are competing and specializing in providing this service.

Variability Larger issues in the interpretation of big data can also arise. The term variability when applied to big data tends to refer specifically to the wide possible variance in meaning that can be encountered. Finding the most appropriate semantic context within which to interpret unstructured data can introduce significant complexities into the analysis.

The Hadoop ecosystem on Windows Azure

Introduction Hadoop on Windows Azure offers a framework implementing Microsoft cloud-based solution for handling big data. This federated ecosystem manages and analyses large data amounts while exploiting parallel processing capabilities, other HDFS architecture optimizations, and the MapReduce programming model. Technologies such as Sqoop and Flume integrate HDFS with relational data stores and log files. Hive and Pig integrate data processing and warehousing capabilities. Pegasus provides graph-mining capabilities. Microsoft Big Data solution integrates with Microsoft BI tools, including SQL Server Analysis Services, Reporting Services, PowerPivot and Excel. Microsoft BI tools enable you to perform a straightforward BI on data stored and managed by the Hadoop on Windows Azure ecosystem. The Apache-compatible technologies and sister technologies are part of this ecosystem built to run on top of Hadoop clusters are itemized and briefly described in this section.

Pig Pig is a high-level platform for processing big data on Hadoop clusters. Pig consists of a data flow language, called Pig Latin, supporting writing queries on large datasets and an execution environment running programs from a console. The Pig Latin programs consist of dataset transformation series converted under the covers, to a MapReduce program series. Pig Latin abstractions provide richer data structures than MapReduce, and perform for Hadoop what SQL performs for RDBMS systems. Pig Latin is fully extensible. User Defined Functions (UDFs), written in Java, Python, C#, or JavaScript, can be called to customize each processing path stage when composing the analysis. For more information, see Welcome to Apache Pig! Hive Hive is a distributed data warehouse managing data stored in an HDFS. It is the Hadoop query engine. Hive is for analysts with strong SQL skills providing an SQL-like interface and a relational data model. Hive uses a language called HiveQL; a dialect of SQL. Hive, like Pig, is an abstraction on top of MapReduce and when run, Hive translates queries into a series of MapReduce jobs. Scenarios for Hive are closer in concept to those for RDBMS, and so are appropriate for use with more structured data. For unstructured data, Pig is better choice. Hadoop on Windows Azure includes an ODBC driver for Hive, which provides direct real-time querying from business intelligence tools such as Excel into Hadoop. For more information, see Welcome to Apache Hive! Mahout Mahout is an open source machine-learning library facilitating building scalable matching learning libraries. Using the map/reduce paradigm, algorithms for clustering, classification, and batch-based collaborative filtering developed for Mahout are implemented on top of Apache Hadoop. For more information, see What is Apache Mahout. Pagasus Pegasus is a peta-scale graph mining system running on Hadoop. Graph mining is data mining used to find the patterns, rules, and anomalies characterizing graphs. A graph in this context is a set of objects with links that exist between any two objects in the set. This structure type characterizes networks everywhere, including pages linked on the Web, computer and social networks (FaceBook, Twitter), and many biological and physical systems. Before Pegasus, the maximum graph size that could be mined incorporated millions of objects. By developing algorithms that run in parallel on top of a Hadoop cluster, Pegasus develops algorithms to mine graphs containing billions of objects. For more information, see the Project Pegasus Web site. Sqoop Sqoop is tool that transfers bulk data between Hadoop and relational databases such a SQL, or other structured data stores, as efficiently as possible. Use Sqoop to import data from external structured data stores into the HDFS or related systems like Hive. Sqoop can also extract data from Hadoop and export the extracted data to external relational databases, enterprise data warehouses, or any other structured data store type. For more information, see the Apache Sqoop Web site. Flume Flume is a distributed, reliable, and available service for efficiently collecting, aggregating, and moving large log data amounts to HDFS. Flume's architecture is streaming data flow based. It is robust and fault tolerant with tunable and reliability mechanisms with many failover and recovery

mechanisms. It has a simple extensible data model enabling online analytical applications. For more information, see the Flume incubation site. Business intelligence tools Familiar Business Intelligence (BI) tools such as Excel, PowerPivot, SQL Server Analysis Services and Reporting Services retrieves, analyzes, and reports data integrated with Hadoop on Windows Azure using ODBC drivers. The Hive ODBC driver and Hive Add-in for Excel are available for download on the Hadoop on Windows Azure portal How To Connect Excel to Hadoop on Windows Azure via HiveODBC. * For information Analysis Services, see SQL Server 2012 Analysis Services. * For information Reporting Services, see SQL Server 2012 Reporting.

Big data scenarios for Hadoop on Windows Azure An exemplary scenario that provides a case for an Hadoop on Windows Azure application is an ad hoc analysis, in batch fashion, on an entire unstructured dataset stored on Windows Azure nodes, which do not require frequent updates. These conditions apply to a wide variety of activities in business, science, and governance. These conditions include, for example, monitoring supply chains in retail, suspicious trading patterns in finance, demand patterns for public utilities and services, air and water quality from arrays of environmental sensors, or crime patterns in metropolitan areas. Hadoop is most suitable for handling a large amount of logged or archived data that does not require frequent updating once it is written, and that is read often, typically to do a full analysis. This scenario is complementary to data more suitably handled by a RDBMS that require lesser amounts of data (Gigabytes instead of Petabytes), and that must be continually updated or queried for specific data points within the full dataset. RDBMS work best with structured data organized and stored according to a fixed schema. MapReduce works well with unstructured data with no predefined schema because it interprets data when being processed.

Getting started with Microsoft Hadoop on Windows Azure The Hadoop on Windows Azure CTP The Hadoop on Windows Azure service is available by invitation only during this Community Technical Preview (CTP). The CTP purpose is for you to test Hadoop-based service on Windows Azure, become more familiar with it, and provide feedback. The process for gaining access is outlined below. The portal used by Apache Hadoop-based services for Windows Azure The Microsoft implementation of Hadoop on Windows Azure uses a Portal to provision new Apache Hadoop clusters. Clusters provisioned on the portal are temporary and expire after several days. When there is less than six hours left on the clock, an expiration time extension is allowed. These clusters run jobs that process data either on the cluster or located elsewhere. For example, the data could reside in a Windows Azure account or be transferred to the cluster over FTP.

The advantage of using a temporary cluster is that there is no cost to maintain the hardware needed for the MapReduce parallel processing jobs. You use the cluster and then release it or allow it to expire. Apache Hadoop deployment solutions are also available for deploying Apache Hadoop to a Windows Azure account, or on-premise hardware that you manage.