Metal, we
need to talk.
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!
We moved a lot of
Applications to the cloud.
Image By BrokenSphere - Own work, CC BY-SA 3.0,
https://commons.wikimedia.org/w/index.php?curid=3893859
19 years before ...
Still doing PHP!
(and a lot of other things :-) )
... but now we've
got an office in Kreuzberg.
Visit us for a beer!
How long have you been doing PHP?
How old is your oldest running PHP Application?
Where it all started ...
Anyone with ..
... Servers in Your own Office?
... Hetzner?
... 1&1 Ionos ?
Database
Monolith
Browser
Server
Highlander Configuration:
There is only one server,
and it does not die anyway.
Yeah, but does it scale?
Is it reliable?
Database-Master
Server
Monolith
Browser
Server
Monolith
Server
Monolith
Server
Load Balancer
Database-Slave
Server
#sharenothing #monolith #ftw
-
Everything under control
-
100% flexibility
-
Your very own security
-
Minimal network latency
-
shared-nothing-architecture:
-
Just add more metal to scale
-
You have to pay for the hardware.
-
for the maximum capability you'll need
-
even if nobody uses it right now
-
including the ecological footprint
#sharenothing #monolith #sad
you have to deal with...
-
scaling
-
monitoring
-
health
-
backup
-
failover
-
...
#sharenothing #monolith #sad
"Marketing did not tell us about our TV ads for Xmas.
Obviously we need more capacity, like 10 servers."
"Ok, i ordered them.
They will be delivered in February."
#sharenothing #monolith #sad
"We got to move
to the cloud."
Rehosting
A.k.a. "Lift and Shift"
Keep the software, change the hardware
-
External:AWS, Azure, Google, Hetzner, Ionos
-
Internal: OpenStack, Vmware, ...
MySQL
Vm
Monolith
Browser
ec2-VM
Monolith
ec2-VM
Monolith
ec2-VM
Load-Balancer VMs
MySQL
Vm
Lift &
Shift
It's 30% cheaper than
on-premise!
(says Amazon)
For 85% more expensive than on-premise!
(says Michael Dell)
... but it's the first step
for a cloud strategy
First win: Replace Services
Scaling, Reliability up
Operational Costs down
Example: MySQL vs RDS vs Aurora
First win: Replace Infrastructure
Single Components like ELB
Orchestration with Beanstalk
Amazon
RDS
Monolith
Browser
ec2-VM
Monolith
ec2-VM
Monolith
ec2-VM
AWS ELB
Lift, Tinker & Shift
The benefit grows
with the cloud adoption?
Vendor Lock-in:
The Instagram Story
24 months to build
12 months to move from AWS to Facebook
Types of Vendor Lock-in
-
Data Lock-in
"I can't move the data structures or amounts easily"
-
Application Lock-in
"I can't move the application logic"
-
Structural Lock-In
"I can't move the integration, communication and interaction of components."
Vendor Control
https://gcemetery.co/
Vendor Control
"Razor & Blades Model"
- Hey, Lambda is cheap
- Ouch, the ApiGateway is expensive
Rehosting
It looks a lot like the original metal, but it's owned by large companies.
Doing it wrong
"Please file an ops ticket to get a new VM. As soon as they get an Ack from the Board they will file an internal ticket, and with a bit of luck you'll get your new VM within a month."
Couldn't we just get every vm on demand?
Who uses docker?
Who uses Kubernetes?
Containerization
Docker, Docker Swarm
Kubernetes, Mesos, OpenStack, OpenShift, LXD
Amazon ECS, GCE
Better Resource Allocation due to shared kernel
Container Image as a Deployment Unit
MySQL Container
+ Persistentvolume
Monolith
Browser
App-Container
Monolith
App-Container
Monolith
App-Container
NGINX Container
Dev-Artefact
===
Deployment Unit
-
the same binary in dev, test & production
-
rollbacks, updates, deploys are easy
No wait state I
2019: 8 Containers per host
"Just small enough to not ask anymore"
No wait state II
Average Lifetime of a container
in orchestrated environments:
12 hours
Ephemeral Containers
Everything is temporary.
Start it, Stop it, destroy it, replicate it, replace it, scale it.
AutoScale!
Finally: proper Utilization
Title Text
The possiblities!
proper orchestration
+ ephemeral containers
==
decompose your application
on deployment and network level.
MicroServices
Losely coupled service oriented architecture with bounded contexts.
MySQL Container
+ Persistentvolume
Monolith
App-Container
Catalog
NGINX Container
MySQL
Order
Postgres
Payment
MongoDB
MicroServices
Componentization via services
(Not Bundles :-) )
MicroServices
Organized around Business Capabilities
(Not technical layers :-) )
MicroServices
Products not Projects
(you built it, you run it)
MicroServices
Smart endpoints and dumb pipes
(there is no service workflow engine or dispatcher)
MicroServices
Decentralized Governance
(You don't have to wait for a decision)
MicroServices
Decentralized Data Management
(There is no shared database)
MicroServices
Infrastructure automation
(There is no coordinated release)
MicroServices
Design for Failure
(Your service isn't down just because another service is down.)
MicroServices
Evolutionary Design
(Services will be replaced by
more services when they grow )
Ouch, do i need to do this?
MicroServices allow to deal with scaling &
high complexity while moving fast.
If that's not your problem (yet),
you shouldn't need to use Microservices.
https://martinfowler.com/bliki/MonolithFirst.html
Reducing Complexity with MicroServices
Constraints that limit complexity:
- Componentization via Service
- Organization around Business Capabilities
- Smart Endpoints and Dump Pipes
- Decentralized Governance
- Decentralized Data Management
- Evolutionary Design
Reducing Complexity with MicroServices
-
Infrastructure Automation
-
Design for Failure
Reducing Complexity with MicroServices
Move complexity to places
where you can automate it
Wouldn't it be great to
automate everything
that is
not actual business logic?
Serverless
Automate All The Things!
- should be "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
- You won't get fired for choosing AWS
Catalog
MySQL
ApiGateway
λ
user-read
RDS
λ
user-delete
λ
user-write
λ
user-update
Observability included
Cloud Native
Up to 10 times faster development
The magic trick to be 10 times faster ...
... remove
90% of the
original work.
Cloud Native
Up to 100 times less
infrastructure costs
Pay as you go
Scale to zero
"If nothing happens, you
don't need to pay anything."
?
Since November 2018 proper support via
"Bring Your Own Runtime" Lambda Layers.
But, but ...
-
Take the afternoon off,
Amazon/Auth0/Slack/Github is down
-
Vendor Lock-in and - even worse: Vendor Control
"External Services are the New Silo"
-
Innovation:
OpenSource -> cloud provider company secrets
- Pricing by value, not by costs:
Expensive API Gateways, anyone?
Kubernetes is the new OS
... on premise
... in the cloud
... on your 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 | PHP-Support | Serverless Framework |
|---|---|---|---|
| OpenWhisk | IBM | Yes | Yes |
| OpenFaaS | VMWare | Yes | Beta |
| Fn | Oracle | 1 Developer | Yes |
| Kubeless | Bitnami | Yes | Yes |
| Fission | Platform9 | Yes | Plugin |
OpenSource FaaS
for K8s
Who is going to win?
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
Cloud Migration
vs
Cloud Native
Your source stays, the metal goes.
Rehosting: "Lift & Shift"
Replacement: "Lift-tinker-and-shift"
Containerize: Dockerize all the things
Neither your source nor your metal stays.
Replacement: Rewrite it all.
Using just 10% of code .
Rearchitecting: Stepwise migration of
your Software
Rearchitecting & Modernizing
We did this a lot, but
this is another 500 slides deck :-)
Ask me about it :-)
Ok, and what should
i do now?
- Low Application Complexity
- Low Operation Costs
- No scaling or reliability issues
- You got your own million-host-cloud
- High Complexity
- Development slowing down
- > 2 Teams
- Large & volatile traffic
- Average complexity
- High operation costs
- Scaling or Reliability needs or
large & volatile traffic
- Average Complexity
- High Business Performance
- Ability to scale is critical
- Need for fast experimentation
- Trusted environment needed
- K8s "run everywhere"
- High security setups
- K8s experts inhouse
- Containerization
- Rehosting: Lift & Shift
- Tinker: Replace Database, Auth, ...
- Rearchitecting: Cut or Replace
From Metal 2 Cloud: Stairway to Heaven
Questions?
Your own experiences?
Everybody should know:
twitter @johannhartmann
Just You and me:
hartmann@mayflower.de
Thank You!
Migration, with a metal background
By Johann-Peter Hartmann
Migration, with a metal background
Your CEO showed up and asked you whether your software runs "in the cloud". And while you think of your well tuned Hetzner setup – that has been running smoothly for seven years in a row now – you nod and say "Yes, it’s running on a container infrastructure", because at least some of the newer things are dockerized. Why should you move to "the cloud" anyway? This talk discusses the different strategies starting with a simple EC2-based virtualization and ending with a full cloud-native replacement, their advantages and their drawbacks.
