Over a million developers have joined DZone.

On Cloudy Models: Azure Web Sites vs. Cloud Apps

DZone 's Guide to

On Cloudy Models: Azure Web Sites vs. Cloud Apps

· Cloud Zone ·
Free Resource

We have several new ways for you to run your applications in the cloud, and developers want a little guidance on how to pick which options. I hope to provide a little guidance around that.

The Model of the Models

Cloud platforms, as you know, can be broken into different categories. At the bottom, with the most control and the least ‘cloudy’ benefit is the IaaS, or Infrastructure as a Service. You get a VM, you have total control, and you get some, but not all of the cloud benefits. This is great when you are migrating existing enterprise applications.

The next step up is PaaS, or Platform as a Service. We call this Cloud Apps. The cloud service provides the platform for you to run your applications. You get a modicum of control (mostly how the environment your app runs in is configured) and you gain a great deal of benefit from not having to support the lower levels of the infrastructure.

Then there is SaaS, which as been around the longest in one way or another.  This is Software as a Service, with the most amount of abstraction from the infrastructure beneath the code that you write. We call this Web Sites.

As we move through these layers, we gain abstraction, and lose control. We have built all three of these types of clouds into Windows Azure so you can choose the type that works best for your app and your business.


First, what we already know

For years Windows Azure has had Cloud Apps. These are applications that are deployed to Windows Azure using the familiar Web Role and Worker Role format. Cloud Apps are a PaaS type of solution. We manage and give you a great platform to build your app on, while giving you some control of the environment. For example, you can tweak the standard image with startup tasks, configure what network traffic is allowed and so on.

Cloud Apps are great choice when you need a little bit of control, but you still don’t want to have to run the whole platform by yourself. If deploying a patch to your server doesn’t get you excited, then this is for you.

Cloud Apps will continue to be the place to go when you have complicated, mutli-tier apps. When you have a mixture of front end and back end servers that are all working together. Perhaps your app needs some customization in the environment, or you need that little bit of control to be able to deploy that COM object you are still dependent on. Do get this customization you can script it of just remote desktop in and make the change by hand.

Another reason to use Cloud Apps is to be able to leverage the new advanced networking that we have provided in the latest release. If you need to network your cloud servers to your on-premises servers, this is for you.

Cloud Apps also has that great production/staging slot system, making it super easy to deploy a new version with a VIP swap. And of course swapping back to the old version just as easily when things don’t go so well.

Web Sites for a truly hands off experience

So, you ask, when should you choose to use Windows Azure Web Sites? The most common reason is when what you are deploying is a pure or simple web application. If you don’t have other servers to deploy, and you just need an IIS container to run your code, then Web Sites is for you. This doesn’t mean that only simple web apps are a fit, you could have a very complex web app. What I mean is that you need a simple hosting environment, just an IIS container, and nothing more sophisticated than that.

If you are porting an existing web site, then Web Sites is probably the first stop for you as well. Just picking up your existing bits, and dropping them into our environment should be a fairly easy path to follow.

And of course, if you are launching an app built on one of the popular open source apps we have in the gallery, then that removes you from even having to deploy the app yourself. Read my post on how easy it is to deploy your blog on WordPress with Web Sites.

Web Sites still give you access to all of the other Windows Azure services like caching, service bus, SQL Database, and Storage.

The Cloud App deployment process requires building packages, and spinning up servers, which can take time. Web Site deployment process only requires ftp’ing or pushing over your bits. No delays, no hurdles, just deploy the way you are used to.

Prefer to push from GIT or TFS? We got that. Want to deploy with Web Deploy in VS? Check. Or just straight up connect with FTP to fiddle the bits directly? No problems.

Web Sites do start by running in a shared environment, where many customer’s sites are running on the same hardware, but with some process isolation. This is very common in almost all web hosting companies (cloud based or not). You can flip your site over to Reserved mode, where your sites are the only sites that are running on the hardware. When you do this you do leave the ‘free 10 sites’ area and move into having to pay for the hardware that you are using. But while we are in preview mode, that CPU costs are reduced. Official pricing will be available when we launch

Whereas Cloud Apps have about a 10-20 minute lag to spin up hardware, scaling up on the Reserved hardware is near instant, as that hardware is pre-allocated, and waiting for you. You can also scale up and down the number of servers, as in Cloud Apps.

The Short Answer

The short answer is:

Pick Web Sites:

  1. Just need IIS
  2. Ok running in shared space
  3. Don’t need or want any control below IIS

Pick Cloud Apps:

  1. You have sophisticated deployment and complex server needs
  2. Need some control of the platform, but I don’t want to manage patches
  3. You need isolated hardware

Pick VMs:

  1. Need total control
  2. What you are deploying isn’t cloud friendly
  3. Just trying to quickly migrate an existing infrastructure

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}