TL,DR: Anyone who experienced the Microsoft culture from a few years ago could never have imagined seeing Microsoft supporting a solution (Kubernetes) created outside of its premises, with same enthusiasm they have for their own products. It’s understandable if the old Microsoft culture still reigns within the company, could its attempts to impose its own products above anything else have an effect on a trend driven by the open-source community?

Over the last few years, the term Microservices has skyrocketed, and a question raised is always around the tooling to support them. New tooling appeared claiming to support the development of microservices, but when the scope is about deployment and orchestration, very few solutions provide clear patterns or have proven to be ready for massive scale. Kubernetes and Service Fabric are the two most often discussed solutions that stand out among the others.

In a recent interview on Cloud Native, Jason Zander, a Microsoft Executive Vice President, said:

“We love Kubernetes, but it’s playing catch-up with our Service Fabric”‍

... but in what areas is Kubernetes catching-up?

Kubernetes and Service Fabric are built on top of solutions that have been around for a while, way earlier than the term “Microservices” became a popular topic.

Service Fabric roots date back to 2001, it all started with the goal of delivering a worldwide multimedia platform to support the management of globally connected home devices and video streaming services like security footages and personal media, similar to what people know today by the names of YouTube, Netflix and IoT. At a time where a trend of smart devices like Xbox, PCs and other gadgets could be interconnected to provide a better user experience, the team saw the bigger potential and made it a general-purpose platform. This Microsoft team started what would later be the foundation for many Azure PaaS offerings such as Azure SQL Database, Azure Event Hubs, Azure CosmosDB (former DocumentDB), Cortana, Skype for Business and many others.

The platform has changed names multiple times throughout its journey; Microsoft announced a private preview at Build Conference 2015 to show to the public how they managed their products in Azure and was planning to open to the public, Service Fabric was released as Public Preview in November 2015 where users could start building applications on top of it.

Kubernetes roots date back to 2003; Google built Borg, a system used to schedule hundreds of thousands of jobs among tens of thousands of machines. These jobs were mainly processes running within the same machine isolated from each other to support services like Google Search, Gmail, Google Docs, and Infrastructure services like BigTable. In 2006, a team of Google engineers joined to create a Linux Kernel feature called cgroups (control groups), the foundation for what is popularly known today as Containers. In the fall of 2013, with the popularity of containers, mainly pushed by the popularity of Docker, another team of Google engineers with more than ten years of experience managing containerised applications using Borg, decided to create from scratch a new lightweight version of Borg. By applying the good practices and avoiding the mistakes made whilst building Borg, what became known as Project Seven, was later released to the public in mid-2014 as Kubernetes. Since then, the solution has been open-sourced and donated to the Cloud Native Computing Foundation, and it didn’t take long for Kubernetes to become one of the most popular and adopted open-source solutions.

‍

Juggernauts back both solutions, Microsoft and Google, regarding scalability and experience orchestrating applications on massive scale clusters. On one side, Microsoft managing Azure services to support critical PaaS offerings to serve millions of enterprise customers, on the other side Google, bringing years of experience managing mission-critical solutions spanned across tens of thousands of machines, supporting billions of users.

The problems addressed by both solutions are very similar, providing a platform to abstract the infrastructure configuration and maintenance of a large cluster of machines from the application lifecycle management. This abstraction reduces the friction on development of highly distributed and scalable solutions by using building blocks and offloading the infrastructure concerns to the platform; from there, the solutions start to diverge.

Service Fabric is 15+ year-old technology re-designed and re-branded throughout the years to become what it is today; its origins focused on cluster federation and process orchestration for windows applications. Through all these years, it accumulated lots of features that could be argued are some years ahead of Kubernetes.

Kubernetes foundations are cluster management of Linux machines and orchestration of applications based on containers, something that only existed on Linux until recently when Microsoft decided to adopt the idea. Kubernetes’ main goal has always focused on container orchestration, with a big influence and concepts from Borg. Containers took its place in the future of computing, and Microsoft embraced it and decided to work on its Windows Containers.

Service Fabric has always been a Windows-first product. In the last couple of years, things have changed a lot with Container trends and the .NET Core movement, bringing .NET developers previously locked down to .NET Framework on Windows, to port their solutions to the Linux platform, meaning they are now catching up with the Linux stacks that have been the Kubernetes playground for many years.

Windows Containers is a new technology developed behind closed doors by the Windows team, Kubernetes is catching up the windows containers ecosystem but is highly dependent on Microsoft supporting it in the long term, sooner or later both will be on the same page, if Microsoft doesn’t drop his support first and decide to focus on Service Fabric only.

Service Fabric, like most solutions provided by Microsoft, is a very opinionated platform. Provided with some inflexible guidance, that generally speeds up the adoption for most simple setups and reduces the chances for failures; on the other hand, it slows you down on complex scenarios when you need more customisation and flexibility from the platform to adapt to solutions that do not adhere to Microsoft architectural processes.

Most parts of Service Fabric components were built from scratch to address the needs of the platform, and it is what many today call a monolith solution, where most components are tightly coupled to each other, making replacement difficult. This weight is noticeable when comparing the slow release cycle of Service Fabric to Kubernetes frequent incremental releases on individual components.

Kubernetes was designed to be a component-based solution to be extended by other open-source components, and most of its core features are provided by products already available in the open-source community. A good example is the state management using ETCD; it has never intended to implement leader election algorithms, state machine replication or many other algorithms from scratch. Kubernetes’ loosely coupled approach slows you down in starting new solutions because you have to learn and choose from a multitude of options to form a cluster with all the pieces needed to support your operations. Once mastered, the development of new solutions will be much faster for complex scenarios and easy to replace bits when it does not support your needs anymore.

Service Fabric team has been trying to move Service Fabric development to open-source, but it’s tight coupling to Microsoft internal processes has been delaying the plan.  The source code itself is already on public GitHub repositories, but to be a true open-source solution it is far from ideal; open-source is not just opening the code for public appreciation, but also provides a clear and public roadmap of the platform plan.  Good project governance and accepting the public support to implement solutions on top of the platform, these milestones are a long way ahead and will take many years to become true.

Jason Zander is correct to say when you compare feature by feature, Service Fabric has a much richer feature set built in and it implements most of the components whereas Kubernetes relies on third-party solutions, but Service Fabric is a way behind when Linux and containers are the main topics. The new version of Service Fabric, Mesh, based entirely on containers and cloud resources, means that things will change a lot for Service Fabric. Most of the features promised by Mesh are already supported on Kubernetes today, the only game changer in this race is the approach adopted for the Infrastructure Resource Management, that will be managed by Azure. This is just an advantage in a race that, sooner or later, will be addressed by Kubernetes with the support of other cloud providers.

If Service Fabric wants to take the lead, Service Fabric Mesh must embrace a true open-source approach. If it continues with this rigid and unclear path, handled in a meeting room for corporate users and impose the decisions to the end users; it will lag behind, with another race lost.

‍