SLO vs. SLA
Related service Custom software · everything else
DEFINITION
An SLO (Service Level Objective) is an internal target · 'p99 `/checkout` success 99.9% over 30 days'. An SLA (Service Level Agreement) is a contractual promise to the customer, usually with penalties · 'fall below 99.5% and we credit you'. The SLA is always looser than the SLO so you have headroom. The SLI is the underlying metric the SLO is built on (latency, error rate, freshness). Mixing the three gets you double trouble: either an overly strict contract, or no internal alerting signal.
- Docker→
We package an app with its dependencies into an image, which runs as a container - identical on your laptop and in production. "Works on my machine" stops being an excuse.
- CI/CD→
Continuous Integration / Delivery: every commit is automatically built, tested and (optionally) deployed. This pipeline lets us ship safely many times a day, without manual mistakes.
- Blue-Green Deployment→
We run two identical environments: blue is live, green is the new version. Once green is verified we flip traffic to it; on trouble we flip back instantly. Zero-downtime releases with instant rollback.
- Horizontal Scaling→
We add more machines/instances (scale out) instead of one bigger box (vertical, scale up). For stateless services this wins: cheaper, more elastic, no ceiling. State goes to a separate store.
- Load Balancer→
Distributes incoming traffic across multiple instances - the front door that gives you redundancy and smooth scaling. Health checks remove dead instances, so one failure stays invisible to users.
- Distributed Tracing→
We follow one request across every service using a trace ID (e.g. OpenTelemetry). In a microservices system this is how we pinpoint which service slowed down or failed - no guessing.
No posts cite this term yet.