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

Cloud native applications are popular these days. They promise superior reliability and almost arbitrary scalability. They follow three key principles: they are built and composed as microservices. They are packaged and distributed in containers. The containers are executed dynamically in the cloud. But which technology is best to build this kind of application? This talk will be your guidebook.

In this hands-on session, we will briefly introduce the core concepts and some key technologies of the cloud native stack and then show how to build, package, compose and orchestrate a cloud native microservice application on top of a cluster operating system such as Kubernetes. To make this session even more entertaining we will be using off-the-shelf MIDI controllers to visualize the concepts and to remote control a Kubernetes cluster.

Transcript

1. @LeanderReimer #DevoxxPL Platinum Sponsor: A Hitchhiker’s Guide to the Cloud Native Stack Mario-Leander Reimer QAware GmbH
2. @LeanderReimer #DevoxxPL 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 Mario-Leander Reimer Chief Technologist, QAware GmbH
3. @LeanderReimer #DevoxxPL Let’s talk about Cloud Native Applications.
4. @LeanderReimer #DevoxxPL DISRUPT INDUSTRIALIZE HYPERSCALE TRAFFIC, DATA, FEATURES CLOUD NATIVE APPLICATIONS ANTIFRAGILITY DEVOPS & 
 CONTINUOUS DELIVERY OPEX SAVINGS (automation & utilization)
5. @LeanderReimer #DevoxxPL 3 KEY PRINCIPLES CLOUD NATIVE APPLICATIONS BUILT AND COMPOSED 
 AS MICROSERVICES PACKAGED AND 
 DISTRIBUTED IN CONTAINERS DYNAMICALLY EXECUTED IN THE CLOUD
6. „There ain’t no such thing as a free lunch.“ Robert A. Heinlein, 1966, The Moon Is a Harsh Mistress
7. 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
8. @LeanderReimer #DevoxxPL • 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.
9. @LeanderReimer #DevoxxPL 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
10. @LeanderReimer #DevoxxPL 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?
11. @LeanderReimer #DevoxxPL
12. @LeanderReimer #DevoxxPL 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
13. @LeanderReimer #DevoxxPL (1) Microservices (2) Containerization (3) Composition (4) Orchestration The 4 Phases of Cloud Native App Development. Orchestration Composition Containerization Microservices docker compose
14. @LeanderReimer #DevoxxPL Demo Microservices
16. @LeanderReimer #DevoxxPL 2002. Buying Registration Items Categories Services
17. @LeanderReimer #DevoxxPL 2008. Additional Service
18. @LeanderReimer #DevoxxPL 2011. Additional Service
19. @LeanderReimer #DevoxxPL Bad News. Very long
 release cycles. Limited
 scalability.
20. @LeanderReimer #DevoxxPL 2016. Additional Service
21. @LeanderReimer #DevoxxPL 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
22. WHAT DID THEY DO?
23. @LeanderReimer #DevoxxPL The (obvious) answer: Decomposition.
24. @LeanderReimer #DevoxxPL 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!
25. @LeanderReimer #DevoxxPL 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
26. @LeanderReimer #DevoxxPL A simple Zwitscher microservices using Spring Cloud. Zwitscher Controller Zwitscher Repository /tweets API ZwitscherServiceApp search(…) https://github.com/qaware/hitchhikers-guide-cloudnative
27. @LeanderReimer #DevoxxPL Demo Containerization
28. @LeanderReimer #DevoxxPL 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 Virtual Machine 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
29. @LeanderReimer #DevoxxPL 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
30. @LeanderReimer #DevoxxPL 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
31. @LeanderReimer #DevoxxPL • 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.
32. @LeanderReimer #DevoxxPL Demo Composition
33. @LeanderReimer #DevoxxPL 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?
34. @LeanderReimer #DevoxxPL Netflix Zuul
35. @LeanderReimer #DevoxxPL Zwitscher Controller Zwitscher Repository /tweets ZwitscherServiceApp /zwitscher-service/* Discovery Configure Actuator /admin/health Register Read K/V Get Services /prometheus
36. @LeanderReimer #DevoxxPL 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
37. @LeanderReimer #DevoxxPL Demo Orchestration
38. @LeanderReimer #DevoxxPL 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
39. @LeanderReimer #DevoxxPL Conceptual View on K8s Building Blocks. Master Worker API Server Controller Manager Scheduler etcd kubelet kube-proxy Container Engine
 (Docker / rkt) Pod Pod Pod C1 … Cn Users Admin
40. @LeanderReimer #DevoxxPL • 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
41. @LeanderReimer #DevoxxPL Single or Multi Container Pods? Deployment Deployment Deployment Deployment Deployment ZWITSCHER-BOARD ZWITSCHER-CONSUL ZWITSCHER-MONITOR ZWITSCHER-SERVICE Service Service Service Service Service ZWITSCHER-TRAEFIK
42. @LeanderReimer #DevoxxPL zwitscher-traefik Kubernetes DNS zwitscher-consul zwitscher-service Manage Manage Manage Resolve Ops
43. @LeanderReimer #DevoxxPL K8S-only Deployment Variant. zwitscher-service Manage Manage Ops zwitscher-board Ingress DNS ConfigMap
44. @LeanderReimer #DevoxxPL 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
45. @LeanderReimer #DevoxxPL 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"
46. @LeanderReimer #DevoxxPL 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
47. @LeanderReimer #DevoxxPL 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
48. @LeanderReimer #DevoxxPL • 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!
49. @LeanderReimer #DevoxxPL
50. @LeanderReimer #DevoxxPL • 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.
51. @LeanderReimer #DevoxxPL Please vote for this talk.
52. @LeanderReimer #DevoxxPL & & Mario-Leander Reimer Chief Technologist, QAware GmbH mario-leander.reimer@qaware.de https://www.qaware.de https://speakerdeck.com/lreimer/