Freigeben über

Choosing between Azure Container Service, Azure Service Fabric and Azure Functions

  • Artikel

Recently concluded Connect had a very important session on the topic of Building Microservice Applications with Microsoft Azure.

It was great to see PMs from 3 teams to come together and discuss questions that have been on the developer's minds for long time.

This post is summary of my impression of the dialogue.

Azure Container Service (ACS) provides a bridge between Azure and existing containers ecosystem. It lets developers manage underlying infrastructure (VMs, Storage, Load Balancing, etc.) separately than the application.  It offers developers to select from 3 major container orchestrators available today i.e. (DC/OS, Swarm and Kubernetes). It collaborates with the the container ecosystem to contribute towards promise of application virtualization. It simply offers a glue between infrastructure and your favorite container orchestrator.

ACS focuses on smaller services. You can start with container-izing a monolith. It can be then gradually broken down into multiple smaller services. This process of breaking down large monolith into smaller services in entirely under control of application architect/developers. ACS gives that flexibility to development team. ACS is content with a containerized application regardless of what application is written or how it is written.

So, ACS is primarily about Azure Infrastructure and an orchestrator!

Azure Service Fabric on the other hand, is more about just Azure Infrastructure and orchestrator. It is neutral on infrastructure. That's why it can run on premise as well as on any cloud (including AWS and Azure).  This is a great option for teams who are looking to build an application using microservices architecture on premise. When the decisions on whether to move to cloud and which cloud are finalized, they simply port the application from on premise to cloud.  Unlike ACS, Service Fabric provides a prescriptive guidance on how application should be written. It provides a full blown programming model. This model proposes either Reliable Services or Actor Model to write application. Application written using this programming model, can either be stateful or stateless. It is more fault-tolerant and easy to scale. Multiple such services forms a microservices architecture based application. It gives more control (and ownership!) of the underlying infrastructure to developers.

Regardless of whether Azure Container Services or Azure Service Fabric is selected, as application architecture evolves and as these microservices are decomposed further and further, they are reduced essentially to a single function. This is where Azure Functions comes into picture.

Azure Function evolves from WebJobs, which are part of App Service. They are great in executing some logic either in response to a trigger or on a pre-defined schedule. They have a simple programming model that doesn't need elaborate infrastructure set up. That's why they fall into Serverless computing category.

So how do you make a decision?

Azure Container Service: If you are looking to deploy your application in Linux environment and are comfortable with an orchestrator such as Swarm, Kubernetes or DC/OS, use ACS. A typical 3 tier application (such as a web front end, a caching layer, a API layer and a database layer) can be easily container-ized with 1 single dockerfile (or docker-compose file). It can be continuously decomposed into smaller services gradually. This approach provides an immediate benefit of portability of such an application. Containers is Open technology and there is great community support around containers.

Azure Service Fabric: If an application must have its state saved locally, then use Service Fabric. It is also a good choice if you are looking to deploy application in Windows server ecosystem(Linux support is in the works as well!). Refer to common workloads on Service Fabric for more discussion on applications that can benefit from Service Fabric. Biggest benefit is that Service Fabric applications can run on-premise, on Azure or even in other cloud platforms also.

Azure Functions: If an application needs an HTTP endpoint for a potentially long running  process without getting into a elaborate programming model, Azure Functions is a good option. They can be developed as an extension of an existing application. They support routing based endpoints similar to an API. They support AAD and other authentication, SSL, Custom Domain, RBAC, etc. They have a good CI/CD support as well. They are in the process of integrating .Net Core support. So if you are looking to get a simple application model and don't want to get into setting up/managing underlying infrastructure, Azure Functions is good choice.

Comments

  • Anonymous
    November 28, 2016
    Thanks for the details Mahesh. Could you also help with typical use cases covering these three aspects