Docker Containers - Yes, No, Maybe?

Prakash Pattisapu — Fri, 03 Apr 2020 00:10:20 +0000

I've been working on a personal mobile project since the past year or so. This requires a highly scalable and real time back-end platform. I spoke to some industry colleagues on the high level architecture before I got started in early 2019 and some said "Containers" and some said "Serverless". Granted, coming from the Windows world, I've not worked with Container technologies before [btw, Windows Server Core 2016 and Nano Server both have excellent Container Support now].

I've been working on large scale global distributed Micro-Service systems since the past 5 years or so with the all the following benefits on the Service Fabric Platform.

Of course, Service Fabric supports "Containers" too but, I never got around to using them and just used Service Fabric the way it was originally designed for. Orchestrating "Processes" on a massive scale with the goodness of Reliable Programming Services and native support for Stateful Services and end-to-end DevOps using Azure DevOps Server

Sticking to "Process" orchestration allowed me to architect systems that are much simpler, more cost effective, easily maintainable without sacrificing any benefits of "Containerization" and most importantly gave the best bang for the buck for my employer.

Containers gives you Process Isolation, Consistent Environment, Run Anywhere. If we apply the same principles to Service Fabric orchestrated environment [Process based], it ticks all the boxes.

We can rely on O/S provided default process isolation + .Net based App Domains to achieve process isolation. [Granted, .Net core does not have App domains but, I am still ok with O/S provided process isolation]
Service Fabric packages your Code + Config + Data [for Stateful services] and deploys to "n" number of replicas across your cluster.
It runs any where from your laptop to the most massive data centers.
We can impose resource governance limits on each individual process. [ex: 50% of memory and 25% CPU for a specific process, placement constraints limiting certain processes to certain "node types" etc]
"Processes" provide the best activation times and are the leanest compared to VM's and Containers [On both bare metal and VM's]
Saves time and money not having to deal with container technology and Orchestration.
I would say "Containers" makes sense in the following scenarios:

If you are developing global multi tenant applications where each tenant should be running on a different isolated environment, config, runtime and package dependencies, it makes absolute sense to go for "Containers". [ex: Building your own Cloud like Aws/Azure/GCP]. Update: Server 2019 and Nano Server support Hyper-V containers which work great with "Hostile Multi-Tenant" scenarios.
Lift and Shift: The app currently works, need to make it portable without re-writing it, containers makes sense.
For Enterprise LOB microservice applications, Global Scale Distributed Systems, AI/ML workloads, IoT Edge computing scenarios and Web Hosting, consider a Process Orchestrator like Service Fabric before jumping into Containers.

Please let me know your thoughts in the "comments" below..

PS: As expected, I did not go with Containers for my mobile project. That's a topic for another article :)

The case for Azure Service Fabric.

Prakash Pattisapu — Wed, 11 Dec 2019 03:41:24 +0000

The world is currently going towards Containers and everybody's favorite Container Orchestrator is Kubernetes aka K8s.
This article shows that K8's is not the only framework for building Distributed apps, especially on Windows Server and how Service Fabric also has a few advantages over Kubernetes!

Before we get started, Service Fabric gives all of these benefits out of the box.

Service Fabric can be installed on your laptop to hundreds (and thousands) of machines spanning multiple locations on the planet. The run time and SDK are free and can be enabled via "Azure Development workload" in Visual Studio Installer.

Steps

Enable "Azure Development workload" via the Visual Studio installer
Install Service SDK from https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started
If you need to deploy containers, you need to install Docker.
Open Visual Studio, create your first service fabric application
Choose the "Project Type" you want to start with. You can have a "Stateful Service", "Stateless Service", "Actor Service", ASP.Net Core [Both Stateful and Stateless] & Container Hosted Project.
After choosing your first project type, enter your " project name" and click "Next". Below you can see that I've created a "Stateful" service called "ProductService"

Post Installation of SDK

After the SDK is installed, you will see a service fabric icon in the system tray.
You have the option of creating a "5 node" or "1 node" local cluster. "1 Node" is better for faster deployments. "5 node" more closely mimics a production cluster.
- You can manage the local service fabric dev cluster using the local service fabric explorer. [default URL: http://localhost:19080/]

Anatomy of a Service Fabric Application

Our Service Fabric Application name is "Dev_To_SF".
The project "Dev_To_SF.csproj" is the Service Project "glue" project that holds references to all other fabric projects. The job of dev_To_SF.csproj is to...
- Define the "ApplicationManifest.xml", "AplicationParameters" and "PublishProfiles" file. ApplicationManifest file lists the service types, partition types [for stateful services], Package Reference names, Package Version Numbers and Default App parameters
- "ApplicationParameters" folder houses the "params" that are to be passed when the Application is being constructed in Service Fabric. [You may have different set of params based on Dev/UAT/Prod environments]
- Publish Profiles folder defines the profile to be used when deploying to a particular envt.
- The scripts folder contains a Powershell script that is invoked when deploying from Visual Studio. For localhost deployments this is fine. For CI/CD, you would want to use Azure DevOps Server/Jenkins etc as your build tool for automated deployments.
- The "Default Services" section in ApplicationManifest defines what services to be installed by default in your cluster. If you want fine grained control, you can omit this section and deploy your app using Powershell commands. This approach gives you total flexibility on what "services types" to create under your application.

Anatomy of a Microservice inside a Service Fabric Application

"Product Service" is a Stateful service. The entry point for this service is inside "Program.cs" in ProductService. This entry point resembles a console application because it is! It uses service fabric specific API's to to register "ProductService" with the fabric runtime.
Each service also has a "ServiceManifest" file that describes http/tcp end points names, service versions etc and Settings file that defines any service specific params.
The stateful Product service class inherits "StatefulService" class. This gives us accesss to the "StateManager" instance which is responsible for propagating the app state to the "Primary" and "Secondary" replicas.
The internal" StateManager" gives access to a "Key-Value" store which models a regular .Net Dictionary but which is different and built for the cloud.

Coming Next..

In the next article, we will look @ deployment to local cluster, Stateful Services and a little bit more on Reliable Dictionaries.

I mentioned in the beginning of the article that Service Fabric has some advantages over Kubernetes.. here they are:

Service Fabric orchestrates both Processes and Containers. Kubernetes is strictly a "Container" Orchestrator. The barrier to entry into Service Fabric is lower. Process Orchestration has the fastest activation times.
Service Fabric provides a reliable services programming model on top of the core "Orchestrator". This programming is what gives us reliable services, actor model, queues etc.
Equal support to windows and linux containers. Kubernetes services are linux first. If your primary deployment target is windows server, you will be slightly behind in terms of features.
Learning curve: There are many tools and add-ons available in the kubernetes world. On the service fabric side, The default installer will give all you need to develop your first micro service app and deploy it. I believe developing and deploying to service fabric cluster is easier compared to Kubernetes.

Side Note: We got a 50% performance boost moving our windows service workload to a 10 node service fabric cluster on similar hardware! [On-Premises]