Recently I have investigated container orchestration solutions on Azure. The main competitors in this area are Azure Kubernetes Service and Azure Service Fabric. Both have their place, advantages and downsides. This is a small smackdown of those two based on my research and experience with Kubernetes. Unfortunately I have not had practical experience with Service Fabric so far. Please let me know your thoughts in the comments section. Let’s start then.
Kubernetes
Although I am focusing on the upstream Kubernetes, most of these points are also valid for Azure Kubernetes Service (AKS).
The good parts
Everything is customizable
You would like to use Haproxy instead of Nginx as your reverse proxy and load balancer? No problem. Just grab an appropiate helm chart and install it into your cluster. The list of Kubernetes addons and extensions is endless. They run directly on the cluster and are usually managed by Kubernetes as any other service.
Stability
Kubernetes is very stable. I’ve been running production workloads with low-to-average load for almost half a year now without any problems. Some services are running for all this time without even restarts. The Kubernetes itself is very stable and does its job very well in keeping the services alive.
The bad parts
Very steeep learning curve
In order to start with Kubernetes, both cluster admins and cluster users must learn a big dose of new stuff before they can be productive with those new tools. Docker is just on top of the iceberg that you need to learn about before you can deploy with confidence.
Complexity
Kubernetes introduces a lot of complexity to your systems. Use it only when there is a good reason to do so. If you have less than a dozen of services, probably you don’t even need a container orchestrator. Always make a good case, so that you are certain, that the advantages of Kubernetes outweights its complexity and difficulties.
Azure Service Fabric
The good parts
Good support for .NET framework
If you have a lot of applications that use full .NET framework, you can very tightly integrate with Service Fabric, as it provides developers with integration library. The library provides you with programming models and primitives that you can build on top, in order to leverage the platform better. There is even a special library that you can use to develop applications based on Actor Model (Service Fabric Reliable Actors).
Supports lift-and-shift strategy for legacy .NET stack
If you have a ton of legacy and want to move to the microservice world, you can bring your old .NET services directly to the Service Fabric cluster. By doing that, you can leverage a single infrastructure for all your services, which makes it easier to manage and migrate software to a new stack.
The bad parts
Still very complex
Service Fabric is at least as complex as Kubernetes. Container orchestration is a difficult topic, and whether you use Kubernetes or Service Fabric, there is a lot to learn. Apart from that, only microsoft provides support and documentation for Service Fabric. Despite the fact that Service Fabric is now open source, the amount of support from the community is nowhere near the one that we see with Kubernetes.
Contrainers are second-class citizens
Service Fabric focuses on running applications that use the .NET or Java libraries provided by Microsoft. Those applications are tightly integrated with the platform and the programming model provides a lot of benefits for those services. Containers, though, are run as „guest” workloads and cannot benefit from the same features as native .NET applications. For those kinds of workloads, Kubernetes might be a better choice.
Final remarks
Those are only my random thoughts on the differences between Kubernetes and Service Fabric that I have noticed. Both solutions are available on Azure and both have their upsides and drawbacks. However, I did not try to compare them as apples-to-apples as those services provide different things. Remember that Service Fabric is much more complete solution for hosting applications. It requires many more components to be installed onto Kubernetes before we can have a proper comparison. Probably the better way to compare these two would be to take OpenShift Origin or other complete solution based on Kubernetes.
It is also worth mentioning, that both Azure Service Fabric and Azure Kubernetes Service do not have a cluster-level SLA. This means that Azure provides an SLA only for the underlying machines, without giving any guarantees on the cluster stability itself.
Both of those solutions require a lot of knowledge and expertise. The alternative is to look at SLA-backed services that make sure your cluster is running. However, if you can go along without using container orchestrators, you probably should.
Kubernetes is many times bigger in terms of community, support and companies that are using it. There is a high chance that at some point Microsoft will kill Service Fabric and go with the solution developed on top of Kubernetes.
I hope that those notes will help you make the decision about whether to use Service Fabric or Kubernetes in your next project. You can always drop me an email or just leave a comment below in case you want to share your experience with either of those.