A Hitchhiker’s Guide to the Cloud Native Stack. #DevoxxPL

@LeanderReimer#DevoxxPL
Platinum Sponsor:
A Hitchhiker’s Guide to the
Cloud Native Stack
Mario-Leander Reimer
QAware GmbH

Mail: mario-leander.reimer@qaware.de
Github: https://github.com/lreimer
Slides: https://speakerdeck.com/lreimer
• Developer & Architect
• 20+ years of experience
• #CloudNativeNerd
• Open Source Enthusiast
Chief Technologist, QAware GmbH

Let’s talk about Cloud Native Applications.

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

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

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

7
The 5 Cloud Commandments:
1. Everything Fails All The Time.
2. Focus on MTTR not MTTF.
3. Know the Eight Fallacies of Distributed Computing.
4. Scale out, not up.
5. Treat resources as cattle not as pets.
picture alliance / United Archive

• Design for Distribution: Containers; microservices; API driven development.
• Design for Performance: Responsive; concurrent; resource efficient.
• Design for Automation: Automated Dev & Ops tasks.
• Design for Resiliency: Fault-tolerant and self-healing.
• Design for Elasticity: Scales dynamically and reacts to stimuli.
• Design for Delivery: Short roundtrips and automated provisioning.
• Design for Diagnosability: Cluster-wide logs, metrics and traces.
Design Principles for Cloud Native Applications.

Different Levels of Cloud Native Application Maturity.
•Scales dynamically based on stimuli.
•Dynamic infrastructure migration without 
service downtime.
Level 3: Cloud Native
•Fault tolerant and resilient design.
•Metrics and monitoring built-in.
•Runs anywhere. Infrastructure agnostic.
Level 2: Cloud Resilient
•Consists of loosely coupled systems.
•Services can be found by name.
•Adheres to the 12-factor app principles.
Level 1: Cloud Friendly
•No file system requirements.
•Runs on virtualized hardware.
•Executed as self-contained image.
Level 0: Cloud Ready
Maturity
https://www.opendatacenteralliance.org/docs/architecting_cloud_aware_applications.pdf

The Anatomy of the Cloud Native Stack.
Application Platform Cloud Native App
Cluster Orchestrator Applications
Cluster Scheduler Containers
Cluster Virtualization Resources
Cluster Operating System
Monolith
How to decouple
from physical
hardware?
How to provide the
right resources for
container execution?
How to run (containerized)
applications on a cluster? 
How to automate standard
operations procedures?
What infrastructure to
provide to cloud native
applications?

A Cloud Native Stack with Spring Cloud and K8s.
Application Platform Cloud Native App
Cluster Orchestrator Applications
Cluster Scheduler Containers
Cluster Virtualization Resources
Cluster Operating System
Monolith

(1) Microservices
(2) Containerization
(3) Composition
(4) Orchestration
The 4 Phases of Cloud Native App Development.
Orchestration
Composition
Containerization
Microservices
docker
compose

DemoMicroservices

2002. Buying
Registration
Items
Categories
Services

2008. Additional
Service

2011. Additional
Service

Bad News.
Very long 
release cycles.
Limited 
scalability.

2016.
Additional
Service

Good News.
1000 deployments a day …
… triggered by dev teams.
~ 100% availability
Resource efficiency
Suitable scalability
Enabled new kinds of
applications ( IoT, mobile, APIs)
to compete globally

The (obvious) answer: Decomposition.

Cloud Native Application Development: Components All
Along the Software Lifecycle.
DESIGN BUILD RUN
• Complexity unit
• Data integrity unit
• Coherent and cohesive
features unit
• Decoupled unit
• Planning unit
• Team assignment unit
• Knowledge unit
• Development unit
• Integration unit
• Release unit
• Deployment unit
• Runtime unit  
(crash, slow-down, access)
• Scaling unit
Design Components
Dev Components
Ops Components
1:1 n:1
NEW!

Dev Components Ops Components?:1
System
Subsystems
Components
Services
Good starting point
Decomposition Trade-Offs
Microservices
Nanoservices
Macroservices
Monolith
+ More flexible to scale
+ Runtime isolation (crash, slow-down, …)
+ Independent releases, deployments, teams
+ Higher utilization possible
− Distribution debt: Latency
− Increasing infrastructure complexity
− Increasing troubleshooting complexity
− Increasing integration complexity

A simple Zwitscher microservices using Spring Cloud.
Zwitscher
Controller
Zwitscher
Repository
/tweets
API
ZwitscherServiceApp
search(…)
https://github.com/qaware/hitchhikers-guide-cloudnative

DemoContainerization

Hardware vs. OS Virtualization.
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
VirtualMachine
Container
Isolated Hardware Isolated NW-interface, process space, file system
*) HSI = Hardware Software Interface
SCI = System Call Interface
▪ Less volume of private copy
▪ Near zero runtime overhead
▪ Short start-up time
▪ Stong isolation

Developer’s Perspective of the Docker Workflow.
$ 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

Example Dockerfile
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/ 
ENV JAVA_OPTS –Xmx256m
 
EXPOSE 8080 
CMD /app/zwitscher-service.jar

• A Dockerfile is code! Treat it as 1st class citizen.
• Know your base image. Size matters.
• Chain RUN commands. Use intelligent layering.
• Remove temporary files and directories.
• Define ENV variables for important parameters.
• Use one image for all your environments.
• Version your images.
• Use quality tools to check Dockerfiles and images.
Some useful Tips on using Docker.

DemoComposition

Microservices need an Ecosystem to run in.
How to access
endpoints from
the outside?
How to expose
and find service
endpoints?
How to execute an
ops component?
How to call other
endpoints resilient
and responsive?
How to detect and
resolve operational
anomalies?
How to provide cluster-
wide configuration and
consensus?

Netflix
Zuul

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

Example docker-compose.yaml
version: '3' 
services:
zwitscher-consul:
...
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
ports:
- "8080:8080"
networks:
- zwitscher-net
$ docker-compose build
$ docker-compose up –d --build
$ docker-compose logs
$ docker-compose down

DemoOrchestration

Easy K8s Setup: Local, Bare Metal, Cloud or Managed.
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

Conceptual View on K8s Building Blocks.
Master
Worker
API Server
Controller Manager
Scheduler
etcd kubelet
kube-proxy
Container Engine 
(Docker / rkt)
PodPodPod C1 … Cn
Users
Admin

• Services are an abstraction for a
logical collection of pods.
• Pods are the smallest unit of compute
in Kubernetes
• Deployments are an abstraction used
to declare and update pods, RCs, …
• Replica Sets ensure that the desired
number of pod replicas are running
• Labels are key/value pairs used to
identify Kubernetes resources
Most important K8s concepts and terms.
Deployment
Service
Replica
Set
 
Pod
Container
Container
DNS Name
Labels:<K,V>
Port
Volume

Single or Multi Container Pods?
DeploymentDeployment Deployment
Deployment
Deployment
ZWITSCHER-BOARD
ZWITSCHER-CONSUL
ZWITSCHER-MONITORZWITSCHER-SERVICE
Service Service Service
Service
Service
ZWITSCHER-TRAEFIK

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

K8S-only Deployment Variant.
zwitscher-service
Manage
Manage
Ops
zwitscher-board
Ingress
DNS
ConfigMap

Example K8s Deployment Definition.
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

Define Resource Constraints carefully.
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 and Readiness Probes for Actuator URLs.
# 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

Example K8s Service Definition.
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

• Programmable MIDI Controller.
• Visualizes Deployments and Pods.
• Scales Deployments.
• Supports K8s, OpenShift, DC/OS.
• http://github.com/qaware/kubepad/
Let’s have some fun with K8s!

• Building distributed systems is hard!
• The Cloud Native Stack hides most of the inherent complexity.
• High abstraction: Boon and Bane of software development.
• Developers and architects need additional skills and know-how.
• Favour gradual transition over big bang cloud migration
No magic! Just complex technology.

Please vote for
this talk.

&&
Chief Technologist, QAware GmbH
mario-leander.reimer@qaware.de
https://www.qaware.de
https://speakerdeck.com/lreimer/

A Hitchhiker’s Guide to the Cloud Native Stack. #DevoxxPL

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie A Hitchhiker’s Guide to the Cloud Native Stack. #DevoxxPL

Ähnlich wie A Hitchhiker’s Guide to the Cloud Native Stack. #DevoxxPL (20)

Mehr von Mario-Leander Reimer

Mehr von Mario-Leander Reimer (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

A Hitchhiker’s Guide to the Cloud Native Stack. #DevoxxPL