Every Tuesday - Deep dives, architecture lessons, and real engineering stories.
Every Saturday - The best DevOps, SRE, Cloud, AI, tools, tutorials, and projects from the week.
In partnership with
100+ Claude Code hacks to ship code 10X faster
Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.
If you're not using AI, you're spending 40 hours doing what they do in 4.
These 100+ Claude Code hacks fix that and help you ship 10x faster.
Sign up for The Code and get:
100+ Claude Code hacks used by top engineers — free
The Code newsletter — learn the latest AI tools, tips, and skills to code faster with AI in 5 minutes a day
📬 Missed This Week’s Uptime Sync?
This week’s best DevOps, SRE, Cloud, Kubernetes, database, AI infra, and production engineering reads:
PostgreSQL without PgBouncer?
Kubernetes health checks gone wrong
Why Copilot code review got worse
The 2026 FinOps roadmap
ECS for Kubernetes engineers
What to log during incidents
Policy as code, DevSecOps, R2, MySQL, TLS & feature flags
glab-tui, Suzaku, Svix & Starboard
This roadmap focuses on the skills that matter most:
Operating production services
Diagnosing failures
Automating safe delivery
Measuring reliability
Reducing repetitive engineering work
Building useful internal platforms
Understand the Job
SRE and platform engineering are not primarily about Kubernetes, Terraform, or cloud dashboards. They are about making software:
More reliable
Safer to change
Easier to operate
Easier for engineers to deploy and troubleshoot
The roles overlap, but their common goal is improving the software delivery and operations system.
Application teams typically own:
Code and tests
Configuration
Service behaviour
Application-level performance
SRE teams typically improve:
Service-level objectives
Alerting
Incident response
Capacity planning
Reliability practices
Safe change management
Platform teams typically provide reusable capabilities for:
Building services
Deploying software
Observing production
Managing access
Standardising common workflows
Reliability is shared across development, operations, platform engineering, and SRE. No single team can fully "own production" when multiple teams can ship changes that affect users. Google Cloud's reliability guidance describes reliability as a shared responsibility.
A platform is not automatically a portal or a Kubernetes cluster. The CNCF Platforms White Paper defines platforms as integrated capabilities delivered through consistent self-service experiences.
A platform might include:
Repository templates
CI pipelines
Deployment workflows
Documented scripts
Dashboards
Access controls
SOPs
In a small company, one engineer may perform parts of all these roles. Learn the work before focusing on the title.
18-Month Learning Roadmap
Months 0-2: Learn systems and coding fundamentals
Start with the foundations that explain what software is doing:
Linux processes and signals
Files, permissions, and users
Shell scripting
Git
HTTP
DNS
TLS
TCP basics
SQL
Basic Python or Go
You should be able to:
Read a small service
Write a health endpoint
Query a database
Automate a repetitive task
Inspect a running process
Explain how an HTTP request reaches an application
Months 2-4: Learn to build and release software
Learn how software moves from source code to production:
Docker images
Container registries
Environment configuration
Automated tests
CI pipelines
Versioned artifacts
Deployment health checks
Rollbacks
Release approvals
A release is not complete when CI turns green. It is complete when:
The new version serves traffic
Health checks measure something meaningful
Dashboards look normal
Errors and latency are within acceptable limits
The previous version can be restored
Someone knows how to roll back
Deployment controls become especially important when several changes target the same environment. GitHub Actions documents protected environments, approvals, branch restrictions, secrets, and deployment concurrency in its continuous deployment and deployment controls guidance.
Months 4-7: Learn one cloud and infrastructure as code
Choose one cloud provider and learn it deeply before studying several clouds superficially.
Focus on:
Identity and access management
Virtual networks
Subnets and routes
Firewalls and security groups
Load balancers
Compute
Object and block storage
Managed databases
Queues
Backups
Monitoring
Basic cost controls
Then use Terraform to create a small environment. Infrastructure as code makes configuration reviewable and versioned, but it does not make a weak design reliable by itself. Read the Terraform documentation.
Follow these practices:
Keep infrastructure configuration in Git.
Review Terraform plans before applying changes.
Separate environments.
Protect Terraform state.
Keep secrets out of repositories.
Use least-privilege access.
Prefer managed services when operating the underlying system is not a product advantage.
Kubernetes production guidance covers access control, resource limits, certificates, backups, and resilience. Do not copy a large production architecture into a beginner project without understanding its cost and operational risk.
Reliability
Months 7-10: Build observability and SRE skills
Observability helps you understand what is happening inside a system:
Metrics show trends over time.
Logs describe specific events.
Traces show the path of an individual request across services and dependencies.
OpenTelemetry's observability primer explains how traces use spans to connect work across components.
Start with signals tied to user experience and system capacity:
Request rate
Error rate
Latency
CPU and memory usage
Disk utilisation
Connection saturation
Queue depth
Database health
Deployment version
Dependency failures
When an alert fires:
Confirm whether users are affected.
Determine the scope of the problem.
Check recent deployments.
Check dependency health.
Use metrics to identify when the issue began.
Use traces to locate the failing hop.
Use logs to inspect the exact error.
Mitigate the impact.
Record follow-up actions.
Do not page someone for every CPU increase. Alert when:
Users are already affected.
A service objective is at risk.
A resource is approaching a hard limit.
Immediate action is required.
Google's incident management guidance covers user-focused alerting and effective on-call preparation.
Define a simple SLO
Start with one service-level objective: 99.9% of valid API requests succeed over 28 days.
This allows a 0.1% failure budget. The value of an SLO is not the number itself. It is the decision the number supports.
If the error budget is nearly exhausted:
Pause risky feature work.
Prioritise reliability improvements.
Investigate recurring failures.
Improve testing or deployment controls.
Reduce operational risk before making more changes.
Google's SLO guidance and error budget policy guidance explain this model in more detail.
Practise incident response
During an incident, mitigate before performing deep analysis.
Possible mitigations include:
Rolling back a release
Disabling a feature
Reducing traffic
Failing over
Adding capacity
Rate limiting requests
Reverting a configuration change
After the incident, document:
User impact
Detection time
Timeline
Mitigation
Recovery
Contributing factors
Missing safeguards
Owned follow-up actions
The goal is not to assign blame. The goal is to make the next incident less likely or less damaging.
Build Platform Skills
Months 10-18: Create a small internal platform
Build abstractions only after you understand the services beneath them. Otherwise, you risk hiding complexity instead of reducing it.
Start with one common service and create a small golden path containing:
Repository template
Dockerfile
CI checks
Deployment configuration
Secrets integration
Standard dashboard
Standard alerts
Ownership metadata
Runbook
Rollback instructions
Treat the platform as an internal product. Measure whether it provides:
Fewer support tickets
Faster delivery
Safer defaults
Fewer repeated configuration errors
Better service ownership
Easier troubleshooting
Do not build a portal full of features nobody needs.
Build Projects
A strong portfolio project should show the complete operational lifecycle:
Build one deployable service.
Add tests and a CI pipeline.
Package it into a container.
Deploy it to a small cloud environment.
Add metrics, logs, and traces.
Define an SLO.
Introduce a controlled failure.
Observe and diagnose the failure.
Roll back or mitigate the issue.
Write a runbook.
Automate the repeated steps.
Document the trade-offs.
This demonstrates more end-to-end ability than listing dozens of tools.
The target outcome is not "I know Kubernetes." It is:
I can explain how a request moves through a system.
I can deploy a change safely.
I can detect when users are affected.
I can investigate a failure with evidence.
I can recover service under pressure.
I can reduce repeated work for other engineers.
I can choose an appropriate level of operational complexity.
Final Principles
Keep these principles in mind as you progress:
Learn operations before abstractions.
Understand systems before adopting tools.
Measure user impact, not just infrastructure health.
Treat deployment as part of reliability.
Prefer simple designs that you can operate.
Automate repeated work after understanding it manually.
Use managed services when they reduce unnecessary burden.
Build platforms around real developer needs.
Treat reliability as a shared responsibility.
Optimise for safer change, not more technology.
Join 1,000+ engineers becoming better DevOps & SRE professionals.
Every week, I share:
How I'd approach problems differently (real projects, real mistakes)
Career moves that actually work (not LinkedIn motivational posts)
Technical deep-dives that change how you think about infrastructure
No fluff. No roadmaps. Just what works when you're building real systems.
👋 Find me on Twitter | Linkedin | Connect 1:1
Thank you for supporting this newsletter.
Y’all are the best.