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-Setup
-
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
- Containerization
- Rehosting: Lift & Shift
- Tinker: Replace Database, Auth, ...
- 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?
- 29
