Exploring Windows Azure Execution Models: IaaS
The Cloud Zone is brought to you in partnership with Iron.io. Discover how Microservices have transformed the way developers are building and deploying applications in the era of modern cloud infrastructure.
“Execution Model” is a fancy term for describing how and where your application runs. Microsoft’s Azure platform explicitly supports three different execution models that allow you to take varying levels of control over the environment that your application is hosted in. These levels vary from what I like to call a “bare metal” implementation where the user is responsible for everything but the hardware that the application runs on to a nearly hands off approach that lets Azure take care of most of the dirty work. Which you choose is completely up to you and should be determined on a case-by-case basis.
Many users will opt for the Infrastructure as a Service or IaaS “bare metal” approach. With this approach you are in complete control of the environment in which your application runs. This may be good for some use cases but this freedom is a double-edge sword as you are responsible for everything from patching to scalability. While Azure does offer a number of value-add features out of the box such as hardware monitoring and optional load balancing the bulk of the responsibility is on you. This isn’t necessarily a bad thing, though. Microsoft gives you complete control over the virtual machines you use allowing you to either build a VHD from scratch, upload one or choose from their gallery of boilerplate VHDs that include several CentOS and SUSE Linux builds. You know, if you’re into that sort of thing.
What’s even more interesting is that since Azure’s virtual machine approach is based on the widely accepted VHD format you can bring your VMs with you. This has the added bonus of allowing you to download VHDs from Azure and run them locally. That is, of course, assuming that you have all of the necessary licenses. This portability is a major bonus because it doesn’t lock you in to one platform. It also lets you standardize and version if you have VMs that run on premises as well as in the cloud. In contrast Amazon’s EC2 platform ties you down to the proprietary AMI (Application Machine Image) format which requires third party utilities and/or substantial time at the console to move to and from the cloud.
If you pick from one of Azure’s VHD gallery machines you don’t need to concern yourself with licensing for Windows, SQL Server, etc… it’s rolled right into your Azure account. Speaking of cost, you are only charged for the time that your VMs are up and running in this model. This isn’t CPU time… this is the actual time that your VM is up and running so you still need to be cautious.
VMs that run within Azure can be grouped into logical containers called cloud services. A cloud service lets your expose a single public endpoint to the rest of the world and load balance requests between the VMs that are up and running in that group. This is great for scalability since you can easily bring up or shut down VMs from the same image to handle fluctuations in traffic. Be careful not to confuse this with the identically named cloud services feature of Azure that is actually a more hands-off Platform as a Service or PaaS execution model that I’ll dive into in a future blog post.
If you’re looking for a hands on execution model that lets you be in complete control but bear the administrative responsibility of your environment then Azure’s IaaS approach is probably what you’re looking for.
It’s important to note that this is the most hands on model explicitly supported by the Azure platform. Another model would be to run all of your applications on-premises and simply consume other services provided by Azure as needed. For example, most of Azure’s storage services including blob, table and queue access can be consumed by any application regardless of where it’s hosted be it in within or outside of the cloud. The cool thing is that if you host your application within a VHD then moving the application to and from the cloud is relatively trivial. You may even choose to take a hybrid approach where you have some components of your application that are running in the cloud and some that are running outside of it. There’s nothing wrong with that and is actually a rather popular approach to take.
If you’re interested, you can try it out for free. This is a 90-day trial and entitles you to 750 small compute hours per month. Look for my next execution model post soon where I’ll dive into Azure’s SaaS (web sites) execution model. Until then, stay cloudy!