Microservice Architecture

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Martin Fowler - http://martinfowler.com/articles/microservices.html

A single application as a suite of small services
built around business capabilities

Communicating with lightweight mechanisms, often an HTTP resource APIs

Independently deployable

Minimum of centralized management

Deployment

How do we get the sh*t to bare metal?

Speed

Canary Release

Linux Packages

bz@cc:~/$ ar t cart_0.6.20.deb
debian-binary
control.tar.gz
data.tar.gz
bz@cc:~/$ tar tzf data.tar.gz
./etc/default/cart
./etc/init.d/cart
./usr/share/shop/cart/bin/cart
./usr/share/shop/cart/bin/cart.bat
./usr/share/shop/cart/lib/cart-microservice-0.6.20.jar
bz@cc:~/$ tar tzf control.tar.gz
./postinst
./control
./md5sums
bz@cc:~/$ cat debian-binary
2.0

Control File

Source: shop-cart-service
Section: web
Priority: optional
Version: 4.2.42
Maintainer: Bernd Zuther 
Homepage: http://www.bernd-zuther.de/
Vcs-Git: https://github.com/zutherb/AppStash.git
Vcs-Browser: https://github.com/zutherb/AppStash
Package: shop-cart-service
Architecture: amd64
Depends: redis-server (>= 2.8.13)
Description: Cart Service

Package Source

Buildserver

reprepro -Vb /var/packages/debian includedeb shop /tmp/*.deb
reprepro -b /var/packages/debian/ export
reprepro -b /var/packages/debian/ list shop

Provision

---
- apt_repository: repo='deb http://ci-repo/debian/ shop main' state=present
- apt: update_cache=yes force=yes
- apt: pkg={{item}} state=present force=yes
  with_items:
  - shop-cart-service

Linux Packages

Pro Contra
Service Repository No Service Discovery
Dependency Management Runtime enviroment must be created on every single node
Technologies are battle-tested Depends on the linux distribution

How can we avoid the installation time?

Docker

Build, Ship, Run

Docker File

FROM relateiq/oracle-java8
MAINTAINER Bernd Zuther <bernd.zuther@codecentric.de>
EXPOSE 18080
ADD product-0.6.tar /
ENTRYPOINT ["/product-0.6/bin/product"]

Docker Workflow

bz@cc1 $ docker build -t zutherb/product-service .
bz@cc1 $ docker push zutherb/product-service
bz@cc2 $ docker pull zutherb/product-service
bz@cc2 $ docker run zutherb/product-service
bz@cc2 $ docker ps
CONTAINER ID        IMAGE                               COMMAND                CREATED
87bb5524067d        zutherb/product-service:latest      "/product-0.6/bin/pr   14 seconds

Deployment Scenario

Linking

bz@cc ~$ docker run -d --name mongodb mongo
705084daa3f852ec796c8d6b13bac882d56d95c261b4a4f8993b43c5fb2f846c
bz@cc ~$ docker run -d --name redis redis
784ebde0e867adb18663e3011b3c1cabe990a0c906396fc306eac669345628cf
bz@cc ~$ docker run -d -P --name cart --link redis:redis zutherb/cart-service
438b2657c7a5c733787fb32b7d28e1a0b84ba9e10d19a8a015c6f24085455011
bz@cc ~$ docker run -d -P -p 8080:8080 --name shop --link cart:cart \
              --link mongodb:mongodb zutherb/monolithic-shop
9926e187faa215ac9044603d51adbd8d679d8076b4a349ebbc9917dade6d560e
bz@cc $ docker exec 9926e187faa215ac9044603d51adbd8d679d8076b4a349ebbc9917dade6d560e env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=87bb5524067d
MONGODB_PORT_27017_TCP=tcp://172.17.0.28:27017
MONGODB_PORT_27017_TCP_ADDR=172.17.0.28
MONGODB_PORT_27017_TCP_PORT=27017
MONGODB_PORT_27017_TCP_PROTO=tcp

How can describe our microservice application?

Docker Compose

redis:
  image: redis
  ports:
    - "6379:6379"
cart:
  image: eshop/cart-service
  ports:
    - "18100:18100"
  links:
    - redis
catalog:
  image: eshop/catalog-frontend
  ports:
    - "80:80"
  links:
    - product
    - cart

Docker

Pro Contra
Applications are isolated Daemon runs as root on host
Images are built once and run anywhere No Process Supervisor
Docker Repository No Service Discovery
Big ecosystem (Kubernetes, Mesos, Vamp)  

Distributed System - Requirements

Autonomous Worker

Control Plane

Distributed System

Docker Swarm

Docker Swarm

Pro Contra
Only using Docker API No Process Supervisor
Description of the whole application No Service discovery (Hosted Discovery is not recommended for production use)
You needn't care where work is executed Failure analysis will get harder
You needn't care about dependencies Routing must be implemented by hand

Kubernetes

Pod

apiVersion: v1
kind: Pod
metadata:
  labels:
    name: cart
    role: backend
  name: cart
spec:
  containers:
    - name: cart
      image: zutherb/cart-service
      ports:
        - containerPort: 18100

Replication Controller

apiVersion: v1
kind: ReplicationController
metadata:
  ... (labels)
spec:
  replicas: 2
  selector:
    name: cart
  template:
    metadata:
      ... (labels)
    spec:
      containers:
      - name: cart
        image: zutherb/cart-service
        ports:
        - containerPort: 18100

Service

Service

kind: Service
apiVersion: v1
metadata:
  labels:
      name: cart
      role: backend
  name: cart
spec:
  ports:
    - name: cart
      port: 18100
  selector:
      name: cart

Kubernetes

Pro Contra
You needn't care where work is executed No description of the whole application
You needn't care about dependencies Failure analysis will get harder
Service discovery Master is a single point of failure
Process Supervisor Routing must be implemented by hand

Mesos

Marathon Deployment

{"id": "basic-3",
  "cmd": "python3 -m http.server 8080",
  "cpus": 0.5,
  "mem": 32.0,
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "python:3",
      "network": "BRIDGE",
      "portMappings": [
        { "containerPort": 8080, "hostPort": 0 }]}}}
curl -X POST http://10.141.141.10:8080/v2/apps -d @basic-3.json \
  -H "Content-type: application/json"

Marathon + Mesos

Pro Contra
You needn't care where work is executed No description of the whole application and for deployment scenario
High Availability No Service Discovery
Process Supervisor Failure analysis will get harder
Many tools and documentation are available  

Very Awesome Microservices Platform (Vamp)

Vamp + Marathon + Mesos

Pro Contra
Description of the whole application and for routing scenario Many components have to be understood
You needn't care where work is executed Failure analysis will get harder
High Availability  
Process Supervisor  
Service Discovery  

Summary

  Docker Daemon Docker Swarm Kubernetes Mesos
Service Repository
Orchestration
(< 100)
Scheduler - Docker Compose API Server (Vamp+) Marathon/Chronos
Ressource Allocation - Swarm Master Kublet Info Service Mesos Master
Executor - Swarm Agent Kublet Mesos Slave
High Availability
Routing Definition
Use Cases Single Application
Microservice Application
Web Application 		Distributed Microservice Application Distributed Microservice Application Distributed Microservice Application
Big Data
Kubernetes / Docker Swarm

<Thank You!>

Demo + Slides Application

Links

Links