Opsview comes with 23 Azure Opspacks to quickly get your company monitoring your Azure infrastructure and applications.
You are here
Moving your App to Azure PaaS: How to choose between PaaS and IaaS
In this article, I intend the explore the options you have in transitioning your business application to Azure. I will look at what you might expect to gain by exploring the hosting options on both Azure’s Platform as a Service options (PaaS) or their more traditional Infrastructure as a Service offering (IaaS). This is a choice many organisations are making when it comes to designing new applications or services.
What are we talking about with Azure Paas or IaaS?
Infrastructure as a service or IaaS. Which is essentially having the raw compute managed and being provided a VM without needing to worry about managing the infrastructure that is providing this VM. Often IaaS providers will offer services around raw compute to make the provisioning or scaling of platforms easier.
For example, Azure offers this as Virtual Machine Scale Sets that permit metric-based scaling for your platform as well as ‘near infinite scale’ services to support this such as Load Balancers, or the ever useful identify and access management services like Azure Active Directory.
Where PaaS differs is that it places the responsibility of managing and scaling the infrastructure beneath your application. This removes most of the day-to-day responsibility of managing the platform that delivers your application and changes many of the costs to ‘as consumed’ rather than for the compute you use (which may be under-utilised or over provisioned). On-top of this, if you choose to use Azure’s AppServices you are then able to use tools like Application Insights to start getting granular insight through deep application performance monitoring.
Azure App Insights
Understanding your choices
Both PaaS and the more traditional IaaS come with their own positives and negatives. The selection between the two really depends on your appetite and attitude towards the workload you are moving. If it’s just a “lift and shift” of your existing application, stop reading and deploy your app on IaaS after reviewing the reference architecture from Microsoft for N-Tier applications. The potential issue with making changes this way is that you may bring problems from your previous deployment into your new deployment, for example a requirement to scale up rather than out or single points of failure can all be brought over.
Conversely, making the move to a PaaS platform will almost certainly require changes to your application. In many cases this will be in the form of re-architecting your application to be more reliant on Azure App Services rather than than just your standard hosting builds. You will also be becoming more reliant on cloud only services such as Azure Service Bus to handle inter-app messaging, for example. These services may make it harder to transition away from your current cloud architecture in the future. However, the trade-off between having to write your application for the platform (and thus re-write it when you change platform) and having to spend a lot less time trying to address technical scaling and availability is worth it. It’s easier to frame with the question ‘would you rather invest time in one block every time you change platform or spend time on regular maintenance’.
When choosing between the two options it is important to keep costing in mind too. PaaS pricing is almost always a true ‘as you use it’ pricing rather than the stepped increments that IaaS provides when having to scale per VM.
With all this you can also explore other PaaS options such as functions and move towards a true ‘server-less’ architecture looking at elements such as Azure Functions to allow for far easier scaling. You may even consider Azure’s Deployment/Continuous integration options to let you transition to a more DevOps centric focus which makes shipping new versions a snap.
What would my Azure PaaS application look like?
For a traditional IaaS or on-prem consumer PaaS can be hard to visualise so it’s worth taking the time to sketch out how your application might look as it will help you get more comfortable with the level of detachment you will need when it comes to the infrastructure. For inspiration Microsoft provides a series of reference architectures here.
The nice part is that whatever you choose you can still easily monitor it with Opsview's new Azure Opspacks. You are able to monitor the major services offered by Azure without the need for any agents, keep track of difficult metrics like DTU usage on your hosted SQL databases and best of all, our generic collection framework allows you to quickly write your own checks. We also offer a series of integrations to allow you to rapidly collect metrics from your public cloud deployment without any complex setup requirements. Opsview’s API allows you to provision monitoring as you deploy platforms too! Try Opsview for free.
More like this
So, last Friday night, I decided to turn my infrastructure into code by learning Ansible, and capture the entire demo configuration.
When choosing an Enterprise monitoring tool there are many considerations, but one that is almost always right at the top of the list is...