This question comes up very often at conferences and forums. The answer, as you might have guessed, is “it depends…”
In this blog post, however, we will go beyond “it depends” and try to describe some factors that can help you choose between Azure PaaS offerings.
Let’s gets started. We will cover the following Azure PaaS offerings:
Azure Functions (AF) – This is a serverless compute option. AF allows you to write small pieces of code (in a variety of languages) and let Azure worry about running them (or even scaling them as needed).
Azure Service Fabric (ASF) – This is a distributed platform to package, deploy, and manage scalable and reliable microservices.
App Service Environment (ASE) – This is a premium service plan for Azure App Service that is fully isolated and dedicated. It retains all the benefits of Azure App Service including multiple language support, DevOps integration, seamless scaling and compliance.
Azure Container Service (ACF) – This is a service that allows for creation, configuration, and management of a cluster to run containerized applications. ASF currently supports the following orchestrators: DC/OS, Docker Swarm and Kubernetes.
In the table above, I have “ranked” (green, orange and red) the aforementioned Azure PaaS options against a set of criteria (described below). Note that the “rank” should not be misconstrued as good or bad. These criteria may or may not apply to your target application.
Ability to customize the guest OS: Even though by definition you are not managing the guest OS when dealing with PaaS, you may still want to customize the guest OS in some cases. For example, you want to install monitoring agents like Splunk, install custom certs or set the date/time zone on the guest OS. AF and ASE offer the least amount of ability to customize the underlying OS. This should come as no surprise, as AF and ASE abstract most of the platform details (leaning strongly towards productivity in a productivity-versus-control split). ACS and ASF allow options for OS customization and hence get the orange designation. VMSS gets a green because it is closest to the IaaS tier and thus it offers the most flexibility to customize the guest OS.
Management overhead: Management overhead pertains to patching the guest OS, managing the health of the virtual machines, etc. Once again, ASF and ASE come with minimal management overhead since all of the underlying infrastructure is abstracted from you. ACS and ASF sit on top of VMSS. So it is currently your responsibility to manage the underlying OS including patching. ACS and ASF get an orange designation, because they have the built-in capability for cluster management. Additionally, ASF recently announced automated OS patching. VMSS gets a red designation because it requires the most management.
DevOps Integration: This criteria pertains to CI & CD integration (VSTS, GitHub etc), monitoring support (AppInsight, Splunk) and richness of CLI capabilities. Azure App Service has been around the longest and has the most mature CI/CD story. You can setup CI & CD directly from the Azure Portal. Additionally, multiple deployment slots, load testing, and Testing In Production (TIP) features are built-in. All of these capabilities earned it the green designation. AF, ACS and ASF all have a robust CI & CD story, earning them an orange designation. The recent AF-related announcements at BUILD have greatly improved its DevOps story. CI & CD is already well established for containers. ACS has added support for VSTS and multi-container deployment via Azure Container Registry. In addition, CI & CD support for Jenkins is also available. ASF also has CI & CD support via VSTS. VMSS gets a red designation mainly because there is no OOB CI & CD story. That said, WebDeploy and VM Extensions can be used for CI & CD with VMSS.
Fine-grained cluster management: This criteria is about the ability to have a fine-grained control over the cluster. ASF offers the ability to specify fine-grained control of rules that govern how your services are deployed on a cluster. This criteria does not apply to AF and VMSS. ASE gets a red designation because there is limited ability to control how services are deployed to the underlying worker pool. ACS gets an orange designation because of the orchestration capabilities it inherits from supported orchestrators DC/OS , Swarm and Kubernetes. Clearly DC/OS and Kubernetes are well-established orchestrators with advanced advanced features like container placement, container scaling, resource usage monitoring and health checks. ASF gets a green designation because it goes beyond the orchestration capabilities and offers an “opinionated” way of building microservices by including a programming model, support for state management and chaos testing. Additionally, ASF is increasingly supporting Docker constructs natively including recently previewed support for Docker compose. In general, Docker support across Azure PaaS options is growing.
Compliance: As the name suggests, this criteria is about the compliance certifications available for each service. ASE is ISO, SOC, and PCI compliant. VMSS is PCI compliant. ACS and ASF sit on top of VMSS and as a result, inherit its PCI compliance. AF, given that it went GA at BUILD does not have a compliance story yet.
Code Refactoring: This criteria pertains to code refactoring required to move your existing non-PaaS hosted application to Azure PaaS. Once again, I am not passing a judgement on whether green is good or bad. I am simply commenting on the effort involved in moving an existing application to Azure PaaS.
AF, because of its nature, will require the biggest change to application architecture (although not to all the application constructs; for example, stateful services or long running transactions can be met by AF). VMSS and ASE get a green designation because existing applications can be migrated to these services with minimal refactoring. ACS and ASF require you to think about refactoring to microservices. You have think about repacking your applications into smaller packages and containers. Next, you also have to think about refactoring the code by splitting coarse-grained web services into smaller units or wrapping controllers into domain objects. Finally, think about refactoring the data structures.
In summary, as we have seen through the discussion above, we have a rich set of PaaS options on Azure that give us choice across the productivity-versus-control split. Even though the criteria we discussed in this blog post are not exhaustive, hopefully this discussion gives you a framework for selecting the Azure PaaS option that best fits your needs.
Image Copyright: 3dlabs2015 / 123RF Stock Photo