Containers and Kubernetes: Improvements in Infrastructure Management for Application Developers

Introduction

Cloud Computing has seen a steady uptick in adoption across ISVs and Enterprises due to benefits seen due to rapid feature implementation, testing, deployment and management. The focus of this newsletter is to share some of the advancements in the technology for infrastructure management, which will affect the methods in which business applications are being developed. This newsletter assumes that the audience is comfortable with basic cloud terminology, including infrastructure, platform and service clouds (-aaS i.e. as-a-service).

Infrastructure Clouds (like AWS EC2, Azure Compute, IBM SoftLayer) provide core infrastructure primitives like compute, storage and network. This enables a user to order a VM and run application workloads of the user’s choice. The user is responsible for running the Guest OS and above applications, while the cloud provider is responsible for running the hypervisor and below primitives. A simple representation is as follows

Containers

On the other hand, containers are a software construct, that appears to run as a lightweight virtual machine. Amongst other features, it has a dedicated process space which allows applications to run with a dedicated network interface, which can be ssh’ed into. However, containers are not primitives like VMs. Rather, they use OS features, like cgroups (which provides isolated access to resources like CPU and memory) and namespaces (which provide isolated views of the system like processes, network interfaces, mount points, filesystems etc.) to provide a consistent boundary on what is running within a container.

In addition, containers are a powerful tool to package applications, including the dependencies to ensure that the applications run consistently. It fits with the analogy of shipping containers, which ensures that goods to be transported are abstracted by containers, so that shipping companies can automate the shipping of containers, without worrying about what is within them. While this write-once, run-anywhere philosophy was initially championed by Java (the programming language), containers (best represented by Docker) provide the ability to run applications in your programming language of choice (including Java, .Net, Node.js, Python etc). Docker is the industry standard for implementing containers.

It would be useful to distinguish between a container image i.e. software packaging and distribution (also called as Dockerfile) and container runtimes i.e. executing a binary in a sandbox (e.g. Docker Engine). Due to containers running natively on the OS, they can run with native CPU and IO speed, can launch immediately (as opposed to standard boot times in VMs) and have lesser memory/storage overhead. They are more efficient than VMs in utilizing system resources, which enables more applications to run on the same quantity of hardware. Due to these 3 main features (isolation, repeatability, very low resource overhead – startup & runtime), containers, in conjunction with CI/CD, are helping application architectures move to a distributed micro-services model to enable rapid application development and deployment. Additional links here (Best Practices)

Kubernetes

This section is more relevant to teams involved with managing infrastructure, but it would be worthwhile for developers to understand how to build micro-services to make efficient use of the underlying resources. The last section briefly touched on the benefits on running workloads in containers vs VMs. While containers are useful to encapsulate a single unit of work, additional management of these containers is needed, to provision, monitor and scale based on the requirements of the workload. Cluster management/Orchestration systems, like Kubernetes, Docker Swarm, Apache Mesos, are used to manage containers at scale. This article will focus on Kubernetes, considering its large-scale adoption across the industry.

Kubernetes (also K8s) is a platform for automating deployment, scaling and operations of containers across clusters of hosts. To take the shipping analogy forward, Kubernetes (Greek for helmsman/pilot) would steer the ship carrying the containers. Developed originally by Google to manage their Cloud-scale workloads, Kubernetes is also provided as a managed service by most cloud providers (AWS EKS, GCP Kubernetes Engine, Azure Kubernetes Service, IBM Cloud Kubernetes Service).

For application developers, Kubernetes attempts to abstract the infrastructure steps of ssh’ing into VMs. Instead, Kubernetes provides a declarative way to describe your cluster’s desired state i.e. what applications/workloads need to run, what container images are used, number of replicas, what network and disk resources are needed etc. Once this desired state is defined, the Kubernetes Control Plane ensures that the cluster’s current state matches the desired state, by performing tasks automatically such as starting/restarting containers, scaling number of replicas of a container etc. Using this approach, application developers can focus on developing the application logic within containers, while cloud providers/cluster operators can focus on providing PaaS-like capabilities for workloads to run at scale.

For application developers, I would recommend the following reading links to get started

·       Kubernetes Basic Workflows

·       Getting Started for Application Developers

·       Additional Patterns and tools for Application Developers

This article was intended to share an introductory overview on how enterprises/ISVs are migrating from a 3-tier on-premise architecture to a micro-services cloud-based architecture via lift-shift migration on VMs -> containerization -> Kubernetes implementation. To be fair, these are steps to be taken along a more complex journey.