Is Azure Service Fabric still relevant in 2020

This is a question that comes up very often today - is Azure Service Fabric still relevant in 2020? Is it dead? Is is dying? Is Microsoft investing in SF or is it slowly going downhill day by day? I'll try to answer those for you here.

Why Not Kubernetes?

Kubernetes is huge today. It's a winner win in terms of building scalable infrastructure. There's nowhere to look further if you are thinking of building scalable solutions. It's architecturally beautiful, it's open-source, there is a huge community around it (way way bigger than Service Fabric). It's backed by Google - defintitely a leader in building scalable infrastructure and data centers.

Kubernetes has evolved massively, there are numerous products to support it, loads of companies have built their products running on top of it, and it's supported by all the major cloud providers out of the box.

What's Special About Service Fabric?

Service Fabric is definitely not dying. In fact, it's evolving. The other thing is, it's evolution is not as public as other alternatives, but there are reasons for it.

First of all, SF came out of Microsoft as it's internal product. SF powers Microsoft Azure. Most of the Azure services in one way or another run on top of Service Fabric. This includes Cosmos DB, Event Hubs, Service Bus, SQL Server, Azure Functions just to name a few you definitely know. Even some parts of Kubernetes' Azure offering (AKS) run on top of Service Fabric. That's funny, considering AKS is supposed to be an alternative platform. Even Azure Container Instances which are lightweight ways to run containers in the cloud without the need of a heavy orchestrtor, are powered by SF. Almost everything is.

The difference between Microsoft and other cloud providers, is that Microsoft has made it's core framework (SF) available to the public, and later made it open-source so you can be sure solutions you are building are not locked in to one vendor (Microsoft), you can better understand how the product works, and contribute to it if you're brave enough!

The other thing is, Microsoft doesn't really care if SF is popular enough or not - this doesn't change anything in terms of raw income:

• Microsoft Azure does and will be powered by SF platform, because there are no better alternatives.
• It doesn't cost Microsoft anything to keep SF available to the public, because they are working on it to power their biggest product (Azure) anyway.
• All the documentation, GitHub code repository and so on are tax free - they need to be up to date for internal employees anyway.

Superior Architecture

In terms of architecture, SF (at least in my opinion) is way more superior comparing to the alternatives (read K8). I'll can rant how ancient K8 architecture is, but here are main points:

• 🩲K8 is really a heavily centralised architecture, it's not as distributed as you may think. It has API server in the middle and agents called Kubelets installed on all worker nodes. All Kubelets communicate with API server, which keeps the state of the cluster persisted in a centralised repository - etcd cluster. To maintain cluster membership information, all Kubelets are required to maintain connection with the API server and send heartbeats every period of time. In addition to being not great in terms of design, more nodes in a cluster mean increased traffic and more load on central API server, which is not great.
• 🕸Service Fabric is fully decentralised. SF is designed to be fully distributed, all nodes are organised in a ring and heartbeats are only sent to a small subset of nodes called the neighbourhood. The arbitration procedure is only executed in case of a problem like missed heartbeats, which significantly decreases the traffic and potential network congestion issues, as the traffic is evenly redistributed across the cluster. This means there are no central services on special nodes - even "central" core services run on any node and have the same privileges as user applications.
• 👾Service Fabric recovers from failures instantly comparing to K8. By default, due to it's centralised nature, K8 will need around 5 minutes to determine that a node is dead. This is fine for stateless workloads, however for stateful services this can lead to potential disasters. SF tries to detect dead nodes ASAP, 5 minutes is unacceptable. On average, a dead node is detected within 10 to 15 seconds. What does this mean? Well, if you are running an eventually consistent database or storage service, K8 will be just fine, however for strong consistency it's simply not suitable and you need to go look elsewhere (SF, it runs SQL Server!).
• 💾K8 does not have state. This is one of the biggest points in SF architecture - state is available to any microservice, and it's realiable, replicated, and extremely fast. K8 simply does not have state - if you need to store data somewhere reliably, you need to either use external volumes, or an external database server. External volumes are risky as they introduce a single point of failure, and are generally slow. External databases is a good choice, however they have issues too - network latency, slow comparing to SF local state, and there is a good chance that that external database will be actually powered by Service Fabric 😅

Is It Safe To Go With Service Fabric?

Yes and no. If you need to make that decision, consider the following:

• 🏘Do you need to run on premise? If you do, SF currently has no support for Linux clusters on premise, only Windows. To run on Linux, you need to be in Azure. However, if your primary workloads are on Windows it doesn't really matter.
• ☁Are you multi-cloud? If yes, then keep in mind that SF can run on other clouds as well, there is even an official guide how to install it on AWS (GCP and others are quite similar in procedures). However, only Windows workloads are supported. You need to be in Azure to rent a linux cluster.
• 💰Is cost important to you? Generally speaking, SF is cheaper to run comparing to K8, because it can pack more services on one node due to it's capabilities to run multiple types of workloads. You can also utilise native Azure services, and quite often pay nothing for storage (don't need external databases as storage is built into SF). In addition to that, SF requires much less staff to program for and support ⌨. In essence, a lot of services that you need to build yourself with K8 are already part of SF.
• 🚅Is performance important? SF is usually more performant that K8 due to it's decentralised architecture, low traffic requirements, faster storage access and unique programming models.
• 📰Is this a new project? If you are planning a new project, SF may be beneficial for you, as learning curve is way shorter compared to K8. Even for junior developers Microsoft has a great story - all of the operations can be performed visually and there is an ultimate excellent experience both in Azure and development tools, especially Visual Studio.
• 🛒Are you a Microsoft .NET or Java shop? If you are using .NET or Java you can benefit from deep integration with SF services, to the lowest core possible, and utilise the full power of this platform. You can still use any language and any platform, but the support of them is equal to K8.
• 📦Are you using containers? If you do, you must know that SF fully supports containerised applications just like K8 does. There is no awkwardness about this, or cut-down functionality. In fact, it's easier to deploy a container to SF.
• 👨‍👩‍👧‍👦Do you need to mix containers and non-containerised workloads? If you do, SF is a perfect choice. Running applications in container is optional, but fully supported. In addition to containers, you can just take any legacy or new application as is and run it in SF - scalability, reliability, recovery etc. will be enabled on top with no changes. You can also run containers. You can write something called Native Service Fabric applications, those that utilise it's fully power.
• 👩‍👦Do you need to mix Windows and Linux? One of the features of SF clusters is that you can run both windows applications/containers and linux applications/containers in one cluster. In any combination, with no restrictions. Is this imprtant? No other platform other than SF offers this.
• 🔑Are you against vendor lock-in? If so, stop reading this and go away 😆 But seriosly, vendor lock-in is a myth. Even by going with K8, you are not transferrable amongst clouds - it's just your IT Ops need to fully rebuild infrastructure in another cloud, and developers need to re-test their applications in another K8 instance, potentially fixing a lot of bugs. Vendor lock-in can be only avoided by properly designing your application from ground up. But seriously, SF doesn't add that many requirements that your application can't be ported to another cloud with ease.
• 👩‍💻Do you care about your developers? If so, go for SF. It has amazing tooling, great developer story, very short time-to-market number, and is a pleasure to work with.

Great Developer Story

It's truly great. There is virtually little to none learning curve. Your developers can get an application running in SF on day one. Microsoft has made a lot of effort to make it right - first for internal employees, then for YOU. There is a good course on Service Fabric for developer on Pluralsight to get them started as well.

The other massive win is that SF does not require a lot of IT Operations to babysit your cluster, because most of the modern microservice related architectures just work our of the box. If you need to customise them, again, it's not complicated and fully covered in this Pluralsight course. This doesn't mean, of course, that you can fire all your IT Ops team. Of course there is much less staff required, but you can also contcentrate on important parts of your infrastructure, rather than babysitting your K8 cluster and adding bits one by one which already exist in SF, are battle tested, created by someone else, and you have free SLA for it!

One of the biggest things in SF after Stateful Services, is that it also has built-in support for Actor Model! And programming it is also a pleasure.

Can I Trust Service Fabric?

I would. Simply because it's a proven platform. The biggest customer is Microsoft itself, and the biggest product is Microsoft Azure. Do you like how reliable Azure is? Go SF. There are some other customer stories you can read but this is just a top of the iceberg. I've worked for some massive clients that don't need any introduction, and they are happy about Service Fabric 😎

Why Don't I Hear About Service Fabric As Much as Kubernetes?

Because of people's factor. The crowd is always leaning towards something popular, with big adverts, slogans, mottos, vendor and so on. If I'd say I love VB you'd probably laugh at me (I actually don't 😁) however VB is perfect for many applications. There is also a lot of nagative history concerning Microsoft and the trust is probably not fully there. Although this has changed a lot recently, it's still not quite there. Only open mindness and ability not to blindly follow the crowd because it's so popular can change that. More popular is not always better.

This post was originally published on IsoLine Ltd Blog