Containers, Azure and Service Fabric


Today I will try to gather some explanations about containers, how they are implemented or used on Azure, and how this all relates to micro-services and Azure Service Fabric.

First let’s share some basic knowledge and definitions.


Containers in a nutshell

To make a very long story short, a container is a higher level virtual machine. You just pack your application and its dependencies in it, and let it run.

The good thing about those is that you do not have to pack  the whole underlying OS in there. This gives us lightweight packages, which could be around 50MB for a web server for example. Originally, containers were designed to be stateless. You were supposed to keep permanent data out of those, and be able to spin out as many instances of your applications to run in parallel, without having to bother about data.

This is not completely true about most deployments. Today many containers are used as lightweight virtual machines, to run multiple identical services, each with its instance.

For example, if you need a monitoring poller for each new customer you have, you might package this in a container and run one instance for each client, where you just have to configure the specifics for this client. It’s simple, modular and quick. The stateless versus stateful containers is a long standing one, see



Just like in virtualization, the case is mostly not about the container technology and limits, but rather about the tools to orchestrate that. Vmware vCenter versus Microsoft SCVMM anyone?

You may run containers manually above Linux or Windows, with some limitations, but the point is not to have a single OS instance running several services. The point is to have a framework where you can integrate that container and instantiate it without having to tinker with all the details : high-availability, load-balancing, registration into a catalog/registry etc. The video below is very good at explaining that :

The Illustrated Children’s Guide to Kubernetes

There are several major orchestrators in the field today. Kubernetes is the open-sourced one from Google’s own datacenters. It has gained a lot of traction and is being used a many production environments. DC/OS is the one based on Apache Mesos, which has been pushed a lot by Microsoft. It uses Marathon as the orchestration brick. And of course Docker has its own orchestrator : Docker Swarm. I will not go into comparing these, as there is a lot of content on that already.


Containers on Azure

As you can do on-premises, there are at least two ways to run containers on Azure. The first is simply to spin of a virtual machine with a container engine (Docker engine, Windows Server 2016, Hyper-V containers…) and start from scratch.

The easy way is to use Azure Container Service, which will do all the heavy lifting for you :

  • Create the needed controller VM(s) to run the orchestrator
  • Create the underlying network and services
  • Create the execution nodes which will run the containers
  • Install the chosen orchestrator

ACS is basically an automated Azure Resource Manager (ARM) configurator to deploy all of this simply.

You have a choice of the orchestrator you want to use, and the number of nodes, and voilà!


A bit anti-climatic, don’t you think? I have to disagree, somehow. I do not think that the value of IT is in installation and configuration of the various tools and frameworks, but rather in finding the right tool to help the business/users to do their job. If someone automates the lengthy part of that installation, I’ll back him up!

A note on pricing for these solutions : you only pay for the storage and IaaS VMs underlying the container infrastructure (controllers and nodes)



If you really do not want to handle the IaaS part of a container infrastructure, you can get a CaaS (Container as a service) option from the Azure Marketplace. This solutions will be priced specifically, with a platform cost (for the Docker Engines running on Azure) and a license cost for the product ( With that you get all the nifty modules and support you want :

  • The control plane (Docker Universal Control Plane)
  • Docker Trusted Registry
  • Docker Engine
  • Support desk from Docker teams


Azure Service Fabric and Micro-services

I will not go deep into this subject, it deserves a whole post into itself. However to complete the subject around containers, let me say a few things about Service Fabric.

Azure Service Fabric will be able to run containers, as a service, in the coming months.

The main target for Azure Service Fabric is more around the development side of micro-services, in the meaning that it is a way of segmenting the different functions and roles needed in an application to render the architecture highly adaptable, resilient and scalable.

Mark Russinovich did a great article on that subject :



One Reply to “Containers, Azure and Service Fabric”

Leave a Reply