Azure Service Fabric 与 Docker 数据中心

Question

I went over this blog Azure SF vs Docker but it didn't answer my doubts completely. I have Docker Data Center on-prem and i want to push Azure SF into this. But i feel DDC is doing exactly same thing as Service Fabric. Few things from my mind.

• DDC takes care of scaling up, all types of container orchestration, health monitoring etc.

Few items which it doesn't provide :

• Service remoting between services, publish subscribe model between services, stateful layer(i've heard about portworx volume rep)

Can someone enlighten me more on when should i go with SF which DDC doesn't provide.

Answer 1

If your application landscape consists of containers and there is no intention to change that then you should probably stick to DDC.

Service Fabric (ASF) has a lot more to offer than support for containers. In fact, in earlier days it did not even had support for containers.

The focus of AFS is to provide a platform for building microservices based applications using stateless services, stateful services and actors.

Things that DDC does not provide:

• Stateful Services
• Actor model

Stateful Services : The benefit of stateful services is that the data lives where the code lives, so no more separate data stores like a NoSQL or relational database. A great benefit is the reduced latency. So in other words, if you have a frontend running in a container that connects to a container that contains a MySQL server for example, you can replace that using a mix of stateless and stateful services.

Actor model : The actor pattern is a computational model for concurrent or distributed systems in which a large number of these actors can execute simultaneously and independently of each other.

In some scenario's the use of containers in ASF is a temporarily one, to lift and shift existing software and combine that with ASF own service models. In later stages the containers can be replaced by ASF services.

The official docs does list some scenario's as when to run containers on ASF:

IIS lift and shift : If you have existing ASP.NET MVC apps that you want to continue to use, put them in a container instead of migrating them to ASP.NET Core. These ASP.NET MVC apps depend on Internet Information Services (IIS). You can package these applications into container images from the precreated IIS image and deploy them with Service Fabric. See Container Images on Windows Server for information about Windows containers.

Mix containers and Service Fabric microservices : Use an existing container image for part of your application. For example, you might use the NGINX container for the web front end of your application and stateful services for the more intensive back-end computation.

Reduce impact of "noisy neighbors" services : You can use the resource governance ability of containers to restrict the resources that a service uses on a host. If services might consume many resources and affect the performance of others (such as a long-running, query-like operation), consider putting these services into containers that have resource governance.

By the way, in your referenced Q & A the fact that is a Microsoft product is listened as a possible disadvantage. It might still be to some, but Microsoft has announces it will open source ASF.