Orchestrating containers with Service Fabric

This post was authored by Boris Scholl, a Program Manager on the Azure Compute team.


At a high level, containers can be seen as encapsulated, individually deployable components running as isolated instances on the same kernel, leveraging operating system level virtualization. This means that each application, its runtime, dependencies, and system libraries run inside a container with full, private access to their own isolated view of operating system constructs. Along with portability, this degree of security and resource isolation is the main benefit for using containers with Service Fabric, which otherwise runs services in traditional processes. On Linux, this isolation has traditionally been provided by cgroups and namespaces, and Windows Server Containers (coming in Windows Server 2016) will behave similarly. In addition, Windows Server 2016 will offer Hyper-V Containers, an even higher level of security isolation for hostile multi-tenant scenarios. Figure 1 shows the different isolation levels.


Figure 1: Isolation level spectrum


Service Fabric will support the different types of containers discussed above in an upcoming release. In this post, I'll provide an early look at Service Fabric container integration, its scenarios and implementation.

For more information on Docker and Windows Containers in general, see Mark Russinovich's blog post about containers, docker, windows and trends .

Service Fabric container integration

Service Fabric leverages Docker for container management on both Linux and Windows containers. Under the covers, we use Docker to create, manage, and delete containers and container images. From a user perspective, Service Fabric will support two container scenarios:

Guest Container

In this case, you can take advantage of Service Fabric's cluster management and orchestration capabilities in the same way you would with guest executables. You reference a container image in Docker Hub, a Docker Trusted registry, or a private registry, in your service manifest, along with additional parameters, such as environment variables. Service Fabric will pull down the image (if it's not already in the local registry) and launch a container based on the arguments you provide. Below is an example of a service manifest that defines the container image contoso/frontend.

<ServiceManifest Name=“ContosoServiceTypePkg" Version="1.0">
        <StatelessServiceType ServiceTypeName=“ContosoServiceType" ... >
    <CodePackage Name="CodePkg" Version="1.0">
    . . .

Service Fabric Services inside a container

In this scenario, you build Service Fabric stateless and stateful services normally and then package them inside a container. This approach gives you all the benefits of native Service Fabric services, such as networking naming service support, self-reporting of load metrics and integration with code, config, & data upgrades, in addition to higher isolation levels provided by containers. At a high level, the container integrates with the Service Fabric runtime on the host system by using Docker data volumes. Figure 2 shows a Service Fabric cluster with running containers that communicate with Service Fabric on the host machine.


Figure 2: Service Fabric Cluster running containers


This post was a quick overview of how Service Fabric will manage containers. We will have much more detail to share when Windows containers launch in Windows Server 2016 and Service Fabric on Linux enters public preview, so stay tuned!

Comments (8)
  1. David Allen says:

    A few clarifying questions: 1) Are Docker containers in use now for existing production Service Fabric installations? 2) Will containers be optional or will they be an intrinsic part of Service Fabric architecture?
    Thanks for keeping us up-to-date.

    1. Shahid says:

      1) Docker containers are part of the Linux host capabilities which are currently in private preview. I don’t know for definite but I would imagine the large preview customers are already running these.
      2) My understanding having spoken to someone from the team is that the Linux support in service fabric is delivered via containers. Obviously you have the choice of running on windows at the moment without containers but I wouldn’t be surprised if we find containers being used as the default hosting for service fabric (windows or Linux) as it’s a good fit.

    2. Boris Scholl says:

      Hey David, sorry for the late response. To answer your questions:

      1. Not quite sure what you mean by that. If you are asking if we have real customers running Docker containers on top of Service Fabric, the answer is no. Keep in mind that we are still in preview for Service Fabric on Linux. If your question is if you can use Docker containers with our Service Fabric on Linux preview, the answer is yes. (It’s still in early stages, so you may not be able to use all container features.) We will document the exact feature set soon.
      2. Containers are optional. Service Fabric treats containers like services.
      Let me know if you have more questions.

  2. Namit.T.S says:

    Thanks for the post Boris. Few clarifications
    1. When using the second approach ‘Service Fabric Services inside a container’, what extra level of isolation do we achieve which is different from the service level isolation provided by reliable service programming framework?
    2. Can you please share some scenarios around when to use what approach?

    1. Boris Scholl says:

      Hi Namit,

      1. Service Fabric services use job objects. You can think about containers as job object + namespace virtualization. As a result the container provides a higher level of isolation than a job object.
      2. Scenarios: You want that additional level of isolation as described above. As Windows containers share the same kernel, that may not be enough for you and in this case you can use Hyper-V containers (think about it as a lightweight VM). In this case you accomplish a full isolation of your services which may be needed in certain scenarios.
      Another scenario is that you want to take advantage of the container portability and immutability. By packaging the services inside container images you create and immutable environment. Think about a scenario where your service depends on a library, if you don’t use containers you need to make sure the library is present on an SF cluster. If you package the library into a container image it will travel with the app.

      Please let me know if you have more questions on this.

      1. Namit.T.S says:

        Thanks Boris,

        Can you please point me to any document which talks more about Service Fabric integration with windows containers. Is there a private preview I can sign up for? Is there an ETA you can share on this feature being GA?


      2. Vinod Bhoite says:

        Hi Brios,
        I have created multiple services using Service Fabric Application and deployed in Azure Service Fabric Cluster.
        Now, I want docker to in between this.

        Can you pleas explain, how docker will play role in such cases?
        Means, Need to install Docker on each Service Fabric Cluster node and then deploy services on those container.. right?
        I am not getting how it will be.

  3. Bal Purewal says:

    Could you tell me how windows containers within Service Fabric communicate with each other? What do I need to pass into the Service manifest?

Comments are closed.

Skip to main content