Containers + service fabric

Why Containers?

In an ongoing effort to streamline infrastructures, maximize server resources, and ensure that applications run smoothly and securely, there is a push to adopt containerization of applications. Containerization offers a more efficient alternative to virtualization and it’s heavily influencing the future of cloud computing and the direction of Infrastructure-as-a-service (IaaS).

Following are some good resources to get you up to speed on container technology.

Role of Docker

Containerization as a technology is quite old and existed in Linux base OS. Although it was available for use in Linux, it started gaining traction only after emergence of Docker platform. In simple terms, Docker provides an abstraction layer/ platform that allows developers and system administrators to use containers with ease.

Role of an Orchestrator

While Docker meets the needs of managing one container on one host, it does not take care of managing multiple containers deployed on multiple hosts. This is where Orchestration tools comes into picture.

Orchestration tools extend lifecycle management capabilities to complex, multi-container workloads deployed on a cluster of machines. By abstracting the host infrastructure, orchestration tools allow users to treat the entire cluster as a single deployment target.

Following are services that a typical orchestration platform/ tool should provide:

  • Application/ Container life cycle – Deploy, start, update, stop etc..
  • Declarative configuration
  • Rules and constraints
  • Provisioning
  • Discovery
  • Health Monitoring

There are many container orchestrators available in market today. Typically, orchestrator products are the same products that provide cluster infrastructure, like Mesosphere DC/OS, Kubernetes, Docker Swarm, and Azure Service Fabric.

All of my workload currently runs on Windows and Azure Service Fabric is a best fit for my requirement. I will be using Service Fabric as an container orchestrator.

Basic Principles

  • Make of service agnostic of orchestrator. In other words, your application code should not depend on any SDK or platform libraries. For example, if you are developing containerized web API and using Service Fabric as an orchestrator, your project should not have references to any service fabric assemblies. This will allow us to easily move to other orchestrators in future without making any changes to our application code.
  • Single Azure Container Registry for all applications
  • For disaster recovery, each cluster environment will have 2 set of clusters in different region with ATM active -active configuration
  • Sharing of cluster by multiple services based on service load
  • Use reverse proxy for inter service communication within one cluster/ Service fabric app
  • MSI (IMDS) should be used to access Azure Resources like Key Vault, SQL Azure. This will help in reducing usage of certificates and secrets.

In next few posts I would provide a problem solution approach covering project structure, development, release and maintenance.

Leave a comment