In this series we’ll be looking at a core component of the Microsoft Azure platform: Cloud Services. Though new features are added regularly to Microsoft Azure, the platform has been around for a few years now and Cloud Services (previously called Hosted Services) have been offered from the start.

Cloud, you say?

Yes, “the cloud”. You might be using the cloud when you’re playing a game, when you’re talking to your friends, to store your files, or to host your applications. Before we start digging into the technical details of Cloud Services it’s important to take a closer look at the different ways you can run your application:


Figure 1 – Ways to run your applicationGraphic provided by Azure Training Kit, Microsoft

Figure 1 shows a few of the ways you can run your application. Listed first is the option that was, for many years, the most obvious: running the application on premises. Running on premises means you have to do pretty much everything, from buying the servers and licenses to setting up the routers and applying load-balancers. If your application isn’t run in a data center you also have to handle operational problems like cooling, backup power, and managing access to the server room.

Depending on your needs, all of this might add up to too much overhead: this is why the cloud, where overhead is minimal, might be a good alternative to on-premises deployments.

One type of cloud alternative is Infrastructure as a Service (IaaS). With IaaS you manage everything that runs within the OS, and your cloud provider handles the rest: the physical management of the servers, taking care of storage and the network, virtualization, backup power, etc. The only thing you need to worry about is installing the operating system and configuring the server to suit your needs. I think it’s safe to say that this is the most popular alternative to on-premises deployment, because for many of us it feels very similar to all those years we spent managing servers on premises. The advantage here is that we can focus on managing the server and our applications without having to worry about hardware, licenses and all those other things that potentially increase our time to market.

The fact that, with IaaS, we no longer need to worry about buying hardware and licenses – we now simply rent those resources – also makes this a far more interesting model for smaller companies and startups.

Microsoft Azure’s IaaS offering includes the Virtual Machines feature, which is perfect for migrating your on-premises deployments to the cloud, running applications like SharePoint and SQL Server, and even running your own custom applications. But remember: with IaaS, you manage the OS and everything that runs within it, so there’s still a lot that’s up to you. You’ll need to correctly configure the OS and any services you require on it (like IIS), make sure the machine is secure, apply updates and security patches (Heartbleed, anyone?), and so on.

So, while IaaS gives you the most flexibility, this might still be too much overhead, depending on your requirements. What if you simply want to build an application without having to worry about anything else? Well, in that case you might want to take a look at using a Platform as a Service (PaaS).

With PaaS there’s much less need to spend time on your infrastructure, so you can spend more time on your application. In Figure 1 you can see that, with PaaS, the OS, the middleware and the runtime are now also managed by the cloud provider, so you can focus mainly on how to build your application and where to put the data. The most popular PaaS features you’ll find in the Microsoft Azure platform today are Microsoft Azure Cloud Services and Microsoft Azure Web Sites, and in this series we’ll focus on Cloud Services.

The big advantage of Cloud Services is that all you need to do is build your application, package it, and finally deploy it to Microsoft Azure: all the rest is done for you. The Fabric Controller (the core or the kernel of the Microsoft Azure platform) will then make sure that the servers needed to run your application are provisioned, configured, and monitored. It will take care of load-balancing user requests, and will try to heal your deployment if something goes wrong with one of the servers – and all of this is done automatically.

But again, depending on your requirements, you might not even need to build an application. Maybe you can just rent some software that fulfils your requirements: in that case we’re talking about Software as a Service (SaaS). This is where you simply want to use some software without having to worry about anything else. Keep in mind that, most of the time, this will again reduce the flexibility of the platform you’re using.

Take SharePoint Server, for example. You could buy the required hardware and simply run SharePoint Server on premises. If there’s no real need (like a legal requirement) to run SharePoint on premises, you could consider running it in a virtual machine (IaaS). That way you wouldn’t need to invest upfront in hardware or licenses. But if you also don’t really need to manage your own SharePoint infrastructure, you could go further and get SharePoint Online, a SaaS version of SharePoint offered in Office 365. Here, everything is managed by Microsoft and you simply get to use SharePoint.

This is where requirements and flexibility come into play. Office 365 heavily restricts the customization you can do with SharePoint Solutions (and apps for SharePoint are a different story).

If you can live with the out-of-the-box features offered by SharePoint Online then the SaaS offering might be the best pick for you, but if you need to make heavy customizations in SharePoint to fulfil your requirements you probably wouldn’t want to move to SaaS.

There will always be different ways to host your applications and by knowing your requirements you’ll always find the one that fits you best. And now it’s time to get started with Microsoft Azure Cloud Services, to let you see how to put some of these hosting options into practice!

Getting started

In order to get started we first need to install the Windows Azure SDK, which is required to build Cloud Services. The easiest way to do this is through the Web Platform Installer (WPI), as indicated in Figure 2. (You can alternatively download the manual installers from the Microsoft Azure downloads page.) The version of the SDK you’ll need to install depends on which version of Visual Studio (or Visual Studio Express) you’re running.


Figure 2 – Installing the Windows Azure SDK with the Web Platform Installer

The Azure SDK installs the following components on your machines:

  • (Storage) Tools (Visual Studio support for browsing your subscription)
  • Authoring Tools (support to build and package Cloud Services)
  • Libraries for .NET (libraries to interact with Storage, Cloud Services, Diagnostics, etc.)
  • Storage Emulator (emulation of a Microsoft Azure storage account)
  • Compute Emulator (emulation of Microsoft Azure Cloud Services)
  • ASP.NET and Web Tools

After installing the required components, when you launch Visual Studio you’ll see support for building Cloud Services. Go ahead and create a new Cloud Service named “Hello World”.


Figure 3 – New Cloud Service

When you create a Cloud Service you also get a chance to define the various roles required by your application. We’ll look at roles in more detail in later articles, but for now you can think of roles as templates for the servers that will be deployed, defining the size of the machines, the OS version, and the type of application to be run (a web application running in IIS, for example).


Figure 4 – Roles

For the HelloWorld Cloud Service, let’s add an ASP.NET Web Role to host a simple web application showing “Hello World”. When you choose an ASP.NET Web Role, you need to make an additional choice that isn’t related to Cloud Services: you need to specify the type of ASP.NET application you’re building. Since we’re building a very simple application the “Empty” template will do (for this example let’s use the Web Forms option, though MVC is supported with these roles as well).

After a few seconds your solution has been created. The solution looks like a normal ASP.NET project, but you’ll notice a few differences: besides your Web project there’s also a Cloud Service project, and your Web project now comes with a WebRole.cs file. These again are all things we’ll cover throughout the series.


Figure 5 – Solution

Now, to finalize the sample application, simply add a Web Form to my application named Default.aspx: your sample application is now ready and you can go ahead and start it. When you press F5 you’ll see Visual Studio starting the Windows Azure Debugging Environment. If you take a closer look at the progress window you’ll see that a few things are happening: Visual Studio is starting the storage emulator, the compute emulator, and deploying the application to the emulator. This is the main tool that the SDK gives you: the ability to emulate how your application will run when deployed as a Cloud Service.

The first time you run a Cloud Service with Visual Studio it will start the emulator, which will be available from the tray (indicated by a Microsoft Azure icon). Right-clicking on the emulator icon lets you control the emulator and open it (see Figure 6). By now you may know that there are actually two emulators: one for your application and one to simulate the storage account.


Figure 6 – Hello World running in the Emulator

Your browser should also have opened, showing the Default.aspx page with the “Hello World” text. Congratulations! You just created your first Cloud Service and, since it runs fine locally, we can go ahead and deploy it to Microsoft Azure.

Deploying your first application

The Publish feature in Visual Studio helps you to get your application running in no time. The only prerequisite here is that you have a valid Microsoft Azure subscription. Right-click the Cloud Service project and choose Publish: this will bring up the Publish wizard. If this is the first time you’re doing this you’ll probably see a login page. Enter the credentials of a Microsoft account or Azure Active Directory account related to the subscription where you want to deploy your application.

After choosing a subscription you’ll need to create a Cloud Service and a Storage account. For this example I created a Cloud Service named justazurehelloworld. It’s common practice to include the name of your application in the name of the Cloud Service, because you’ll typically have one Cloud Service per application. Oh, and if you were wondering, creating a Cloud Service is free: you are billed for the resources deployed in a Cloud Service but not for the Cloud Service itself.


Figure 7 – Publish window

There are plenty of settings you can change before deploying, but for this example the default values are OK, so go ahead and press Publish. Visual Studio will start building the application and, once that’s done, will upload the package to your Storage Account; it’ll then start the deployment by referencing the package. You can follow the progress of the deployment from the Azure Activity Log (Figure 8) or from the management portal.


Figure 8 – Activity Log

While the application is deploying let’s take a minute to look at what’s happening here. The package has been uploaded and Visual Studio has initiated the deployment through the Service Management REST API. After receiving the request, the Fabric Controller has been told exactly which resources need to be provisioned before it can deploy the application.

First it will provision a virtual machine – in Cloud Services, we call this an “instance” – with Windows Server 2012 R2 (the default option in Visual Studio 2013 for the project we just created) and launch IIS 8.5 on that machine. Once the machine has been provisioned the Fabric Controller will get the application binaries and content (Web.config, Default.aspx, etc.) from the package and deploy it to this new machine. Finally the controller will configure the load balancer to accept incoming requests to the application.

When I deployed the application, it took a little over six minutes after pressing the Publish button for the application to become available online. Can you imagine how long it would have taken in an on-premises deployment, where we would have needed to order the required licenses and hardware, configure the server, configure a load-balancer and firewall, and so on? The Microsoft Azure platform can do all these things for us, allowing us to reduce drastically our time to market.

The last entry in the Azure Activity Log should confirm that the deployment has been completed. But how can we test it? Well, when we deployed the application to a Cloud Service it also received a public IP address and a hostname. The IP address will not change until we remove the production slot (more about that later) and the hostname is always: nameOfyourCloudService.cloudapp.net. When I deployed the application I created a Cloud Service named justazurehelloworld, so the hostname of my application is justazurehelloworld.cloudapp.net. Figure 9 shows the final result of my deployment after browsing to the hostname of my Cloud Service.


Figure 9 – Hello World! Application deployed

How much power do you need?

So, your application is running, people start to use it, and everybody is happy. But then users start complaining that the application is getting slower and slower. Michael Collier has a great series on the different options you have for monitoring applications running in Microsoft Azure. The easiest way to do this is through the Management Portal. The info you’ll get here is very limited, but it will do for this example:


Figure 10 – Management Portal

When you open your Cloud Service in the Management Portal you’ll get a brief overview of how your application is behaving. If users start complaining that the application is acting slow, there’s a good chance that your instance (virtual machine) can’t handle the load. In that case it might be a good idea to add a few extra instances to your Cloud Service.


Figure 11 – Scaling out

On the Scale tab (Figure 11), if I change the number of instances from one to four, you can witness the true power of the Microsoft Azure platform. After I press the Save button the Fabric Controller will provision three extra machines and configure them in exactly the same way as the first machine.

After that it will reuse the package we deployed a while ago to deploy the application on those additional machines. Wait a few minutes for the scale-out to complete, and we’ll now have four instances of the application running (on four virtual machines). The load balancer will do what’s necessary to distribute the requests over the different machines (using the round robin technique).

Now, as well as adding extra resources to our application, we’ve made something else happen. Because we’re running with more than one instance in our Web Role, our Cloud Service will have an SLA of 99.95% availability because it runs in multiple fault domains. We’ll look at fault domains in more detail in a later article, but in essence we’re saying that the application is now deployed in multiple racks. This means that, in the unexpected event that the entire rack stops working (due to an issue with the switch, for example), the application is still deployed in a different rack. If your Role runs on a single instance it runs only in a single rack, which means there’s a higher risk that your application can go down. Running on multiple instances also gives you some protection when an instance needs to be taken down and replaced to apply security patches or the host or guest OS needs updating. As long as your application runs on more than one instance, it won’t disappear while updates are applied.

With Cloud Services, you can also scale down as easily as you scaled up. If we don’t need those additional resources we can throw them away and stop paying for them. This shows the flexibility of the Microsoft Azure platform and the cloud in general: have you ever tried scaling down in an on-premises environment? The investment has been made, end of story. You can’t simply give back to your supplier the hardware and licenses you no longer need. You’re stuck with it, even if you don’t want it.

Let’s compare this to the “pay only for what you use” model in Microsoft Azure. The calculator will give you a good understanding of the cost of running this application in Microsoft Azure. For this example I ran four Small Instances for one hour. Figure 12 shows how much it would cost me to run this application on four Small Instances for one month. The thing is, I didn’t run this application for a month, just for an hour: Microsoft Azure’s billing will reflect this, so I’ll have a bill for just the $0.32 of usage I actually had, another great advantage of using Microsoft Azure.


Figure 12 – Price for running the sample application

To the cloud and beyond

In this article we looked at different ways to deploy your application and the advantages of deploying with Cloud Services. We created a simple Cloud Service with Visual Studio, tested it locally with the emulator, deployed it to a live environment, and used the power of the cloud to scale our application.

The next articles will cover every aspect of Cloud Services in detail. We’ll look at the different types of application you can run in a Cloud Service, how they can interact with Virtual Machines, how to configure, scale, deploy, troubleshoot, and more. By the end of this series you’ll have a complete overview of what Cloud Services have to offer.

See you soon for Part 2: Anatomy of a Cloud Service.