I have worked on Kubernetes and currently reading about Service Fabric, I know Service Fabric provides microservices framework models like stateful, stateless and actor but other than that it also provides GuestExecutables or Containers as well which is what Kubernetes also does manage/orchestrate containers. Can anyone explain a detailed difference between the two?
You can see in this project paolosalvatori/service-fabric-acs-kubernetes-multi-container-appthe same containers implemented both in Service Fabric, and in Kubernetes.
Their "service" (for external ingress access) is different, with Kubernetes being a bit more complete and diverse: see Services.
The reality is: there are "two slightly different offering" because of market pressure.
The Microsoft Azure platform, initially released in 2010, has implemented its own Microsoft Azure Fabric Controller, in order to ensure the services and environment do not fail if one or more of the servers fails within the Microsoft data center, and which also provides the management of the user's Web application such as memory allocation and load balancing.
But in order to attract other clients on their own Microsoft Data Center, they had to adapt to Kubernetes, released initially in 2014, which is now (2018) either adopted or closely considered by... pretty much everybody (as reported in late December)
(That does not mean one is "better" than the other,
only that the "other" is more "visible" than the first ;) )
So it is less about "a detailed difference between the two", and more about the ability to integrate Kubernetes-based system on Microsoft Data Centers.
This is in line (source: detailed here) with Microsoft continued its unprecedented shift toward an open (read: non-proprietary) staging platform for Azure (with Deis).
And Kubernetes orchestrator is available on Microsoft's Azure Container Service since February 2017.
You can see other differences in their architecture of a deployed application:
Service Fabric:
Vs. Kubernetes:
thieme mentions in the comments the article "Service Fabric and Kubernetes comparison, part 1 – Distributed Systems Architecture", from Marcin Kosieradzki.
Both are different. Kubernetes manages rkt or other containers.
Service Fabric is not for managing containers. In case it manages some, that does not make it its purpose. That does not enable it for a comparison with Kubernetes.
eg: When a pod dies Kubernetes puts it to other nodes immediately. The part of SF that manages containers does not do this, it is done by some other area of Service Fabric. And outside containers. And was not designed with containers in mind.
Related
I am a newbie in Kubernetes.
I have 19 LAN servers with 190 machines.
Each of the 19 LANs has 10 machines and 1 exposed IP.
I have different websites/apps and their environments that are assigned to each LAN.
how do I manage my Kubernetes cluster and do setup/housekeeping.
Would like to have a single portal or manager to manage the websites and environment(dev, QA, prod) and keep isolation.
Is that possible?
I only got a vague idea of what you want to achieve so here goes nothing.
Since Kubernetes has a lot of convenience tools for setting a cluster on a public cloud platform, I'd suggest to start by going through "kubernetes-the-hard-way". It is a guide to setup a cluster on Google Cloud Platform without any additional scripts or tools, but the instructions can be applied to local setup as well.
Once you have an operational cluster, next step should be to setup an Ingress Controller. This gives you the ability to use one or more exposed machines (with public IPs) as gateways for the services running in the cluster. I'd personally recommend Traefik. It has great support for HTTP and Kubernetes.
Once you have the ingress controller setup, your cluster is pretty much ready to use. Process for deploying a service is really specific to service requirements but the right hand rule is to use a Deployment and a Service for stateless loads, and StatefulSet and headless services for stateful workloads that need peer discovery. This is obviously too generalized and have many exceptions.
For managing different environments, you could split your resources into different namespaces.
As for the single portal to manage it all, I don't think that anything as such exists, but I might be wrong. Besides, depending on your workflow, you can create your own portal using the Kubernetes API but it requires a good understanding of Kubernetes itself.
I'm investigating converting my service fabric application to kubernetes. One area I'm struggling with, is what the equivalent of service fabric actors is in kubernetes? I mainly use reminder actors in the application, is there an equivalent in kubernetes?
To use actor programming model on k8s you should use the combination of actor framework (orleans or akka.net) and k8s stateful sets.
Talk from Oslo NDC 2019 Real-Time, Distributed Applications with Akka.NET, Kubernetes and .NET Core
Have a look at dapr runtime. It is heavily influenced by Microsoft's learning of Service Fabric Reliable Services/Actors and runs on top of Kubernetes (and others).
Take into account that it is still in development and not yet released for production scenarios.
I have a greenfield application that I would like to host on Service Fabric but high availability will be a key concern. Is there a way for a cluster to span across Azure region’s? Does Service Fabric recognize Availability Zones?
Is there a way for a cluster to span across Azure region’s?
Yes, it's in the FAQ.
The core Service Fabric clustering technology can be used to combine
machines running anywhere in the world, so long as they have network
connectivity to each other. However, building and running such a
cluster can be complicated.
If you are interested in this scenario, we encourage you to get in
contact either through the Service Fabric GitHub Issues List or
through your support representative in order to obtain additional
guidance. The Service Fabric team is working to provide additional
clarity, guidance, and recommendations for this scenario.
Does Service Fabric recognize Availability Zones?
Yes, but limited.
Make sure to check out this example (marked as 'not production ready'). And check out SF Mesh as well, which allows you to deploy to multiple AZ's. (but currently in preview)
Reading a lot on internet but the information is not clear or mixedup so I thought I will ask the question here.
I am trying to understand how Terraform is same or different from container orchestration tools like Kubernetes, Mesos etc.
Can Terraform work independently or Kube and Mesos? How is it connected to docker containers?
Can someone please shed the light?
Thanks!!!
I don't know enough about Mesos as I would like, but I do know about Kubernetes and Terraform. Despite I'm not an expert the general basics between this tools have a different purpose. While Terraform deals with the generation of the infrastructure in the cloud by using their apis, Kubernetes deals with the administration and orchestration of containers in the undergroown infrastructure by using the api of the container daemon such the docker daemon.
So generally talking the Terraform main point is to make transparent the creation of the cloud infrastructure where you write what you want to have, servers, network, security policies, some PaaS Service and Kubernetes is the orchestrator of containers.
Hope this helps you. Please, in the case of someone saws a mistake. Remark it so we all improves.
Terraform - A Tools to Build your Infrastructure an open-source project Hashicorp labs if you are aware with AWS and heard of CloudFormation both work in same manner but Terraform have some better feature you can write your whole Infrastructure as a Code run it in one click and decommissioned it in one click.
For more you must visit the site: https://www.terraform.io
Now Kubernetes (An open source project by Google) and Apache-Mesos( Or DC/OS) An project by Apache foundation both are used for Container orchestration (and I’m purposely avoiding using the word Docker) is not for everyone and does not answer every need.
Mesos was launched first but it was really hard to manage Mesos networking that time. and In 2014 there was the first Release of Kubernetes comes in.
Now, DC/OS (the Distributed Cloud Operating System) is an open-source, distributed operating system based on the Apache Mesos distributed systems kernel.
It's in the race with Kubernetes .
I would suggest you must go through this article to get a better understanding of Kubernetes vs Mesos : https://logz.io/blog/kubernetes-vs-mesos/
And Yes they are not related to Terraform at all.
Thanks
I have a bunch of services deploying as guest executables to service fabric and all seems fine. I was wondering if there was any point in porting the services to be native Fabric Service services.
Looking at the documentation I can't seem to find any benefits of having implementing them as such, am I missing something obvious?
If your services are stateless there is probably no compelling reason to migrate them into native stateless services. It could be different if your services were stateful; in this context I mean that they store some state inside the process.
The state in native stateful services is stored redundantly, so your services can cope with node failures. This could increase the resilience of your service. In general, you usually create native services in green field situations and rely on guest executables and containers in migration/hybrid situations.
Guest Executable is missing out on some advanced features but it is up to you to decide if you need them.
Benefits of running a guest executable in Service Fabric
There are several advantages to running a guest executable in a Service Fabric:
High availability. Applications that run in Service Fabric are made highly available. Service Fabric ensures that instances of an application are running.
Health monitoring. Service Fabric health monitoring detects if an application is running, and provides diagnostic information if there is a failure.
Application lifecycle management. Besides providing upgrades with no downtime, Service Fabric provides automatic rollback to the previous version if there is a bad health event reported during an upgrade.
Density. You can run multiple applications in a cluster, which eliminates the need for each application to run on its own hardware.
Discoverability: Using REST you can call the Service Fabric Naming service to find other services in the cluster.
I.e. There is something called Stateless Reliable Services - http://www.jamessturtevant.com/posts/Service-Fabric-Service-Types/
The above link will explain it more.