From Engines to Orchestrators

Lee Calcote
Sept 30th, 2016

Lee Calcote

clouds, containers, infrastructure, applications

 and their management

Show of Hands

Types of Containers

System Containers

  • Like a VM
  • Full OS image
  • Multiple processes

Application Containers

  • Single process
  • Use namespaces to deal with resource isolation for a single process.

  • Use cgroups to manage resources for a group of processes.


  • rkt
  • docker
  • runC
  • kurma


  • containerd
  • systemd-nspawn
  • OpenVZ
  • Solaris Zones
  • BSD jails
  • Linux-VServer
  • LXC


  • LXD
  • CGManager
  • machinectl


  • qemu-kvm, lkvm

System Container Engines

Application Container Engines

Container Specifications

Implemented by -

  • rkt is the canonical implementation
  • Kurma leverages runC 
  • Jetpack is an implementation of for FreeBSD using jails and ZFS

Implemented by -

  • runC is the reference implementation
  • runV is a hypervisor-based runtime
  • cc-oci-runtime launches an Intel VT-x secured Clear Containers 2.0 hypervisor



  • image-spec

    • a software shipping container image format spec with security and naming as components

  • image-tools

    • tooling for the image 

Get Started with your Engines

and get your engines started

Popular Engine
process models

  • rkt executes as CLI; no daemon

  • Can run Docker Images and also App Container Images (ACIs)

  • Security has been a focal concern 

  • uses HTTPS to locate and download remote ACIs and their attached signatures

  • Docker Engine runs a daemon



$ rkt run postgres



$ docker run postgres


Docker Engine




[ awr -k uh -streyt -or]

[k uh n- tey-ner]


  • Cluster Management

    • Host Discovery

    • Host Health Monitoring

  • Scheduling

  • Orchestrator Updates and Host Maintenance

  • Service Discovery

  • Networking and Load-Balancing

Key Capabilities

  • Application Health Monitoring

  • Application Deployments

  • Application Performance Monitoring

One size does not fit all.

A strict apples-to-apples comparison is inappropriate and not the objective, hence  characterizing  and  contrasting.


Genesis & Purpose

  • an opinionated framework for building distributed systems

    • or as its tagline states "an open source system for automating deployment, scaling, and operations of applications."

  • Written in Golang, Kubernetes is lightweight, modular and extensible

  • considered a third generation container orchestrator led by Google, Red Hat and others.

    • bakes in load-balancing, scale, volumes, deployments, secret management and cross-cluster federated services among other features.

  • Declaratively, opinionated with many key features included


Docker Swarm

Genesis & Purpose

  • Swarm is simple and easy to setup.

  • Swarm is responsible for the clustering and scheduling aspects of orchestration.  

  • Originally an imperative system, now declarative

  • Swarm’s architecture is not complex as those of Kubernetes and Mesos

  • Written in Golang, Swarm is lightweight, modular and extensible




Genesis & Purpose

  • Mesos is a distributed systems kernel

    • stitches together many different machines into a logical computer

  • Mesos has been around the longest (launched in 2009)

    • and is arguably the most stable, with highest (proven) scale currently

  • Mesos is written in C++

    • with Java, Python and C++ APIs

  • Marathon as a Framework

    • Marathon is one of a number of frameworks (Chronos and Aurora other examples) that may be run on top of Mesos

    • Frameworks have a scheduler and executor. Schedulers get resource offers. Executors run tasks.

    • Marathon is written in Scala


A high-level perspective of the container orchestrator spectrum

Lee Calcote

Thank you. Questions?

clouds, containers, infrastructure,

applications  and their management