The Platform-as-a-Service (PaaS) hosting model in Azure has come a long way since it was launched years ago. (If you’re unfamiliar with the term PaaS, it refers to managed services where cloud providers manage most or all of the infrastructure needs of a system and developers just supply the application code or assemblies instead of managing virtual machines and operating systems. Check out our training at www.opsgility.com to learn all about this). Without rehashing the full history of the Azure PaaS story here, it all started with a model called “cloud services”. In that model, developers could create .NET applications that were designed to run specifically on managed Azure virtual machines, either with or without the IIS web server. Basically, each component of an application would run as a separate service and could be scaled to whatever number of instances was appropriate. This model wasn’t nearly as flexible and agile as the options available today, but it did have one important benefit in that it worked very well for both large and small applications. If a developer only needed one extra-small virtual machine instance for his or her app, and maybe one more instance for availability, that was fine. Likewise, if a developer wanted 50 instances for a front-end and 25 instances for a back-end service, that was fine too.
Alright, so fast forward to today. “Cloud services” is gone and in its place are a variety of new, more specialized, options. There are now separate models for hosting web and mobile applications, event-driven serverless applications, orchestrated container and microservices clusters, event-driven workflows, and so on. With all of the great new options available, there is one frustrating gap in the spectrum. What if a developer just wants to host a small back-end service on one, or maybe two, dedicated servers in a PaaS model? In other words, what is the story for apps that are too “big” (or just not a good fit) for serverless hosting but are too small for a 5 node dedicated virtual machine cluster? There just wasn’t a good answer here. Granted, the developer could always just manually host an app on virtual machines, but then all of the benefits of PaaS are given up and the developer has to manage the operating system and failovers manually. Here is a graphic to illustrate the options and the gap in the middle.
So we’ve established the problem, and finally we have a solution! Most applications can be effectively containerized without any architectural changes. Container hosting options are not new to Azure, but until now the only option was to create a cluster with an orchestrator (docker, DC/OS, kubernetes, or service fabric) where the containers could be deployed. A cluster is great, but it is overkill for a single container instance (a single small application). Enter Azure Container Instances and now here is a service where a developer can create single instances of containers and have them run, individually, without having to provision and pay for a full cluster. This effectively fills the PaaS gap and gives developers the option to start small and easily move up in size if necessary. I am personally very happy with this new option and will be recommending this to customers as a great solution for those small services that most software solutions end up having. The completed graphic is below.