This course shows you how to use Azure's Cloud Service platform service offering.
By the end of this course, you'll have gained a firm understanding of the key components that comprise the Azure Cloud Service platform. Ideally, you will achieve the following learning objectives:
- How to design and develop an Azure Cloud Service.
- How to configure and deploy a cloud service.
- How to monitor and debug a cloud service.
This course is intended for individuals who wish to pursue the Azure 70-532 certification.
You should have work experience with Azure and general cloud computing knowledge.
This Course Includes
- 1 hour and 2 minutes of high-definition video.
- Expert-led instruction and exploration of important concepts surrounding Azure cloud services.
What You Will Learn
- A general overview of Azure cloud services.
- How to design, deploy, and manage cloud services.
- How to monitor your cloud services and debug them.
Hello, and welcome back. In this section, we'll see how we're able to deploy a cloud service to a live Azure environment. Firstly, we'll see how we're able to turn a Visual Studio cloud service solution into a deployable package, and then, how to upload that package into a cloud service. Next, we'll look at how we can move a stage in deployment to production, with what's called a VIP switch. Then, we'll see how we're able to deploy a cloud service, automatically, after a successful build in VS Online, before looking at how we can use the Azure management portal to make changes to our application whilst it's running. Finally, we'll see how we're able to configure regions that the cloud service will be deployed to.
Let's first look at packaging a cloud service. This is the process of bundling up all the code in our cloud service into a form that can be deployed into Azure. To package a cloud service using Visual Studio, we simply right-click on the cloud service, and select Package. From there, we need to specify whether we're going to be using the release or debug build, and which environment and configuration we want to use. Normally, for a deployment to Azure, you will use the cloud configuration. Having set this up, clicking Package will then generate a zip file containing all of the required files to deploy the project into the cloud service.
Before we see how to upload a cloud service package into Azure, let us discuss the notion of update strategies, that is, how we update code to an already running service. Azure cloud services understands the notion of an upgrade, rather than a full deployment, and allows us to control how that update occurs. There are several different strategies available. We'll start with what is known as the incremental update strategy. The incremental update strategy will partition instances into the number of upgrade domains. From there, it will apply the upgrade to each domain consecutively. This ensures that there's no downtime for the application. However, it does slow down the deployment significantly, as each upgrade has to be done sequentially.
An alternative is the simultaneous update strategy. This applies the upgrade to every cloud service instance simultaneously. This approach is the fastest, but leads to there's a potential for application downtime, whilst it is in the process of upgrading. The full update works in a similar manner to the simultaneous update strategy, but rather than reusing the old instances, it will destroy the old virtual machines, and create new ones in their place.
When dealing with upgrade domains, we're able to specify the number we want to use directly in the service definition file. In this case, we've specified that we're to use 20 upgrade domains, instead of the usual five. There are certain changes which prevent us from performing a upgrade, and instead, force us into performing a full deployment. These operations include changing the name of a role, changing the number of upgrade domains, or reducing the size of local storage resources. If we try and deploy these changes as an upgrade, the Azure infrastructure will present us with an error instead.
In this demo, we'll see how the package can deploy a cloud service from within Visual Studio, and the Azure portal. We can easily deploy a cloud service solution from Visual Studio by right-clicking on the cloud service, and choosing the Publish option. We first need to sign into our Azure account. Having signed into our account, we'll have to provide some settings. We'll first pick the cloud service. If this doesn't exist, we'll be prompted to create a new one, but here, I'm using one I've already created. We could also set the environment, build configuration, service configuration too. In this case, I'm gonna use the default production release and cloud options. We can then hit Publish, to get on with the process of first, building the project, and then, packaging it locally, and deploying it to Azure.
Having hit Publish, we can then see that the cloud service solution has been bundled up into a cloud service packaged locally into the release App.Publish folder. It is now being uploaded into Azure. Once the package has been successfully uploaded and deployed into the service, we can look into the portal to see it. Here, you'll see our service with the two roles, WebRole1, and WorkerRole1. We can also upload a CS package into the cloud service from directly within the portal. We hit the Update button, and we have some information to provide. Firstly, we'll pick a cloud storage account. And then, we'll enter a deployment label. Finally, we can package that what we have already created, and the associated configuration with it. We now have selected both the package and the configuration file. Azure has confirmed that the files are valid, and has started uploading them into the service. Once we're happy with this, and they have successfully been uploaded, we're okay to apply our changes on the service, and this will conclude the demo.
We're able to create zero downtime deployments with cloud services, by having two environments running simultaneously, a production environment, and a staging environment. Typically, all traffic will be directed to the production environment. However, using the management portal, we can perform what is known as a virtual IP, or VIP switch, which means that the staging environment takes the address off the production environment, and vice versa. All traffic, then, directed at the production address is routed to the role which was formerly in staging. In effect, this allows you to deploy a new version of the application to the staging environment, and when you're satisfied that it works, switch over from the production deployment to that one with no downtime whatsoever.
We can deploy a new staging environment by selecting the staging tab in the management portal, and then, uploading a package exactly as we did when deploying to production. Having done this, we now have an environment available, which allows us to perform tests in a live environment. If we want to promote our deployment from staging to production, we initiate a VIP swap, by clicking the Swap button in the task bar in the management portal. We're then prompted for confirmation to verify that the current deployment in the staging environment will take over the current production environment. Selecting yes proceeds with the VIP switch. After the VIP switch, we can safely delete the previous deployment.
We also have the opportunity to build up a continuous delivery pipeline, whereby we write code, check in the changes, have a build server build the code, and automatically deploy to a cloud service instance. Here, we'll look at how we're able to configure continuous delivery using Visual Studio Online.
In order to deploy a project from source control, we first need to have the project committed to a project in Visual Studio Online. We can use the Team Explorer to achieve this, and commit the pending changes within our project. Note that to create a CI deployment from within the portal is not currently available, so we need to perform this from the classic Azure management portal. From the portal, open the Cloud tab. We then choose to setup publishing from the source control option. We then authenticate with Visual Studio Online by entering our credentials. We then choose the repository we want to use for the deployment, and click the check mark. Next time, a check in is detected by Visual Studio Online, the build will be triggered, and upon successful build, the build is then deployed to the cloud service.
It's common to need configuration variables within an application. Cloud services are no different. We can set both string and connection string values into a given role, with different values for both local and cloud configurations. There's also a set of events that you can hook into to programmatically react to changes in values of the configuration setting.
In this demo, we'll see how to create and access configuration settings. In order to use a configuration setting, we first need to declare it, by opening the settings to the role, and navigating to the Settings tab. Here, you can see several settings that have been created, city and weather. These are both strings, but you can also see a connection string above. Also notice that you can set different values for cloud and local environments. And if we look at the configuration files for both environments, we'll see that the values have been copied into both. The cloud services SDK also has a cloud configuration manager class to retrieve conflict settings for you in code. This is available as a new get package, that I've already downloaded and installed into the solution. It's extremely easy to access the settings using this class. We can also access and modify configuration settings through the portal. From the service, we can select configuration, and can see that the settings are also accessible here. And we can also modify the values directly from within the portal. And this concludes the demo.
Within our worker role, we're able to sign up to be notified of events which we receive from the cloud service runtime, when certain environment changes happen. One such example is the configuration settings within the role change. In that case, it's likely that we'll need to update the application to use a new connection string or setting. By signing up to the role environment changing event, we're able to receive these notifications. In this case, we've registered for the notification, and whenever we receive any changes, we first check to see whether we're changing the environment. If the environment is changing, then we can set e.Cancel to be true, which forces the role environment to recycle the role, allowing us to reload all of the configuration at the application startup. After deploying our application, the settings are available in the management portal. We're then able to modify them to be new values. In this case, the values have been changed to use a production SQL server address, and the environment has been changed to production. Saving the changes will deploy the configuration onto the worker role, and invoke the event handler we previously created.
In the last topic of this section, we'll discuss regions and affinity groups. When we deploy our cloud service, we're able to deploy it to either a region or an affinity group. A region specifies the geographical location, as to where the cloud service resides. For example, North Europe, Western USA. You should give it a thought to where you deploy your services, based on the international regulations and laws, as well as traffic. For example, where your customers will be based, as well as where other services your applications connect to. An affinity group ensures that your resources are not only located in the same region, but are also located within co-located physical servers. This is not necessarily as much as a concern as it was when Azure first came out, due to redesigns of the Azure data centers, and they also restrict you to only use resources, such as VM sizes, that were available at the time when the group was created.
If we want to deploy a cloud service to an affinity group, we first need to create a new affinity group. One way we can manage this is by using Powershell. To create one, we simply invoke the New Azure Affinity Group commandlet, as specified here. Having created an affinity group, we're then able to specify the affinity group as the deployment target, when we use the New Azure Service commandlet. We can also specify an affinity group when we create a new cloud service using Visual Studio. We simply need to choose the given affinity group, rather than the region.
Stay tuned for the next section, where we'll discuss monitoring and debugging cloud services.
About the Author
Isaac has been using Microsoft Azure for several years now, working across the various aspects of the service for a variety of customers and systems. He’s a Microsoft MVP and a Microsoft Azure Insider, as well as a proponent of functional programming, in particular F#. As a software developer by trade, he’s a big fan of platform services that allow developers to focus on delivering business value.