Our Journey with Service Fabric
In April 2015 Microsoft introduced Azure Service Fabric which was the high-scalable platform that was being used internally to run services such as Bing, Azure SQL DB and others.
Even before it was available, Codit started using Service Fabric to build applications for our customers and ourselves, one of those applications is Nebulus™ IoT. The applications are typically distributed, highly scalable and reliable; but building them was not a walk in the park. Service Fabric is a cluster technology which allows you to create a high-available cluster which replicates all the state across multiple nodes. At Codit, we always want to avoid managing clusters like these as we prefer to focus on the application and not the infrastructure beneath it.
While Azure Service Fabric is a PaaS offering of what we call Service Fabric Cluster where they provide you with all the machinery you need, but you are still in charge of managing the cluster itself. This is what I tend to call Cluster Platform-as-a-Service (CPaaS) and is very similar to Azure Kubernetes Service which gives me a managed Kubernetes cluster.
In the past year we’ve been working with Microsoft to streamline their offering so that you can just run your applications, not a cluster – Today these efforts will see the daylight.
Introducing Azure Service Fabric Mesh
As of today, Azure Service Fabric Mesh is in public preview and is a true PaaS offering which allows you to run applications on top of Service Fabric, without having to maintain the cluster beneath it. (official announcement)
Azure Service Fabric Mesh provides a serverless application platform which allows developers to deploy containerized workloads on top of it and only pay for what they are using. Because the underlying infrastructure is Service Fabric you can run both stateless and stateful applications which benefit from the state replication that is built-in Service Fabric.
The platform provides you the following capabilities out-of-the-box:
- No Infrastructure – Don’t worry about the infrastructure and focus on your application. Microsoft will do all the heavy lifting by managing the underlying cluster, handle infrastructure failures, no-downtime upgrades and more
- Containers – Applications should be packaged and shipped as containers – Either Windows or Linux containers. This makes Mesh a very flexible and portable platform where you can bring your existing applications as-is without code changes
- Intelligent Traffic Routing – Built-in support for Envoy which is an open-source edge & service proxy that allows you to use flexible traffic routing without having to change your application by using routing rules.
- Scalability – Capability to scale your applications both vertically and horizontally based on your needs. Applications will even benefit more from this elastic scaling later when auto-scaling rules are being added.
- Easy Deployments – By using the new Service Fabric Resources you can easily describe your containerized workload by leaving provisioning over to Mesh
Introducing a New Application Model
Service Fabric Resources are a declaration of your application and the resources that it required. This can be done in JSON or YAML and is very similar to a Kubernetes declaration.
Currently the following resource types are available and a few coming soon (*):
- Application describes which components your application uses and what Services that are part of this. These services can be running one or more containers, also known as code packages
- Networks connecting multiple applications and allows you to publicly expose endpoints that are part of your services
- Secrets can be used to reference secrets that are stored in external stores, such as Azure Key Vault, and can be used in your declaration
- Volumes allow you to provide an application agnostic way for persisting data to an external store such as Azure Files or Service Fabric Replicated disk
- Routing Rules (*) define how traffic should be routed
- Auto-Scaling Rules (*) define how services need to scale automatically based on a metric
The great news is that the new model is fully supported on all Service Fabric flavors – Service Fabric Cluster running in Azure, on-prem or any cloud provider but also in Mesh. This also allows developers to test their resource declaration locally by running them on a local Service Fabric cluster.
Personally, I’m a fan of the new model because this decouples your application from the way you will run it. This is important because you will have different needs depending on the environment that your application is running on in terms of scalability, routing, etc.
Another benefit is that you can fully decouple your application lifecycle from your application manifest which allows you to independently version, build & release these parts when they are ready.
Statefulness
One of the key differentiators for building applications on Service Fabric is statefulness, this is no different with Service Fabric Mesh.
Your application will be able to consume a NuGet package which allows you to use Reliable Collections inside your applications. When they are running on Mesh you can then use a Service Fabric Volume which will replicate your state across the cluster.
However, this means that existing applications need to be ported to this new approach.
Containers Are the Way Forward
To run applications on Azure Service Fabric Mesh they need to be packaged as containers. These containers can either be Linux or Windows based and can be stored in a public registry such as Docker Hub or a private one such as Azure Container Registry.
This enables customers to easily port their existing containerized workloads over to Service Fabric Mesh without having to change their application. This also means that when you start building applications for Mesh you do not have a vendor lock-in as it’s fully container based.
That said, if you are not using containers on Service Fabric Cluster it means that you will have a small migration period where you are wrapping your existing services in a Docker container. Depending on what these services do and the control they require this can be easy.
Azure Service Fabric Mesh is more than Service Fabric
Although the name might confuse you – Mesh is more than Service Fabric. Because Mesh is running on Service Fabric Cluster you can build applications that use the platform-specific features such as stateful, but it also means that it is using the Service Fabric Cluster container orchestrator.
If you have an application which is packaged in containers without any dependencies on Service Fabric you should still, consider Mesh over other offerings.
Is Service Fabric Cluster dead?
It’s a matter of control & responsibilities
Azure Service Fabric Mesh allows you to focus on your application without having to manage the Service Fabric cluster underneath it. Some people will really love this while others need the low-level control and would still prefer to run a Service Fabric Cluster themselves – Be it with Azure Service Fabric where Microsoft is managing the nodes or be it an on-prem cluster.
These products are aimed at a different audience and because of the parity between both products it allows you to very easily go from one to the other. This allows you to start with Mesh and learn the basics where you only go to Cluster if you need the additional control and want to invest in operating those clusters and running everything yourself.
Feature Parity
Another interesting aspect is that most Azure Service Fabric Mesh features, if not all, will eventually flow back in the other products so that you can run them on Cluster as well.
This model is very similar to how Azure SQL Database & SQL Server works – You can very easily test new features in the cloud and bring them to the other product if they are proven to be worthy and stable.
Application Manifest
Current Service Fabric Cluster users will also have noticed that the new resource model is very different from the “Application & Service Manifest” approach. That’s right because the old model was a description of the full application and was build as one package. This approach is certainly not going away but you will not be able to use it with Service Fabric Mesh.
However, as mentioned before, you can use the new Service Fabric Resources model and deploy your applications on any Service Fabric product.
Confused? Here is a full overview of how you describe your applications and run them on Service Fabric:
Introducing Containo – A reference implementation
The only way to really learn about new technology is to get your hands dirty. A year ago, I started with a small sample called Containo where I first dipped my toe in the container space to learn more about .NET Core, Docker and Kong which was a ton of fun.
Today I’m announcing the reincarnation of Containo – A container-based reference implementation available on GitHub.
The project will focus on a variety of topics:
- Building a microservices-based platform that is fully container-based
- Run on multiple container orchestrators – Currently Kubernetes & Azure Service Fabric Mesh
- Leverage a single API gateway which exposes internal capabilities – Currently via Kong
The goal is to have full parity on both orchestrators and highlight certain topics such as application composition, application packaging, scalability, operations, and more.
Conclusion
I am very excited to see Azure Service Fabric Mesh being added to the Azure offering. This closes a big gap in the current offering for Service Fabric developers allowing them to focus on the application and not the cluster. At Codit we have a couple of customers where they can benefit from this simplified model and only pay for what they are using.
Containers are here to stay, and everybody should start investing in building, packaging & running applications which are container based. There is no way around them anymore, they are everywhere and with Azure Service Fabric Mesh this is no different.
The introduction of the Service Fabric Resources is a great thing in my opinion because this fully decouples your application from how you will run them by shipping containers and describing how they should communicate, persist, scale and more without having to bake that in to the package.
But wait, doesn’t this sound like what Kubernetes and/or Azure Container Instances are offering already? Yes and no, we will dig deeper in this in a follow-up article.
I would like to thank Mark Fussell, Chacko Daniel, Matthew Snider, Mikkel Mork Hegnhoj and the rest of the Service Fabric team for taking our feedback and turning it into a great new product and the great collaboration we had during the private preview.
Thanks for reading,
Tom.
Subscribe to our RSS feed