15

I see advantages of Kubernetes which include Rolling Deployments, Automatic Health check monitoring, and swinging a new server to action when an existing one fails. I also do understand that Kubernetes is not just for Docker.

So, that brings a couple of questions!

When Azure, and Service Fabric could provide all that I said (and beyond), why would I need Kubernetes?

Would it make sense for one to use Kubernetes along with Service Fabric for large scale deployments on Azure?

David Makogon
  • 69,407
  • 21
  • 141
  • 189
CodeMad
  • 950
  • 2
  • 12
  • 30
  • @Downvoter: Can you please explain why? – CodeMad Jan 30 '18 at 12:00
  • 1
    Watch [this](https://myignite.microsoft.com/sessions/55068?source=sessions) from minute 5 to minute 10. fantastic slide that answers your question. But this question is too broad and probably attracts opinioned answers, that can explain the downvote (which I did not cast btw) – Peter Bons Jan 30 '18 at 12:45
  • 1
    A similar question was asked during the Service Fabric Community Q&A. It starts at around the 9 minute mark: https://m.youtube.com/watch?v=phWGBSV9pzQ – HiredMind Jan 30 '18 at 14:50
  • Thanks for those links, very helpful. :) – Grant Rostig Mar 17 '18 at 09:22
  • Appreciate your help, everyone – CodeMad Mar 26 '18 at 09:23

2 Answers2

38

Let's look first at the similarities between Kubernetes and Service Fabric.

  • They are both cloud-agnostic clustering, orchestration, and scheduling software.
  • They can both be deployed manually, by you, to any set of VMs, anywhere.
  • There are "managed" offerings for both, meaning a cloud provider like Azure or Google Cloud will host a cluster for you, but generally you still own the VMs.
  • They both deploy and manage containers.
  • They both have rich management operations, such as rolling upgrades, health checks, and self-healing capabilities.

That's a fairly high-level view but should give you an idea of what and where you can run with each.

Now let's look where they're different. There are a ton of small differences, but I want to focus on two of the really big conceptual differences:

  • Application model:

    • Service Fabric allows you to orchestrate any arbitrary container or EXE (whether that's a small node.js app or a giant legacy application), and in that sense it is similar to Kubernetes. But overall it is more focused on application development specifically, with programming models that are integrated with the platform. In this respect, it is more closely comparable to Cloud Foundry than Kubernetes.
    • Kubernetes is focused more on orchestrating infrastructure for an application. It doesn't really focus on how you write your application. That's up to you to figure out; Kubernetes just wants a container to run, doesn't matter what's in it.

  • State management

    • Kubernetes allows you to deploy stateful software to it, by providing persistent disk storage volumes to containers and assigning unique identifiers to pods. This lets you deploy things like ZooKeeper or MySQL.
    • Service Fabric is stateful software. Service Fabric is designed as a stateful, data-aware platform. It provides HA state and scale-out primitives. So while Kubernetes allows you to deploy stateful things, Service Fabric allows you to build stateful things. This is one of the key differences that's often overlooked. For example:
      • On Kubernetes, you can deploy ZooKeeper.
      • On Service Fabric, you can actually build ZooKeeper yourself using Service Fabric's replication and leader election primitives.
      • Kubernetes uses etcd for distributed, reliable storage about the state of the cluster.
      • Service Fabric doesn't need etcd, because Service Fabric itself is a distributed, reliable storage platform. The system services in Service Fabric make use of this to reliably store the state of the cluster. This makes Service Fabric entirely self-contained.

The fact that Service Fabric is a stateful platform is key to understanding it and how it differs from other major orchestrators. Everything it does - scheduling, health checking, rolling upgrades, application versioning, failover, self-healing, etc - are all designed around the fact that it is managing replicated and distributed data that needs to be consistent and highly available at all times.

Vaclav Turecek
  • 9,020
  • 24
  • 29
-6

Please find below a good comparaison article about the difference between ACS and Azure Service Fabric: https://blogs.msdn.microsoft.com/maheshkshirsagar/2016/11/21/choosing-between-azure-container-service-azure-service-fabric-and-azure-functions/

Could you please clarify what you refer to when you talk mentionne "AWS" ?

From a "developer level" solution could be statefull in both cases but it have a major difference from an Infrastructure point of view:

  • Docker + Kuberest is a "IaaS" oriented solution
  • Azure Service Fabric (if you are using Azure service) is a PaaS solution.

IaaS is, in general, more costly and have a more significant maintenance cost. From a support point of view:

  • Azure Service Fabric is supported by Microsoft
  • Docker and Kubernetest are more open source oriented

Hope this help.

Best regards

Nicolas
  • 47
  • 3
  • AWS (probably) refers to Amazon Web Services. The question seems to be about the comparison between these different clouds and their functionality, and not so much IaaS vs PaaS using Azure... – jdno Jan 30 '18 at 13:46
  • Thanks for your feedback, then I didn't really answer to the question. Anyway to make a choice, question about the infrastructure and associated maintenance impacts seems legit and need to be adress. Regarding the technology itself, Azure Service Fabric is statefull oriented and it's a key difference regarding the other containers technologies (at least on Azure). – Nicolas Jan 30 '18 at 13:52