The 8-Track AI + Cloud Roadmap

One track per month. Eight months. Three habits: play daily, build weekly, learn monthly.

Author

Vishakha Sadhwani
September 14, 2026

The reason most roadmaps fail is that they treat eight technologies as eight separate subjects. You finish Docker, feel good, move to Kubernetes, and by the time you get to monitoring you're deploying something you've never seen fail. This one is built the other way around. One app carries through the first six tracks. You write it, you version it, you containerize it, you deploy it, you scale it, you instrument it. By month six you have one thing you actually understand instead of eight throwaways.

Tracks 7 and 8 are the deliberate exception. They branch off into AI inference and AI-assisted engineering, and they get their own projects.

First: Pick The App

Do this before track 1, and don't overthink it. You need a small HTTP service with:

  • one real route that does something (talks to a database, calls an API, transforms input)

  • a /health endpoint

  • a /metrics endpoint (you'll need it in month 6, add it now or add it then)

  • at least one test

Node/Express or Python/FastAPI are both fine. Keep it under 200 lines. The app is not the point — the pipeline around it is.

Pick a spec, not a tutorial

These are project briefs with requirements and no walkthrough, which is what you want. Pick one, build it your way:

  • Todo List API — CRUD, auth, pagination. The best default: small enough to finish in a week, real enough to containerize.

  • Expense Tracker API — CRUD plus filtering and JWT auth

  • Weather API — wraps a third-party API and caches it in Redis. Good pick if you want a second container in the stack from day one.

  • URL Shortening Service — slightly harder, and the read/write ratio makes the autoscaling month more interesting

  • All API projects if none of those appeal

Follow-along builds, if you'd rather be walked through it

Python / FastAPI

Node / Express

Wiring up /health and /metrics

This is the bit tutorials skip and the bit tracks 5 and 6 depend on. Two small libraries do almost all of it:

Keep /health genuinely cheap — no database call, no external request. It gets hit every few seconds by Kubernetes in month 5, and a health check that talks to your database will take the whole deployment down with it when the database hiccups. If you want a deeper check, make it a separate /ready endpoint.

What "done" looks like

Before you start track 1, you should be able to run these four commands and have all of them work: 

git clone <your repo> && cd <your app>
<install command>
<test command>          # at least one test passes
<run command>           # then: curl localhost:8000/health and /metrics

That's it. No Docker yet, no cloud, no CI. Those are months 2, 3, and 4.

Reference implementations worth reading

  • stefanprodan/podinfo — a tiny Go service built specifically to demonstrate what a Kubernetes-ready app looks like: liveness and readiness probes, Prometheus instrumentation, graceful shutdown, a Helm chart, deliberate fault injection for testing failure. Read it, don't clone it.

  • docker/getting-started-app — the Node todo app from Docker's official tutorial. Useful as a sanity check on project layout.

  • mrizkisaputra/backend-projects — community solutions to the roadmap.sh briefs above, for after you've written yours.

Free tier accounts you'll need by month 3:

1. Linux & Bash

Why it matters: Every container, cluster node, and cloud instance you touch for the next seven months runs Linux. If you hesitate at a terminal, everything downstream is slower. This month is about reps, not theory — you want grep, awk, sed, pipes, permissions, processes, and systemd to be muscle memory before Docker abstracts them away from you.

🎮 Play — 10 minutes a day

  • OverTheWire: Bandit — 34 levels, each one a small puzzle solved with a real command. This is the best Linux practice on the internet and it's a game.

  • KodeKloud Linux labs — browser-based, no setup, one a day

  • learnshell.org — interactive Bash practice for the scripting half

📚 Learn — this month's course

🛠️ Build — one project a week

Week 1–2: Server Performance Stats — a script that reports CPU, memory, disk, and top processes. Spec only, no walkthrough, which is the point.

Week 3–4: Nginx Log Analyser — top IPs, top paths, top status codes, top user agents, straight from the command line. Then extend it: add date filtering and a 5xx alert threshold.

Stretch: Log Archive Tool — compress and timestamp logs on a cron schedule.

Reference implementation if you get stuck: ghaza1/apache-log-analyzer — an interactive Bash log analyzer with a config file and a suggestions engine. Read it after you've written yours, not before.

Blogs / docs

YouTube

2. Git & CI/CD

Why it matters: Git is the substrate everything else sits on. Terraform state, Kubernetes manifests, GitOps, CI pipelines — all of it is "the repo is the truth." And a pipeline is what turns git push into a deployed artifact with no human in the middle. Once you've built one end to end, "how does code get to production here?" stops being a mystery at every job you ever take.

This is the month your app gets a repo, a test suite, and a pipeline that builds and pushes an image.

🎮 Play — 10 minutes a day

  • Learn Git Branching — visual, interactive, and the fastest way to stop being scared of rebase

  • Oh My Git! — free open-source card game for Git, if you want a second angle on it

📚 Learn — this month's course

🛠️ Build — one project a week

Week 1: GitHub Pages Deployment — the simplest possible workflow, just to get the YAML under your fingers.

Weeks 2–4: Put the real pipeline on your app. Lint → test → build → push to a registry. Docker's official GitHub Actions guide is the cleanest reference for the build-and-push half, including caching and multi-platform builds.

Video walkthrough: Docker CI/CD Project — push triggers the pipeline, image gets built and pushed, container ships. Do it once and pipeline configs stop being intimidating.

Going further: Dockerized Service Deployment uses Actions to deploy a containerized Node service to a remote server — a natural bridge into next month.

Blogs / docs

YouTube

3. Cloud & IaC

Why it matters: Clicking through a console teaches you what the pieces are. It does not scale, it isn't reviewable, and you can't reproduce it six months later. The moment your infrastructure lives in Terraform, every change becomes a pull request with an author, a diff, a review, and a rollback path. This is also the month you learn what a VPC, subnet, security group, and load balancer actually are, because Terraform won't let you hand-wave them.

Your app gets somewhere to live this month.

🎮 Play — 10 minutes a day

📚 Learn — this month's course

🛠️ Build — one project a week

Weeks 1–2: IaC on DigitalOcean — smallest possible real Terraform project. A droplet, from code. Cheap, fast, and it teaches state.

Weeks 3–4: Deploy your app for real. Terraform with AWS — Real-Time Project provisions a VPC, subnets, an internet gateway, instances across two availability zones, and a load balancer entirely from code. Companion repo: iam-veeramalla/terraform-zero-to-hero. Swap their sample app for yours.

Rule for this month: build it once by hand in the console so you understand the pieces, then destroy it and rebuild it in Terraform. The second build is where the learning happens.

Blogs / docs

YouTube

4. Containers

Why it matters: Containers are the default unit of deployment, and the Dockerfile is where most people quietly do a bad job. A naive image is 1.2GB, runs as root, rebuilds from scratch on every code change, and ships your entire toolchain to production. A multi-stage build is 80MB, runs as a non-root user, caches dependencies separately from source, and contains nothing but what the app needs at runtime. Same app, completely different operational reality.

🎮 Play — 10 minutes a day

📚 Learn — this month's course

🛠️ Build — one project a week

Week 1: Basic Dockerfile — get one working, badly. Note the image size.

Week 2: Rewrite it as a multi-stage build. Docker's multi-stage guide plus the Dockerfile best practices page. Target: under 150MB, non-root user, dependencies cached in their own layer. Then wire the build into last month's pipeline and push to a registry.

Weeks 3–4: Multi-Container Application — your app plus a database plus a cache, wired together with Compose. This is the shape of the thing you'll deploy to Kubernetes next month.

Worth reading once: dockersamples/example-voting-app — five services in five languages, the canonical multi-container demo.

Blogs / docs

YouTube

5. Kubernetes

Why it matters: Kubernetes is where your app stops being a process you babysit and becomes a declared desired state that something else maintains. Pods, deployments, services, ingress, probes, resource limits, autoscaling. The concept that pays for the whole month is the reconciliation loop: you say what you want, a controller makes reality match, forever. Autoscaling is the clearest demonstration of that, which is why it's this month's build.

🎮 Play — 10 minutes a day

📚 Learn — this month's course

🛠️ Build — one project a week

Weeks 1–2: Get your app running on a local cluster. Minikube or kind. Deployment, service, ingress, liveness and readiness probes, resource requests and limits. The probes and limits are not optional — the autoscaler doesn't work without them.

Weeks 3–4: Autoscale it. The official HPA walkthrough is the cleanest path: install metrics-server, define an HPA, generate load, watch it scale out, stop the load, watch it scale back in. Then do it with your own app instead of their sample.

For custom-metric scaling (scale on requests per second, not CPU — much closer to how this is done in production): learnk8s/spring-boot-k8s-hpa and stefanprodan/eks-hpa-profile both walk through Prometheus-driven HPA. This sets up month 6 nicely.

Reference: DigitalOcean Kubernetes Starter Kit — a well-written, free, end-to-end guide covering ingress, scaling, monitoring, and backups.

Blogs / docs

YouTube

6. Observability & SRE

Why it matters: Everything up to here was about shipping. This month is about running, which is what the job actually is. An alert that fires constantly trains the team to ignore alerts, which is worse than no alerts. An SLO turns "is the service okay?" from an argument into a number. And the four golden signals — latency, traffic, errors, saturation — are the shortest useful list of things to measure on any service you will ever own.

This is where the app you've been carrying since month 1 finally tells you how it's doing.

🎮 Play — one PromQL query a day

  • Grafana Play — live dashboards with real data, free, no account. Open a panel, edit the query, break it, fix it.

  • PromLabs PromQL Cheat Sheet — work down it one function a day: rate, increase, histogram_quantile, sum by, topk

📚 Learn — this month's course

🛠️ Build — one project a week

Week 1: Prometheus and Grafana — stand the stack up, scrape something, build a dashboard.

Week 2: Instrument your app properly. A request counter, a duration histogram, and an error counter, labelled by route and status. Prometheus instrumentation best practices tells you what to expose and what not to.

Week 3: Alerts that mean something. grafana/demo-prometheus-and-grafana-alerts is a Compose setup with Prometheus, Alertmanager, Grafana, Loki, and a k6 load generator to trigger alerts on demand. An alarm you've never seen fire is not a working alarm.

Week 4: Define one SLO and alert on its burn rate. Pick something like "99% of requests under 300ms over 30 days," compute the error budget, and write a multi-window burn-rate alert. Sloth generates the Prometheus rules for you from a short SLO spec — use it once you understand what it's generating.

Blogs / docs

YouTube

7. AI Inference & Serving

Why it matters: This is where the last six months pay off in a way most AI-curious engineers can't match. Plenty of people can call an API. Very few can tell you what their p99 time-to-first-token is under 32 concurrent requests, or why throughput collapsed when they doubled the context length. Serving a model is an infrastructure problem — batching, memory, GPU utilization, queueing — and you now have the vocabulary for all of it.

Note: this track branches away from your app. It's a separate build.

🎮 Play — one section a day

  • Hugging Face Learn — free courses on LLMs, agents, and MLOps. One section, most days.

  • Hugging Face Models hub — get comfortable reading model cards: parameter count, context length, license, quantization

📚 Learn — this month's course

🛠️ Build — one project a week

Weeks 1–2: Serve a model and measure it. vLLM quickstart to get an OpenAI-compatible endpoint running, then vllm bench to measure it. Three subcommands matter: vllm bench latency (single batch), vllm bench serve (online throughput), vllm bench throughput (offline). Record TTFT, TPOT, and requests/sec at concurrency 1, 8, and 32.

Week 3: Make the numbers move. Change one variable at a time — quantization, --max-model-len, batch size, prefix caching — and re-run. Write down what each change did. That table is the deliverable.

Week 4: Put it on Kubernetes. vLLM on Kubernetes for the walkthrough, and vllm-project/production-stack for the reference deployment. Now point month 6's Grafana at it — vLLM exposes Prometheus metrics natively, so your observability work transfers directly.

Alternative benchmarking tool: GuideLLM if you want load-shaped benchmarks rather than raw sweeps.

No GPU? Serve a small model on CPU to learn the mechanics, then rent an hour of GPU time to get real numbers. An hour is enough.

Blogs / docs

YouTube

8. AI-Assisted Engineering

Why it matters: The gap opening up in this industry isn't between people who use AI tools and people who don't. It's between people who can describe a system precisely enough for an agent to build it, review what comes back critically, and wire the agent into real tooling — and people who paste code and hope. MCP is the part that matters most here, because it's how an agent stops guessing and starts reading your actual systems.

🎮 Play — ship one small thing with an agent

Not a tutorial. Pick a real annoyance — a script you keep rewriting, a dashboard you keep configuring by hand, a report you assemble manually — and have an agent build it with you. Small enough to finish in a sitting. Then read every line it wrote and decide whether you'd merge it.

📚 Learn — this month's course

🛠️ Build — one project a week

Weeks 1–2: Build a project end to end with an agent. Something with a database, an API, and tests. Your job is architecture, review, and the decisions the agent shouldn't be making alone. Keep a note of every place it was confidently wrong — that list is the real output of this exercise.

Weeks 3–4: Build an MCP server. Start with the official MCP quickstart and the quickstart-resources repo. Then build one that's actually useful to you: a server that queries your Prometheus instance, reads your Kubernetes cluster state, or searches your own runbooks. Connecting an agent to the stack you spent six months building is the whole point.

Reference servers: modelcontextprotocol/servers — official implementations worth reading before you write your own.

Capstone, if you want one: End-to-End DevOps + AIOps Project (5-part playlist) — Docker, Kubernetes, CI/CD, GitOps, cloud infra, monitoring, and logging in one continuous build. Every track on this list, assembled.

Blogs / docs

YouTube

The Format

Once a day — PLAY. 5–15 minutes. A Bandit level, a Killercoda scenario, one PromQL query. This is the habit that carries the whole thing; it's small enough that you won't skip it on a bad week.

Once a week — BUILD. One real project. The weekly build is where you find out that you didn't actually understand the thing you watched a video about.

Once a month — LEARN. One course milestone. Not the whole course necessarily — a milestone. The course is scaffolding for the build, not the other way around.

Build Project Quick List

Every weekly project in one place:

Play Quick List

Bookmark these eight. One tab, ten minutes, every day.

Crash Course Quick List

Every video in one place, in case you just want the links:

How To Not Fail This

Don't restart the app. The temptation in month 4 is to scrap the thing you wrote in month 1 and start fresh with something nicer. Don't. The value is in the continuity — watching the same code get progressively harder to break.

Don't let the course drive the month. If you finish the course in week two and the build in week four, good. If you only get halfway through the course but the build works, that's still a win. Nobody has ever been hired for finishing a course.

Tear things down. Everything from month 3 onward costs money if you leave it running. Destroy the Terraform stack when you're done with it, every time.

Write down what broke. Every month, keep a short list of things that failed and why. Eight months later that list is more valuable than anything on your résumé, and it's the thing you'll actually talk about in an interview.

All links are free courses, crash courses, official docs, or free-to-follow projects. Free tiers, course availability, and video links change over time, so check pricing before you deploy anything and search the title if a link has moved.