Future of MicroservicesJakub HadvigOpenShift Engineering

Microservice ?

Microservice● Software architecture● Application composed from processes

○ small and independent ○ single purpose○ replaceable○ isolated

Microservice● Software architecture● Application composed from

processes○ small independent processes○ single purpose○ replaceable○ isolated

Linux Containers (LXC)● Virtualization on a operating-system level● Single Linux host = multiple isolated Linux system ● Containers run with host kernel (fast)● Microservices = Containers

Microservices redefine the “App”● Networked components wired together

○ Not just a “web frontend” anymore○ HTTP frontends are just one type of component○ Make it easy to build, manage, deploy components (tools)

● Critical: relationships between components○ If you can’t abstract the connection between components you

can’t evolve them independently

Dockergithub.com/docker/docker

Docker● Containerization engine for building images● Go● Core functions

○ docker build = Docker images○ docker run = Docker containers

● Dockerfile○ DSL○ 16 instructions

Dockerfile

!!! Remember “CMD” Instruction !!!

Docker images● Immutable (read-only)● Sharable● 80k public Docker images (DockerHub)● Building blocks

○ Image based deployment○ Create once, use everywhere (Dev, QA, Prod)

Docker containers● State-less● Transient● Cattle, no pets

Docker● What do we want?

○ Full access to the existing Docker ecosystem○ Be able to consume images from anywhere○ Work with upstream to improve security and reliability○ Need tools to manage the build process and security updates

● What do we expect?○ Manage 1M+ of running containers○ Manage containers across multiple nodes

Kubernetesgithub.com/GoogleCloudPlatform/kubernetes

Kubernetes● Container cluster manager● Manage containerized applications across a

cluster of Nodes○ Running containers at scale○ Provide runtime and operational tools for containers○ Provide resource management

● Google, Red Hat, CoreOS and others…● Go

Kubernetes architecture (basics)● Master(s)

○ (REST) API server○ Scheduler for allocation of “containers” onto hosts○ Manages replications and watches the system for changes

● Node(s)○ Agent that relays informations between Node and Master ○ Manages containers (using Docker)○ Proxy for local service routing and load-balancing

Kubernetes architecture● Etcd

○ Simple config key-value store distributed across hosts○ Highly reliable○ Used for service discovery○ Simple (CURL ball) & Secure (SSL)○ Provide high-performance operations

Kubernetes work units● Pod

○ Represents group of containers closely related together○ 1..N containers

Pods

Kubernetes work units● Service

○ Abstract set of Pods as a single IP and 1..N ports

○ Provides environment variable in other Pods and simple

TCP/UDP load balancing

Services

Kubernetes work units (cont..)● Replication Controllers

○ Framework for Pods that are meant to be horizontally scaled○ Maintain number of replicas for given Pod○ Replicas are distributed across cluster

● Label(s)○ Common field in all Kubernetes resources

○ Represents a 'tags' you can use to couple the work units

together

Kubernetes work units (cont..)● Route

○ Exposed service, reachable from outside

So what is an new "Application"?Pods linked together by Services:● Edge router for www.myapp.com -> Rails frontend Pods● Rails frontend Pods -> "backend" API Service● "backend" API Service -> Python Pods● Python Pods -> "postgresql" database Service● "postgresql" Service -> PostgreSQL Pod with network

attached storage

OpenShift v3github.com/openshift/origin

OpenShift v3● Use Docker to containerize applications● Use Kubernetes to manage them

○ Allow for Service-oriented-Architecture (Mircoservices !!!)

● Go

Composition● Kubernetes is embeddable● Kubernetes offers us infrastructure● OpenShift embeds it and add PaaS pieces:

○ Builds○ ImageStreams○ Deployments○ Templates○ ... others...

Build● Allows to build “stuff”

○ S2I, Docker, or Custom build● Kubernetes schedule and execute the build inside Docker

container● Triggers

○ webhooks○ image change○ config change

● Built image are pushed into a single ImageStream.

ImageStream● Build upon Docker Registry● Abstraction for lack of functionality

○ base image○ notify changes○ track history

Deployment● Define the lifecycle for a single image

○ What happen when an update is pushed to Docker image?○ What happen when application configuration is updated?

○ What happen when updated application configuration fail to

deploy?

Templates● For consumption by end users of standard

patterns● Describes the whole application topology

S2I (Source to Image)● Don’t make developers write Dockerfile● Providing builder images is operational responsibility● Developers wants simple flows (From GIT repo to Docker image)

○ Push changes to Git○ Get all dependencies installed (bundler, npm, pip, maven, etc..)○ Commit Docker image○ Deploy

S2I (Source to Image)● Build process fundamental elements

○ source○ builder image○ s2i scripts

■ assamble■ run

● Current s2i builder images:○ ruby, php, python, nodejs, perl, jboss

● Incremental builds (kinda)

Source code● Consuming external source repos (no hosting)

○ github && generic webhooks● Support different SCM (bzr, mercurial, SVN, CVS, ...)

OpenShift and Images● Need tools for Docker image management

○ Think about millions of Docker containers○ Need good quota story - OpenShift v3 Online○ Pruning - remove old stuff○ Content tracking and auditing

● Security

Documentation, links, repos● OpenShift 3 Technical Architecture

○ Much deeper dive into the architecture● OpenShift 3 System Design (PEP)● Kubernetes Repo

○ https://github.com/GoogleCloudPlatform/kubernetes● OpenShift Repo

○ https://github.com/openshift/origin● Sample App+Guide

○ https://github.com/openshift/origin/tree/master/examples/sample-app● OpenShift Blog Series

○ https://blog.openshift.com/author/benparees/● Source-To-Image project

○ https://github.com/openshift/source-to-image

Thanks! Questions?