Per Anhalter durch den Cloud Native Stack. #SEACONHH

| SEACON 2017 | Per Anhalter durch den Cloud Native Stack | @LeanderReimer #cloudnativenerd #qaware
PER ANHALTER
DURCH DEN
CLOUD NATIVE
STACK
1

#GIFEE Google’s
(and Facebook’s, Twitter’s, Airbnb’s, ...)
Infrastructure
For
Everyone
Else

Let’s talk about Cloud Native Applications
3

CONTINUOUS 
DELIVERY & DEVOPS
ANTIFRAGILITY
HYPERSCALE  
TRAFFIC, DATA, FEATURES
OPEX SAVINGS 
(automation & utilization)
CLOUD NATIVE APPLICATIONS
DISRUPTINDUSTRIALIZE

PACKAGED AND
DISTRIBUTED AS CONTAINERS
BUILD AND COMPOSED
AS MICROSERVICES
DYNAMICALLY
EXECUTED IN THE CLOUD
CLOUD NATIVE APPLICATIONS
3KEYPRINCIPLES

„There ain’t no such thing as a free lunch.“
Robert A. Heinlein, 1966, The Moon Is a Harsh Mistress

Die 5 Gebote der Cloud.
1. Everything Fails All The Time.
2. Focus on MTTR and not on MTTF.
3. Know the Eight Fallacies of Distributed Computing.
4. Scale out, not up.
5. Treat resources as cattle, not pets.
7

Design Prinzipien Cloud-nativer Anwendungen
• Design for Distribution: Container, Microservices, API-getriebene Entwicklung
• Design for Performance: Responsive, nebenläuﬁg, Ressourcen schonend.
• Design for Automation: Dev- und Ops-Aufgaben automatisieren.
• Design for Resiliency: Fehlertolerant und selbst-heilend.
• Design for Elasticity: Dynamisch skalierbar und reaktiv.
• Design for Delivery: Kurze Roundtrips und automatisierte Provisionierung.
• Design for Diagnosability: Cluster-weite Logs, Metriken und Traces.
8

Maturity Model Cloud-nativer Anwendungen
9
https://www.opendatacenteralliance.org/docs/architecting_cloud_aware_applications.pdf
Level 0: Virtualized
Level 1: Loosely Coupled
Level 2: Abstracted
Level 3: Adaptive
Cloud Native
- Skaliert elastisch abhängig von Stimuli.
- Dynamische Migration auf andere Infrastruktur 
ohne eine Service Downtime.
Cloud Resilient
- Fehler-tolerant und resilient entworfen.
- Metriken und Monitoring eingebaut.
- Runs anywhere. Infrastruktur agnostisch.
Cloud Friendly
- Besteht aus lose gekoppelten Diensten.
- Dienste können über Namen gefunden werden.
- 12-Factor App Principles.
Cloud Ready
- Keine Anforderungen an das Datei-System.
- Läuft auf virtualisierter Hardware.
- Self-contained, kann als Image ausgeführt werden.

Die Anatomie des Cloud Native Stack
10
Application Platform Cloud Native App
Cluster Orchestrator Applications
Cluster Scheduler Containers
Cluster Virtualization Resources
Cluster Operating System
Entkoppelt
von physischer
Hardware.
Verwaltet
Ressourcen für
die Ausführung
von Containern
Führt
Applikationen
auf dem
Cluster aus.
Stellt Ablauf-
Umgebung und
APIs für Apps
bereit.

Cloud Native Stack mit Spring Cloud und K8S.
12
Application Platform Cloud Native App
Cluster Orchestrator Applications
Cluster Scheduler Containers
Cluster Virtualization Resources

Orchestration
Composition
Die 4 Schritte zur Cloud-nativen Anwendung
1. MICROSERVICES
2. CONTAINERIZATION
3. COMPOSITION
4. ORCHESTRATION
13
Containerization
Microservices
docker
compose

MICROSERVICES
14

2002
16
Items
Registration
Buying

2008
17
Additional
Services

2011
18
Additional
Services

Bad News.
19
§ “[…] it was unable to scale for 6 million pageviews per minute and was down
for most of the day during peak events.”
§ “This is the multi-million dollar question which the IT Department of Walmart
Canada had to address after they were failing to provide to their users on Black
Fridays for two years in a row.”
https://blog.risingstack.com/how-enterprises-benefit-from-microservices-architectures
Walmart auf http://www.oneops.com
Sehr lange
Release-Zyklen
Mangelnde
Skalierbarkeit

2016
20
Additional
Services

Good News.
21
Walmart auf http://www.oneops.com
“They wanted to prepare for the world by 2020, with 4 billion people connected, 25+
million apps available, and 5.200 GB of data for each person on Earth.
Walmart replatformed […] with the intention of achieving close to 100% availability with
reasonable costs.”
https://blog.risingstack.com/how-enterprises-benefit-from-microservices-architectures
§ “In fact, the organization reports thatsome 3,000 engineers […] drive 30,000
changes per month to Walmart software.”
§ “Those new applications,which span everything from mobile devices to the
Internet of things (IoT), are crucial weapons in a global e-commerce contest
that pits Walmart againstthe likes of Amazon and Alibaba,as well as a host of
other rivals that are emerging as the cost of entry into the online retail sector
continues to decline in the age of the API economy.”
http://www.baselinemag.com/enterprise-apps/walmart-embraces-microservices-to-get-
more-agile.html
§ “The Walmart […] servers […] were able to handle all mobile Black Friday
traffic with about10 CPU cores and 28Gb RAM.”
§ “On Thanksgiving weekend,Walmartservers processed 1.5 billion requests
per day. 70 percent of which were delivered through mobile.”
http://techcrunch.com/2014/12/02/walmart-com-reports-biggest-cyber-monday-in-
history-mobile-traffic-at-70-over-the-holidays
1000 deployments a day …
… triggered by dev teams.
~ 100% availability
Resource eﬃciency
Suitable scalability
Enabled new kinds of
applications ( IoT, mobile, APIs)
to compete globally

Die Antwort: Dekomposition.
23

• Planning unit
• Team assignment unit
• Development unit
• Integration unit
Komponenten entlang des Software-Lebenszyklus
24
DESIGN BUILD RUN
Design Components Dev Components Ops Components
• Complexity unit
• Data integrity unit
• Cohesive feature unit
• Decoupled unit
• Release unit
• Deployment unit
• Runtime unit
• Scaling unit
?:11:1

| SEACON 2017 | Per Anhalter durch den Cloud Native Stack | @LeanderReimer #cloudnativenerd #qaware25
System
Subsystem
Komponenten
Services
Monolith
Macroservices
Microservices
Nanoservices
Good starting point
Dev Components Ops Components?:1
Decomposition Trade-Offs
+ More ﬂexible to scale
+ Runtime isolation (crash, slow-down, …)
+ Independent releases, deployments, teams
+ Higher resources utilisation
- Distribution debt: Latency
- Increased infrastructure complexity
- Increased troubleshooting complexity
- Increased integration complexity

Die Anatomie des Zwitscher Microservice
26
Zwitscher
Controller
Zwitscher
Repository
/tweets
API
ZwitscherServiceApp
search(…)
https://github.com/qaware/hitchhikers-guide-cloudnative

CONTAINERIZATION
27

Hardware Virtualisierung vs. OS Virtualisierung
28
Real Hardware
Virtual Hardware
OS
OS Libraries
Application
Real Hardware
(Virtual Hardware)
OS
OS Libraries
Application
HSI*
SCI*
Hardware Virtualization OS Virtualization
Private Copy
Shared Resources
§ Less volume of private copy
§ Near zero runtime overhead (RAM, CPU)
§ Short start-up time (~ time to lauch a
process)
§ Stronger Isolation
*) HSI = Hardware Software Interface
SCI = System Call Interface
VirtualMachine
Container
Isolated Hardware Isolated NW-interface, process space, file system

Der Docker Workﬂow
29
$ docker build -t zwitscher-service:1.0.1 .
$ docker run --name zwitscher-service -d
-p 8080:8080 zwitscher-service:1.0.1
$ docker stop zwitscher-service
$ docker start zwitscher-service
$ docker tag zwitscher-service:1.0.1
hitchhikersguide/zwitscher-service:latest
$ docker push hitchhikersguide/zwitscher-service

Beispiel Dockerﬁle für Zwitscher Service
30
FROM qaware/alpine-k8s-ibmjava8:8.0-3.10 
MAINTAINER QAware GmbH <qaware-oss@qaware.de> 
 
RUN mkdir -p /app 
 
COPY build/libs/zwitscher-service-1.0.1.jar /app/zwitscher-service.jar 
COPY src/main/docker/zwitscher-service.conf /app/ 
 
EXPOSE 8080 
CMD /app/zwitscher-service.jar

Einige Tips für den Umgang mit Docker
• Kenne dein Base-Image! Auf die Größe kommt es an.
• Ein Docker Build muss wiederholbar sein.
• Jeder RUN Befehl erzeugt ein Layer. Nutze Mehrfachbefehle!
• Entferne temporäre Dateien.
• Veröffentliche wichtige Ports mit EXPOSE.
• Deﬁniere Umgebungs-Variablen für wichtige Parameter.
• Nutze ein Image für alle Umgebungen.
• Versioniere deine Images.
• Verwende Tools zur QS von Dockerﬁles und Images.
31

COMPOSITION
32

Cluster-weite
Konﬁguration und
Konsensus
Überwachung und
Fehler-Diagnose
Geregelter Zugriff  
auf Service  
Endpoints von Außen
Registrierung und
Suche von Service
Endpoints
Laufzeit-Umgebung
für Service Endpoints
Resistenter Aufruf
von anderen
Service Endpoints

Netflix
Zuul

Zwitscher
Controller
Zwitscher
Repository
/tweets
ZwitscherServiceApp
/zwitscher-service/*
Discovery
Configure
Actuator
/admin/health
Register
Read
K/V
Get Services
/prometheus

Beispiel docker-compose.yml
36
version: '2'
services:
zwitscher-consul:
...
zwitscher-traefik:
...
zwitscher-service:
image: hitchhikersguide/zwitscher-service:1.0.1
environment:
- CONSUL_HOST=zwitscher-consul
- CONSUL_PORT=8500
- TWITTER_APP_ID=${TWITTER_APP_ID}
- TWITTER_APP_SECRET=${TWITTER_APP_SECRET}
depends_on:
- zwitscher-consul
links:
- zwitscher-consul
ports:
- "8080:8080"
networks:
- zwitscher-net
$ docker-compose -p zwitscher up -d
$ docker-compose -p zwitscher ps
$ docker-compose -p zwitscher logs -f
$ docker-compose -p zwitscher down
docker
compose

ORCHESTRATION
37

Verfügbare Cluster Operating Systems
38

Einfaches K8S Setup in der Cloud oder Lokal
39
echo "- Use Vagrant for local K8s setup"
export KUBERNETES_PROVIDER=vagrant
export NUM_NODES=1
echo "- The default provider is GCE"
export KUBERNETES_PROVIDER=gce
export KUBE_GCE_ZONE=europe-west1-d
export NUM_NODES=4
echo "- Another possible provider is AWS"
export KUBERNETES_PROVIDER=aws
export KUBE_AWS_ZONE=eu-central-1a
export NODE_SIZE=t2.small
curl -sS https://get.k8s.io | bash
Minikube

Die Kubernetes Bausteine im Überblick
40
Master
Minion
API Server
Controller Manager
Scheduler
etcd kubelet
kube-proxy
Container Engine 
(Docker / rkt)
PodPodPod C1 … Cn
Users
Admin

Die wichtigsten K8S Konzepte und Begriffe
• Services sind eine Abstraktion für
eine logische Sammlung von Pods
• Pods sind die kleinste deploybare
Compute Einheit in K8S
• Deployments dienen der Deklaration
von Pods, Volumes und RCs
• Replica Sets stellen die geforderte
Anzahl an Replicas sicher
• Labels sind Key/Value Paare die zur
Identiﬁkation verwendet werden
41
Deployment
Service
Replica
Set
 
Pod
Container
Container
DNS Name
Labels:<K,V>
Port
Volume

Kubernetisierung: Single oder Multi-Container Pod?
POD DeploymentPOD Deployment
42
POD Deployment
POD Deployment
POD Deployment
ZWITSCHER-BOARD
ZWITSCHER-TRAEFIK
ZWITSCHER-CONSUL
ZWITSCHER-MONITORZWITSCHER-SERVICE
Service Service Service
Service
Service

zwitscher-traefik
Kubernetes DNS
zwitscher-consul
zwitscher-service
Manage
Manage
Manage
Resolve
Ops

| OOP 2017 | A Hitchhiker’s Guide to the Cloud Native Stack | @adersberger @LeanderReimer #cloudnativenerd #qaware
Aufbau einer K8S-only Zwitscher Variante.
44
zwitscher-service
Manage
Manage
Ops
zwitscher-board
Ingress
DNS
ConfigMap

Deployment Deﬁnition für Zwitscher Service
45
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: zwitscher-service
spec:
replicas: 3
template:
metadata:
labels:
zwitscher: service
spec:
containers:
- name: zwitscher-service
image: "hitchhikersguide/zwitscher-service:1.0.1"
ports:
- containerPort: 8080
env:
- name: CONSUL_HOST
value: zwitscher-consul

K8s Service Deﬁnition pro Deployment
46
apiVersion: v1
kind: Service
metadata:
name: zwitscher-service
labels:
zwitscher: service
spec:
# use NodePort here to be able to access the port on each node
# use LoadBalancer for external load-balanced IP if supported
type: NodePort
ports:
- port: 8080
selector:
zwitscher: service

Vorsicht bei Deﬁnition von Resource Constraints
47
resources:
# Define resources to help K8S scheduler
# CPU is specified in units of cores
# Memory is specified in units of bytes
# required resources for a Pod to be started
requests:
memory: "128Mi"
cpu: "250m"
# the Pod will be restarted if limits are exceeded
limits:
memory: "192Mi"
cpu: "500m"

Liveness und Readiness Probes über Actuator
48
# container will receive requests if probe succeeds
readinessProbe:
httpGet:
path: /admin/info
port: 8080
initialDelaySeconds: 30
timeoutSeconds: 5
# container will be killed if probe fails
livenessProbe:
httpGet:
path: /admin/health
port: 8080
initialDelaySeconds: 90
timeoutSeconds: 10

Let’s have some fun with K8S!
• Standard MIDI Controller
• Visualisiert Deployments und Pods
• Skaliert Deployments
• Funktioniert auch mit OpenShift
• http://github.com/qaware/kubepad/
49

Keine Magie. Aber komplexe Technologie.
• Building Distributed Systems is hard!
• Der Cloud Native Stack macht die Komplexität beherrschbar.
• Die hohe Abstraktion ist Segen und Fluch zugleich.
• Entwickler und Architekten brauchen zusätzliche Skills und Know-
How in etlichen neuen Technologien.
51

Code und Artikel zum Nachlesen unter …
• https://github.com/qaware/hitchhikers-guide-cloudnative
• Der Cloud Stack: Mesos, Kubernetes und Spring Cloud  
https://goo.gl/U5cJAU
• Spring Cloud und Netﬂix OSS: Cloud-native Anwendungen bauen 
https://goo.gl/edNlUK
• Cloud-native Anwendungen mit Kubernetes 
https://goo.gl/dVkoyR
• Eine Einführung in Apache Mesos: Das Betriebsystem der Cloud 
https://goo.gl/7SnMZA
52

CompletableFuture<SoftwareArchitektIn> ich =
CompletableFuture.supplyAsync(()
-> erfindergeist()
.handwerksstolz()
);
CompletableFuture<Projekthaus> qaware =
CompletableFuture.supplyAsync(()
-> professionalität()
.lässigkeit()
);
Erfolg start = qaware.thenCombine(ich,
(i, q) -> i.sendeBewerbung(q))
.join();
Weiter Details unter http://www.qaware.de/karriere/#jobs

42.
THE ANSWER TO LIFE, UNIVERSE,
THE CLOUD AND EVERYTHING.
54

https://www.qaware.de
https://slideshare.net/qaware/
https://github.com/qaware/
&

Per Anhalter durch den Cloud Native Stack. #SEACONHH

Weitere ähnliche Inhalte

Ähnlich wie Per Anhalter durch den Cloud Native Stack. #SEACONHH

Mehr von Mario-Leander Reimer

Per Anhalter durch den Cloud Native Stack. #SEACONHH