Azure Websites and Azure Cloud Services

PaaS Cloud Services

In Azure, there are two uses of the phrase “cloud service.” One is as a container for VMs that you create and maintain yourself. For example, you might create four VMs that are identical and put them in one cloud service. Then you would use the IP address of the cloud service as the entry point, and Azure would provide automatic load balancing of the four VMs. If you want to update the application running on those VMs, you must deploy it to each of the VMs. You can put them in an availability set to ensure that you always have a minimum number of VMs available. If you want to scale the application up or down, you must manually add or remove VMs to or from the cloud service or stop or start them. These VMs will be covered in Chapter 3.

The second kind of cloud service is one in which Azure maintains and manages your VMs for you. When you want to update all of the VMs, you just publish a new version of the application, and Azure updates each of the VMs, making sure to cycle through them so there’s no downtime. If you want to change the number of VMs, you just log into the Azure Management Portal and change the instance count, and Azure will add or remove the requested number of VMs for you.

This section is about the second kind of cloud service. In these cloud services, you have either web roles or worker roles. The only difference between the two is that web roles have IIS running in them by default. Web roles generally are used for web applications, WCF services, and anything else requiring IIS.

Worker roles generally are used for processing that needs to be continuous. For example, you might have a queue with messages on it that you want processed. The worker role runs an infinite loop that checks for messages on the queue and, if found, retrieves them and processes them. You can do substantial processing of images, video, files, etc. in a worker role.

Creating a cloud service

Let’s create a cloud service with a web role in it. Then we can look at the configurations and see how to publish it.

1. Using Visual Studio, create a new project (FILE > NEW PROJECT). For the type of project, select Windows Azure Cloud Service.
2. Fill in the name of the solution and click OK. (If you don’t have Windows Azure Cloud Service in the list of projects, then you need to install the Azure SDK and Tools.) Next you will be prompted to select your role(s).

3. Select the ASP.NET Web Role and click the right-facing arrow to copy it to the right. Hover over it and click the pencil if you want to change the name of your web role before continuing and then click OK. Because you selected an ASP.NET Web project, you will be prompted to select which kind of ASP.NET project. Select MVC and click OK to continue.

   

   Click to view larger image

Now when you look at your solution, you will see the project with the web role (MVC application) and the project with the cloud service; see Figure 2-20.

In the web application project, notice there is a WebRole.cs. This is what starts up when the web role spins up in Azure. By default, this is blank, but you can put in event handlers for the role starting up and shutting down. For example, if you were going to use an Azure queue, you might want to add code to the role startup to make sure the queue exists and create it if it doesn’t.

If you double-click the role, you can access its properties. Here are some of the most commonly used properties:

• Configuration VM Size, Instance count, diagnostics configuration, storage connection strings. To qualify for the service level agreement (SLA), a minimum instance count of two is required.
• Settings Configuration settings that you can retrieve in code. These can be modified in the Azure Management Portal while the site is running live. You can have settings for multiple configurations, including debug and release.
• Endpoints By default, a web role will have an HTTP endpoint open. You can modify that and open other endpoints such as HTTPS.
• Local Storage You can configure local storage for each instance. For example, if you wanted a 5 GB drive to use for temporary files, you would configure that here. Each instance would have its own 5 GB local resource space.
• Certificates You can configure certificates to be used for SSL and for Remote Desktop (RDP) access here. You also must upload the certificate to the Azure Management Portal.

The settings are stored in XML format in the ServiceConfiguration.*.cscfg file(s). There are a couple of properties in the XML in that file that are not surfaced through the UI: osFamily and osVersion. osFamily selects the operating system that will be running in the VM. For example, osFamily 4 is Windows Server 2012 R2; osFamily 3 is Windows Server 2012; and osFamily 2 is Windows Server 2008 SP2.

To learn more about these values, check out the article “Azure Guest OS Releases and SDK Compatibility Matrix” at http://msdn.microsoft.com/en-us/library/ee924680.aspx. Unless your application requires a specific version, leave the values at the defaults, which are currently osFamily = “4” and osVersion = “*”. The asterisk in osVersion means it will use the most recent version of the selected osFamily.

You can have multiple ServiceConfiguration.*.cscfg files. When you publish, it will ask which one you want to use. There is only one ServiceDefinition.csdef file. This has the master list of configuration setting variables and the endpoint definitions. It also has the instance size. Instance sizes range from Extra Small (shared, 1 CPU core, 768 MB memory) to A9 (16 CPU cores, 112 GB memory). Also available is the new D-series VM, with faster processors, a Solid State Drive (SSD) for the temporary disk, and a higher memory-to-core ratio.

For more details, check out “Virtual Machine and Cloud Service Sizes for Azure” at http://msdn.microsoft.com/en-us/library/azure/dn197896.aspx.

You can test a cloud service by using the storage and compute emulators. These are installed as part of the Azure SDK and Tools. If you make the cloud service your startup project, you can just hit F5 and the emulator(s) will start up and the application will run in your default browser.

Publishing a cloud service

Let’s publish our cloud service from the previous section.

1. Open the solution in Visual Studio.
2. Before publishing your cloud service for the first time, you have to create a cloud service in the portal. To do this, log into the Azure Management Portal (manage.windowsazure.com) and click CLOUD SERVICES in the left column.
3. On the bottom of the page, click +NEW > CLOUD SERVICE > QUICK CREATE; you will be prompted for URL and REGION. The URL must be unique among all cloud services. Note that the domain of the URL will be cloudapp.net. Select a region close to you and click CREATE CLOUD SERVICE. Azure will create your cloud service. This has no instances yet; when you publish your application, Azure will start up the instances, install your application, and then enable them for access.

4. In Visual Studio, right-click the cloud service project and select Publish. You will be prompted for the Microsoft account you use for Azure; log in. Now it shows your subscription in the Publish Windows Azure Application window. Click Next to get to the Settings screen.

   

   Click to view larger image

5. Select the cloud service you just added via the portal. For Environment, you can select Production or Staging (more on that later). If you are going to do remote debugging, select a Build Configuration of Debug; otherwise, set it to Release. The Service Configuration is a list of configurations from Visual Studio. This one shows Cloud and Local, but you could have one for production, one for staging, and one for development, and select which one to use here. This is a good way to support multiple environments with different configuration settings (such as database connection strings) in a cloud service.

The advanced settings are shown in Figure 2-21.

This is where you can set a deployment label. For example, you might put a version number in this field. You can also append the date and time to the deployment label. You will be able to see this in the portal, and it will help you know when it was last deployed.

The storage account is used to retain the package that is uploaded for you. The instances are built from the information in that package. The package consists of two files. One is the zipped versions of the application assemblies; the other is a configuration file specifying application configuration.

Accept the defaults here and click Next.

This will take you to a summary screen that will show all of your selections and let you save this publishing profile to be used again. After saving the publishing profile, click Publish.

Visual Studio will open a Windows Azure Activity Log window and display the progress of the deployment. It will verify the storage account, upload the package, create and start the instances with the right operating system on them, install your software, and then make the application available. This takes 5 to 10 minutes. The activity window will look similar to Figure 2-22 when publishing is completed.

You can click the Website URL, and it will open your website in your default browser.

Another way to publish your cloud service is to right-click the cloud project and select Package and have Visual Studio create the deployment package for you. The package consists of two files. One is the zipped versions of the application assemblies; the other is a configuration file specifying application configuration.

Next you can go to the portal and do an UPDATE on PRODUCTION or select the STAGING environment and select UPLOAD. This will allow you to upload the package, and Azure will do the same thing as publishing from Visual Studio. It’s just doing the upload package manually instead of having Visual Studio do it for you. You might want to do this if you have one group create the packages and another deploy them to staging or production.

Scaling and monitoring a cloud service

The easiest way to scale a cloud service is to set the VM Size and Instance count in the service configuration and republish. Another way to do this is to use the scaling options in the Azure Management Portal (manage.windowsazure.com). Log into the portal, and let’s take a look at the features for the PaaS cloud service.

After logging in, click CLOUD SERVICES in the left column. Note that both kinds of cloud services are displayed here in the same list: the PaaS cloud services and cloud services that you create as a wrapper to one or more VMs, as discussed in the beginning of this section. Select the cloud service that you created and published in the previous section.

SCALE options

To scale a cloud service, go to the SCALE option. Here are the options available:

• SCALE BY SCHEDULED TIMES To use this feature, click Set Up Schedule Times. This opens the schedule times screen. You can specify the start and end time for a day and scale settings for day versus night and weekdays versus weekends. You also can specify scale start and end times for specific dates. (This is identical to the Scale By Scheduled Times option for websites displayed in Figure 2-17.)
• SCALE BY METRIC: CPU or QUEUE Several of the options are the same, whether scaling by CPU or QUEUE.

• When scaling by CPU, you select the target CPU that will trigger the scaling event. For example, you might want it to scale when the CPU percentage is between 60 percent and 80 percent; see Figure 2-23.

  

  FIGURE 2-23 Setting target when scaling by CPU.

When scaling by queue, you select the storage account and queue name, as well as the target number of messages each instance can handle. If you take the total number of messages in the queue and divide it by the number of messages that each instance can handle, you get the number of instances that are needed. It will try to scale to this number or to the maximum number of instances, whichever is smaller. For example, if you set this to 500 and 2,000 messages come in, it will scale up to the maximum number of instances or four instances {2,000 messages divided by (500 messages/instance) = 4}, whichever is smaller (see Figure 2-24).

For both options, you can change the instance range. This is the minimum and maximum number of instances you want to have; see Figure 2-25.

For both options, you can select the number of instances by which to scale in or out with each autoscale event and how long to wait before scaling again. For example, you might want to scale out two instances at a time, but not more than once every 20 minutes. For scaling down, you might want to scale in one instance at a time, but not more than once every 30 minutes in case the activity increases again; see Figure 2-26.

An important thing to note: the monitoring framework reads about 15 minutes behind and the data it is reading is a 45-minute average, so it takes about an hour for the autoscale event to be triggered. If the CPU spikes to 75 percent and comes right back down, it will not trigger an autoscaling event; it must be a sustained spike.

Monitoring

There are two ways to monitor performance for a cloud service. One is through the Azure Management Portal (MONITOR tab), and the other is through Visual Studio. In the portal, go to the MONITOR tab for the cloud service and click +METRICS on the bottom of the page; see Figure 2-27. There is a minimal list of metrics available.

If you go to the CONFIGURE tab and change the monitoring level to VERBOSE and let it run a bit, then click +METRICS again in MONITOR, you will find that many more performance metrics are available to add to MONITOR. Azure will write 5-minute, 1-hour, and 12-hour averages to tables in Azure Storage with names like WAD[deploymentid]PT1HRTable. You can set the data retention time in days.

The other way to add performance metrics is through Visual Studio. Open your solution, go to the cloud service properties, and select the Configuration tab. You will find that you can define a Custom Diagnostics plan; see Figure 2-28.

Select Custom Plan and click Edit to open the Diagnostics configuration. On the Performance Counters tab, you will find many other metrics that you can add. You can even add performance counters not already in the list; see Figure 2-29.

These diagnostics are written to the table called WADPerformanceCounterTable, and they are written roughly every five minutes as point-in-time values. There is no automatic retention time for this data; it will stay in the table until you remove it.

Of the two options, I recommend using the configuration in Visual Studio because the other tables have the deployment ID in the table name, and the deployment ID changes each time you deploy a cloud service. This means if you want to graph your metrics over time, you have to search each table. If you make the changes in Visual Studio, all of the metrics are stored in the same table, making it easier to query the information over time.

Miscellaneous points

Here a few items to keep in mind:

Configuration in the portal

You can modify the operating system family and version on the CONFIGURE tab in the Azure Management Portal. If you have configuration settings in your web role or worker role, you can edit those in the portal and save them. In both of these cases, the original package uploaded to Azure is not modified. This means if Azure installs patches on your VMs and reboots them, the manual changes you made through the portal will be lost. So if you make these changes via the portal, be sure to follow up by modifying the Visual Studio solution and deploying a new version.

Production and staging slots in the portal

Each cloud service has both a production and a staging slot. The production slot uses the URL assigned, such as yourgreatwebapp.cloudapp.net. The staging slot is assigned a globally unique identifier (GUID) for the URL, which changes each time you deploy a new package to it. This makes it difficult to test intertwined cloud services, such as A calls B calls C. You either have to change the address in A that points to B and the address in B that points to C, or you have to change the domain name system (DNS) entries, which can take time to propagate.

One way around this is to set up multiple cloud services for one web application in the Azure Management Portal. For example, you might set up MyWebApp for production and stMyWebApp for staging. Publish to staging and do your testing. When you are ready to put the changes in production, publish to the staging slot of MyWebApp and do a VIP Swap, which swaps the IP addresses for the two deployment slots, effectively putting the new one in production. Don’t forget to delete the old one in the staging slot!

Worker roles

To add a worker role to your cloud project, right-click the Roles and select Add New Worker Role Project. Worker roles generally are used to retrieve messages from a queue and process them and then delete the messages from the queue.

A good example of this is having a web application that lets a customer upload pictures. You want to resize the pictures, so when the upload is completed, you write a message to the queue. The worker role would retrieve the message from the queue, resize the photos, put them in the destination folder, and then delete the message from the queue.