Per Anhalter durch den Cloud Native Stack (extended edition)

| OOP 2017 | A Hitchhiker’s Guide to the Cloud Native Stack | @adersberger @LeanderReimer #cloudnativenerd #qaware

PER ANHALTER DURCH DEN

CLOUD NATIVE STACK

1

Mario-Leander Reimer Cheftechnologe

Kontakt Mail: [email protected] Twitter: @LeanderReimer

• Vollblut Entwickler && Architekt

• #CloudNativeNerd

• Open Source Enthusiast


Let’s talk about Cloud Native Applications

3

#GIFEE Google’s�(and Facebook’s, Twitter’s, Airbnb’s, ...)

Infrastructure�

For�

Everyone�

Else

CONTINUOUS DELIVERY & DEVOPS

ANTIFRAGILITYHYPERSCALE TRAFFIC, DATA, FEATURES

OPEX SAVINGS(automation & utilization)

CLOUD NATIVE APPLICATIONS

DISR

UPT

INDU

STRI

ALIZ

E

PACKAGED AND DISTRIBUTED AS CONTAINERS

BUILD AND COMPOSED AS MICROSERVICES

DYNAMICALLY EXECUTED IN THE CLOUD

CLOUD NATIVE APPLICATIONS

3 KE

Y PR

INCI

PLES

„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.

8


Design Prinzipien Cloud-nativer Anwendungen

• Design for Performance: responsive; concurrency; efficiency.

• Design for Automation: automate dev tasks & ops tasks.

• Design for Resiliency: fault-tolerant; self-healing.

• Design for Elasticity: dynamically scale; be reactive.

• Design for Delivery: short roundtrips; automated delivery.

• Design for Diagnosability: cluster-wide logs, traces, metrics.

9


Maturity Model Cloud-nativer Anwendungen

10

https://www.opendatacenteralliance.org/docs/architecting_cloud_aware_applications.pdf

Level 0: Virtualized

Level 1: Loosely Coupled

Level 2: Abstracted

Level 3: AdaptiveCloud 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

11

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.

13

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

14

Containerization

Microservices

dockercompose


MICROSERVICES

15

3


2002

17

Items

Registration

Buying


2008

18

Additional Services


2011

19

Additional Services


Bad News.

20

§ “[…] 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

21

Additional Services


Good News.

22

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 that some 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 against the 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 about 10 CPU cores and 28Gb RAM.”

§ “On Thanksgiving weekend, Walmart servers 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 efficiencySuitable scalability

Enabled new kinds of applications ( IoT, mobile, APIs)

to compete globally

3

WHAT DID THEY DO?


Die Antwort: Dekomposition.

24


• Planning unit

• Team assignment unit

• Development unit

• Integration unit

Komponenten entlang des Software-Lebenszyklus

25

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

| OOP 2017 | A Hitchhiker’s Guide to the Cloud Native Stack | @adersberger @LeanderReimer #cloudnativenerd #qaware26

System

Subsystem

Komponenten

Services

Monolith

Macroservices

Microservices

Nanoservices

Good starting point

Dev Components Ops Components?:1

Decomposition Trade-Offs + More flexible 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


Zwitscher Microservice in 10 Minuten

27

Zwitscher Controller

Zwitscher Repository

/tweets

ZwitscherServiceApp

search(…)


CONTAINERIZATION

28


$ docker build -t zwitscher-service:1.0.1 .

$ docker run --name zwitscher-service -d \ -p 8080:8080 zwitscher-service:1.0.1

$ docker tag zwitscher-service:1.0.1 hitchhikersguide/zwitscher-service:latest $ docker push hitchhikersguide/zwitscher-service

Der Containerization Workflow mit Docker

29

3. Tag & Push

2. Run

Dockerfile

1. Build


Beispiel Dockerfile für Zwitscher Service

30

FROM qaware/alpine-k8s-ibmjava8:8.0-3.10 MAINTAINER QAware GmbH <[email protected]>RUN mkdir -p /appCOPY build/libs/zwitscher-service-1.0.1.jar /app/zwitscher-service.jar COPY src/main/docker/zwitscher-service.conf /app/EXPOSE 8080CMD /app/zwitscher-service.jar


Wichtige 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.

• Definiere Umgebungs-Variablen für wichtige Parameter.

• Nutze ein Image für alle Umgebungen.

• Versioniere deine Images.

• Verwende Tools zur QS von Dockerfiles und Images.

31


COMPOSITION

32


Cluster-weite Konfiguration 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


Zwitscher Controller

Zwitscher Repository

/tweets

ZwitscherServiceApp

/zwitscher-service/*

Discovery

Configure

Actuator

/adm

in/h

ealt

hRegister

Read

K/V

Get Services

/prometheus


Beispiel docker-compose.yml

35

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

dockercompose


ORCHESTRATION

36


zwitscher-traefik

Kubernetes DNSzwitscher-consul

zwitscher-service

Manage

Manage

Manage

Resolve

Ops


Einfaches K8S Setup in der Cloud oder Lokal

38

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

39

Master

Minion

API Server

Controller Manager

Scheduler

etcd kubelet

kube-proxy

Container Engine(Docker / rkt)

PodPodPod C1 … Cn

UsersAdmin


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 Identifikation verwendet werden

40

Deployment

Service

Replica Set

Pod

Container

Container

DNS Name

Labe

ls: <

K,V>

Port

Volume


Kubernetisierung: Single oder Multi-Container Pod?

POD DeploymentPOD Deployment

41

POD Deployment

POD Deployment

POD Deployment

ZWITSCHER-BOARD

ZWITSCHER-TRAEFIK

ZWITSCHER-CONSUL

ZWITSCHER-MONITORZWITSCHER-SERVICE

Service Service Service

Service

Service


Deployment Definition für Zwitscher Service

42

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 Definition pro Deployment

43

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 Definition von Resource Constraints

44

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

45

# 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


Aufbau einer K8S-only Deployment Variante.

46

zwitscher-service

Manage

Manage

Ops

zwitscher-board

IngressDNS

ConfigMap


Auch der Spaß kommt nicht zu kurz.

• Standard MIDI Controller

• Visualisiert Deployments und Pods

• Skaliert Deployments

• Funktioniert auch für DC/OS

• http://github.com/qaware/kubepad/

47


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.

49


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 Netflix OSS: Cloud-native Anwendungen bauenhttps://goo.gl/edNlUK

• Cloud-native Anwendungen mit Kuberneteshttps://goo.gl/dVkoyR

• Eine Einführung in Apache Mesos: Das Betriebsystem der Cloudhttps://goo.gl/7SnMZA

50


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.

52

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

&

Data & Analytics

Per Anhalter durch den Cloud Native Stack (extended edition)