Content
- Serverless in the context of DevOps
- Function-as-a-Service
- Tradeoffs
- Demo
at the beginning there was an
APP
and the app was code
that needed to scale
👉 microservices
Deployment
Containers: lightweight VMs
- 12 factor app
- easier deploy
- reproducible build
but ...
Deployment concerns
- Scaling up and down
- Redundancy
- Scheduling / Orchestration
- Service Discovery
- Resiliency
- Rolling out and back
- Health checks
- Secret and config
➡️ kubernetes
but ...
Kubernetes concerns
- Logging
- Tracing
- Metrics
- Dependency visualisation
- Service identity and Auth
- Circuit breaking
- Traffic flow and policies
- Failover
- Fault injection
- ...
➡️ ️ use code?
drawbacks
- combination language/framework/version/feature
- maintain, upgrade, migrate, retire
- code pollution and complexity (+ testing)
- deployment / rolling update
- language/framework/version lock-in
- debugging
➡️ ️ move it to the infrastructure
overwhelmed yet ?
it's normal
Questions ?
SERVERLESS
Abstraction layer
- serverless 👉 less servers
- DevOps - Ops = Dev
- Deploy functions 👉 FaaS
It is serverless the same way WiFi is wireless. At some point, it will hit a wire.
—
Gojko Adzic
I don't understand this abstraction
sourceMental limitations
- # decisions / day
- # things to remember
- speed of memory / reflexes
We could build it
BUT
spending time on the business
makes more sense financially
tradeoffs
Developer time (build)
Use a product (buy)
On premise: fixed price and capacity
Cloud: pay for what you use
latency versus throughput
cold start ?
👉 strategy
Why deploying Go functions ?
Focus on:
- code
- business features
- security
- monitoring
- performance
- productivity
- SLI/SLO/SLA
- cost/resource optimization
THANK YOU
and I'm sorry 🙏
If you had to maintain my code
I hope you learned more by maintaining it
than me by writing it
contact
https://bisconti.cloud/
@julienBisconti
Slides made with Reveal.js and hugo-reveal