Metal, we
need to talk.

Wir hatten eine grossartige Zeit.

Aber ich habe da jemand neues kennengelernt.

Cloud Native

68% of the companies have started to adopt a cloud native infrastructure

O'Reilly 2019

Cloud Native

Up to 10 times
faster development.

Cloud Native

Up to 100 times less
infrastructure costs

Johann

@ Mayflower

Hi!

Wir haben viele Applikationen modernisiert und in die Cloud gebracht.

Image By BrokenSphere - Own work, CC BY-SA 3.0,
https://commons.wikimedia.org/w/index.php?curid=3893859

Wie alt ist Eure älteste
Applikation in Betrieb?

Wie es alles anfing ...

Jemand da mit ...

... aussenerreichbaren Servern im Office?

... Hetzner? 

... 1&1 Ionos ? 

Database

Monolith

Browser

Server

Highlander Setup:

Es kann nur einen geben!
Er stirbt ohnehin nicht.

Das skaliert nicht.
Und es ist nicht verlässlich.

Database-Master
Server

Monolith

Browser

Server

Monolith

Server

Monolith

Server

Load Balancer

Database-Slave
Server

#sharenothing #monolith #ftw

  • Einfaches Basis-Setp

  • 100% Kontrolle + Flexibilität 

  • Minimale Network Latency

  • Shared-Nothing-Architecture:

    • quasi-lineares Skalieren über Blech

Ich muss die Hardware bezahlen

  • und zwar für den maximalen Bedarf

  • auch dann, wenn niemand sie nutzt

  • inklusive des ökologischen Footprints

#sharenothing #monolith #sad

Mit den Anwendungen wächst die Komplexität ...

  • Skalieren

  • Monitoring

  • Health

  • Backup/Recovery

  • Failover

  • ...

#sharenothing #monolith #sad

"Marketing hat ein Ticket eingestellt, nächste Woche kommt die Fernsehwerbung. Wir brauchen 20 neue Server."
 

"Ich habe sie gerade bei Dell bestellt, in
 2 Monaten sind sie da."

#sharenothing #monolith #sad

"Wir gehen in die Cloud."

Rehosting

A.k.a. "Lift and Shift"

software behalten, hardware wechseln
 

  • Extern:AWS, Azure, Google, Hetzner, Ionos

  • Intern: OpenStack, Vmware, ...

MySQL
Vm

Monolith

Browser

ec2-VM

Monolith

ec2-VM

Monolith

ec2-VM

Load-Balancer VMs

MySQL
Vm

Lift &
Shift

30% billiger als
on-premise!

(sagt Amazon)

Für 85% der Anwendungen teurer als  on-premise!

(sagt Dell)

... aber es ist der erste Schritt in Richtung Cloud.

(Und für viele Firmen
heute  der Status Quo)

Lift & Shift -
Das gleiche wie vorher,
nur teurer?

Service Replacement


Scaling, Reliability hoch
Operative Kosten runter
 

 

Beispiel: MySQL vs RDS vs Aurora

 

Infrastructure Automation


Infrastruktur von Hardware-LB zu ELB Orchestration mit Beanstalk

Operative Kosten runter

 

Amazon
RDS

Monolith

Browser

ec2-VM

Monolith

ec2-VM

Monolith

ec2-VM

AWS ELB

Lift, Tinker & Shift

"Replatforming"

Mehr Benefit durch
mehr Cloud!

Vendor Lock-in:
The Instagram Story

24 Monate um die Lösung zu bauen

12 Monate um die Lösung aus AWS zu holen

Typen von Vendor Lock-in

  • Data Lock-in
    "Die Daten und Datenstrukturen bekomme ich nicht herausgelöst."
     
  • Application Lock-in
    "Ich kann meinen Code nicht umziehen."
     
  • Structural Lock-In
    "Ich kann die Integration, Kommunikation und interaktion von Komponenten nicht umziehen."

Vendor Control

https://gcemetery.co/

Vendor Control

"Razor & Blades Model"

  • Billiger Einstieg, Teuer in Summa
  • Hey, Lambda is cheap
  • Ouch, the ApiGateway is expensive

Cloud-Migration gone bad

"Bitte ein Ticket ans Tec-Board für die neue VM. Die priorisieren das dann ein, und dann geht das in die Ops-Pipeline. Aktuell sind das da gerade 2 Monate,
ausser wir machen Fast Lane."

Könnten wir nicht einfach jede VM selbst klicken?

Wer nutzt Docker?

Wer nutzt Kubernetes?

Containerization

Docker, Docker Swarm

Kubernetes, Mesos, OpenStack, OpenShift, LXD

Amazon ECS, GCE

Bessere Ressourcenallocation durch gemeinsamen Kernel.
 

Container Image as a Deployment Unit

MySQL Container
+ Persistentvolume

Monolith

Browser

App-Container

Monolith

App-Container

Monolith

App-Container

NGINX Container

Die neue VM?

Dev-Artefakt
ist auch die
Deployment Unit

  • das gleiche Binary in dev, test & production

  • rollbacks, updates, deploys sind einfach

No more wait state I

 

2019: 8 Container per Host

"Klein genug um es nicht
genehmigen zu müssen"

No more wait state II

 

Mittlere Lebenszeit von Containern
in orchestrierten Environments:
12 Stunden

Klein genug um
jederzeit zu deployen.

Ephemeral Containers

Nichts ist für immer.


Start it, Stop it, destroy it, replicate it, replace it, scale it.

AutoScale!

Endlich: vernünftige Utilization

Title Text

The possiblities!

gute Orchestrierung

+ ephemeral Container

==

Dekomposition der Application
auf  Deployment- und Netzwerk-Ebene

MicroServices

Lose gekoppelte
Service-orientierte Architecture mit bounded contexts.

MySQL Container
+ Persistentvolume

Monolith

App-Container

Catalog

NGINX Container

MySQL

Order

Postgres

Payment

MongoDB

MicroServices

Zerlegung über Services

 

(nicht Module, Libraries, bundles, GEMs)

MicroServices

Organisiert auf Basis von Business Capabilities

(nicht technischen Funktionen/Layers  :-) )

MicroServices

Produkte nicht Projekte

 

(you built it, you run it)

MicroServices

Smart endpoints and dumb pipes

 

(Da ist keine Middleware, keine Workflow- oder Rules-Engine)

MicroServices

Decentralized Governance

 

(Keine externe Abhängigkeit bei Entscheidungen)

MicroServices

Decentralized Data Management

 

(Es gibt keine gemeinsam zu koordinierende Datenbank)

MicroServices

Infrastructure automation

 

(Es gibt keine koordinierten Releases)

MicroServices

Design for Failure

 

(Es gibt keine koordinierte Fehlerbehandlung)

MicroServices

Evolutionary Design

 

(Es gibt keine koordinierte Architekturstrategie)

Ouch, muss das wirklich sein?

MicroServices erlauben Skalieren
über Teams &

hohe Komplexität bei hoher Geschwindigkeit.

 

Wenn man das problem (noch) nicht hat,
sollte man auch keine MicroServices nutzen.

https://martinfowler.com/bliki/MonolithFirst.html

Komplexität mit MicroServices reduzieren

Rahmen, die Komplexität limitieren:

  • kleinere Services statt Monolithen
  • nur ein Business-Aspekt pro Service
  • Smart Endpoints and Dumb Pipes
  • dezentralisierte Governance
  • dezentralisiertes Datenmanagement
  • lokale Architekturhoheit

Komplexität mit MicroServices reduzieren

  • Infrastrukturautomatisierung

  • Design for Failure


Move complexity to places

where you can automate it

Wäre es nicht super,
jegliche Komplexität,
die nicht Businesslogik ist,
zu automatisieren?

Serverless

Automate All The Things!

  • sollte eigentlich "service-full"
    • Function as a Service / Lambda /λ
    • Serverless databases / Aurora etc
    • SQS, SNS, ELB, Route53, ...
  • Function as a deploy unit
  • Pay-as-you-go
  • Scaling is a solved problem
  • Event-driven

Serverless

Replace all the things!

  • Commodity-Services aus der Plattform
    • Authentifzierung
    • Payment
    • DataAnalytics
    • ML
    • ...
  • Externe Services als SAAS
    • Auth0 & co
    • You name it

Catalog

MySQL

ApiGateway

λ

user-read

RDS

λ

user-delete

λ

user-write

λ

user-update

Observability included

Cloud Native

Up to 10 times faster development

Der Trick 10 mal schneller zu arbeiten ...

... ist
90% der Arbeit

wegzulassen.

Cloud Native

Bis zu 100 mal kleinere Infrastrukturkosten

Pay as you go
Scale to zero

 

"Ich zahle nicht für die Maximalauslastung + Reserve."

But, but ...

  • Nimm den Nachmittag frei,
    Amazon/Auth0/Slack/Github ist down

     
  • Vendor Control is the new Vendor Lock-in
    "External Services are the New Silo"
     
  • Innovationskiller ...
    Von Opensource zu Cloud-Anbieter Company Secrets

     
  • Pricing by value, not by costs:
    Expensive API Gateways, anyone?

Kubernetes is the new OS

... on premise

... in der Cloud

... auf Deinem Laptop

... on the Edge (tbd)

Service Meshes

Automate All the Things - for Kubernetes!

  • ISTIO, Linkerd (2),Consul
  • Load Balancing, FailOver, Retries
  • Traffic control, Routing, Service Discovery
  • CircuitBreakers, Health Checks
  • access control, rate limits
  • rich metrics, logs, traces
  • secure, authenticated & authorized communication
  • Canary deployments, Fault Injection

Ok, Microservices: check.

What about serverless?

Platform Company Multi-Language-Support Serverless
Framework
OpenWhisk IBM Good Yes
OpenFaaS VMWare Good Beta
Fn Oracle Medium Yes
Kubeless Bitnami Good Yes
Fission Platform9 Good Plugin

OpenSource FaaS
for K8s

Wer wird gewinnen?

OpenSource FaaS
for K8s

Knative

Vendor-agnostic cloud native/serverless plattform for kubernetes

Google, Pivotal, IBM, Red Hat, SAP

Source to Url:


Push Code to Github,
get a URL-adressable Endpoint

Knative

Vendor-agnostic cloud native/serverless plattform for kubernetes

Based on Istio

Component
Serving Auto-Scaling with scale to zero
Build Cloud-native from source to production
Events Event-infrastructure for container services and functions

Knative as a Service: Google Cloud Run,
Gitlab Serverless, IBM, SAP
Triggermesh: Lambda!

Recap:
Shades of Cloud

Der Sourcecode bleibt, das Metall geht.

Rehosting: "Lift & Shift"

Replacement: "Lift-tinker-and-shift"

Containerize: Dockerize all the things

Weder Source noch Metal bleiben.
 

Replacement: Rewrite it all.
                           Using just 10% of code .

Rearchitecting: Stepwise migration of

                               your Software

Rearchitecting & Modernizing

Dafür habe ich 500 andere Slides :-)

 Fragt mich dazu :-)

Ok, und was
mache ich jetzt?

  • Kleine Applikationskomplexität
  • Kleine Server & Ops-Kosten
  • Keine Scaling oder Reliabilityprobleme
  • Hohe Komplexität
  • Development langsamer als nötig
  • > 2 Teams
  • Sehr grosser & volatiler Traffic
  • Mittlere Komplexität
     
  • Hohe Server / Ops-Kosten
     
  • Bedarf an schneller und weitreichender Skalierung
  • Mittlere Komplexität
     
  • Hohe Business-Geschwindigkeit
     
  • Fähigkeit zum schnelle skalieren ist kritisch
     
  • Time2Market ist höchste Prio
  • Vertrauenswürdige Umgebung
     
  • "Run Everywhere" 2.0
     
  • High Security Setups
     
  • K8s Experten inhouse
  1. Containerization
  2. Rehosting: Lift & Shift
  3. Tinker: Replace Database, Auth, ...
  4. Rearchitecting: Cut or Replace

From Metal 2 Cloud: Stairway to Heaven

Fragen?
Meine Fehler? Anmerkungen?

Everybody should know:
twitter @johannhartmann
 

Just You and me:
hartmann@mayflower.de

Danke!

Migration, mit einem Metal-Background

By Johann-Peter Hartmann

Migration, mit einem Metal-Background

Der Chef schaut vrobei und fragt,ob wir denn schon "in der Cloud" sind. Und während man an das seit 7 Jahren stabil laufenden Hetzner-Setup denkt antwortet man "Ja, wir haben für die neuen Projekte eine Container-Infrastruktur." Aber warum eigentlich in die Cloud? Weil man das heute so macht müssen alle die Dinge, die gut klappen, auf einmal woanders laufen? Wann lohnt es sich, und wie?

  • 600
Loading comments...

More from Johann-Peter Hartmann