Azure Web Applications — IaaS Versus PaaS

programming hero img
In this post, I will explain the two ways that you can deploy a web-based application in Azure. One will be familiar to IT pros because it builds on the familiar infrastructure-as-a-service (IaaS) concept of networks, storage, and virtual machines. The other will be less familiar because none of those things will be used in the platform-as-a-service (PaaS) alternative.

This post is the result of a journey that I have started. How far I will get with this is unknown! I have started to learn the developer side of Microsoft Azure because my customers have started to move in that direction. I do not plan to abandon the infrastructure world because it will continue to play a big role. I need to stay with or ahead of my customers. Otherwise, my role as an advisor will be redundant. As IT pros, I think we all need to be advisors and therefore, I think we need to know the options.

IaaS-Based Web Service

If you are deploying a web service in Azure, then you are going to be deploying and enabling familiar concepts from the available Azure services.

  • A virtual network will be created with a subnet for each security zone.
  • Firewall rules in the form of network security groups will block or allow traffic into or out of each subnet.
  • Load balancers will be used to share services via load balancing or NAT rules.
  • Standard (HDD) and/or Premium (SSD) storage will be used to store virtual machine and log data.
  • Virtual machines will run Windows Server or Linux.
  • Web, application, and database services will run in the virtual machines.

One such architecture is shared below. It is from the collection of reference architectures that is published by Microsoft.

A Microsoft reference architecture for a virtual machine-based N-Tier web service [Image Credit: Microsoft]
A Microsoft Reference Architecture for a Virtual Machine-Based N-Tier Web Service [Image Credit: Microsoft]
As you can see, this is much more than a machine running IIS and SQL Server. Achieving high availability and scalability requires engineering work. Even with knowledge of the best tools, such as JSON, desired state configuration, Azure Automation, scripting, and more, skill and time are required to get this service online.

And let’s talk about the spend! I am in the business of reselling Azure, so more consumption makes my boss happy. But the above solution is going to cost a ton of money. Look at how much is required to enable the services to run. This is outside of the core features of database, application, and web hosting.

PaaS-Based Web Service

Let’s imagine that you are a developer. You are building an application that will be hosted in the cloud. Azure has been selected. All you care about is your application. Everything else is irrelevant. You do not know anything about networks, firewalls, Windows/Linux, storage systems, and all that stuff. More importantly, you do not want to know about that infrastructure stuff because your expertise is writing code. You are building a new service. You have been asked to either build the above architecture or that you will be given it to look after. This includes:

  • Windows and software updates
  • Replacing out of date operating systems
  • Managing SQL
  • Backing up or replicating virtual machines
  • And more

What does any of that have to do with developing or running an application? What if there was a way to run a website without running a web server? That sort of thing has existed for years. Hosting companies, such as GoDaddy, have been operating web hosting for a long time. Give them a few dollars a month and you can run your site on Windows or Linux without worrying about an operating system. I used to work for one such hosting company. I can tell you that while this sort of service is great for brochure sites, it is not something to build a business upon. There is no high availability, scale out/up is limited or non-existent, database services are limited, and there is no ability to process and consume data.
Azure PaaS offers the simplicity of web hosting. It comes with the power of application processing, data analytics, the potential of Machine Learning, or artificial intelligence if chrome cyborgs do not scare you, and more.
The Azure service fabric abstracts web services that are hosted in virtual machines. You tell Azure that you want to run a feature called a Web App. Azure provisions the virtual machine and takes care of everything else. All that is left for you is to configure the site settings, write your code, and get it onto the site. There will be no machines, firewall rules, operating system, or any of that distracting infrastructure stuff that can go so wrong.
Compare the below reference architecture for a highly available and scaled-out web app deployment in Azure. The below is comparable to the previous IaaS-based architecture:

  • The Web App for the website replaces the web servers.
  • The App Service Plan replaces the application servers.
  • The Azure SQL database replaces the database cluster.
  • Azure AD (or Google, Twitter, Facebook, etc) is used to authenticate users.

This much simpler architecture has also been optimized with a few extra elements:

  • Content Delivery Network (CDN) is geo-caching static content in every Microsoft data center around the world.
  • Redis Cache is accelerating database queries.

A reference architecture for a highly available Azure web app [Image Credit: Microsoft]
A Reference Architecture for a Highly Available Azure Web App [Image Credit: Microsoft]
It sounds like this super PaaS solution with the bells and whistles will cost more than an IaaS-based one. Not quite. A pair of load-balanced Web Apps will cost less than a single virtual machine alternative. The Azure SQL will cost a small fraction of the virtual machine + SQL Server alternative. The customer will have better performance and higher availability for an overall lower cost every month. More for less! Who doesn’t like that?

Which One?

I recently witnessed a pair of competing resellers go head to head. One went with infrastructure and one went with Azure PaaS. It was not even close to a fair fight. The reseller that had invested in skills won the contract and probably did so with much more margin going towards services. This is more profitable than infrastructure or licenses.
I understand the fear. PaaS is new stuff and it sounds like I will be telling you to install Visual Studio next. I will not. Even though, a dev can actually deploy and maintain their code entirely from Visual Studio without firing up the Azure Portal! I understand that PaaS is not for everyone. The fear of lock-in often drives customers to the more expensive and feature-poorer infrastructure alternative. Those features and lower costs are tempting and they are making a difference in business today.

I asked a bunch of Azure PaaS veterans for advice on how to expand my horizons into their hemisphere. Almost all advised me to start in web apps. I understand why. Most of us have deployed a hosted website at some point and this is a starting point. To be honest, there is tons more to Azure Web Apps and I am having fun learning about it. It is actually not hard. I have gotten some cool stuff working with little effort, such as code deployment, dev/test/production deployment slots, authentication via Google/Azure AD, scale out, and more. And I have not started Visual Studio once!