cat about.md

I got here the long way round.

I started in sysadmin and IT work, with the tickets and the servers and the phone ringing at the wrong hour, and taught myself the way into DevOps from there. No bootcamp and no CS degree. That route shapes everything I make here.

Most DevOps content is written for people who already speak the language. It assumes you know what a control plane is, or why anyone would want a service mesh, or what "just use OIDC" means once you have to do it. If you came from the sysadmin side like I did, the problem usually isn't first principles. You want the thing mapped onto what you already know, and you want to watch it work.

So I build the thing end to end, on camera, and leave the mistakes in.

Career path: IT work, sysadmin, on-call, AWS, Terraform, Kubernetes, then AI in operations. it work sysadmin tickets, servers on-call 3am, still aws terraform as code kubernetes homelab ai in ops now
# the route in, roughly in order

What I actually do

Day to day I work with AWS, write Terraform for more or less everything, and keep CI/CD pipelines and observability running. I'm in the on-call rotation too, which is where a lot of what I know actually came from. You get to know a system very well at 3am, when it is broken and you are the one who has to fix it.

Away from work I run a homelab on real hardware: Proxmox, Kubernetes, managed with the same tooling I would use in production. I have also been putting AI to work in operations, writing MCP servers and agents that do useful things against live infrastructure.

Cloud

AWSS3 / CloudFrontIAM & OIDCCost control

Infrastructure as code

TerraformAnsibleProxmoxTalos

Delivery & operations

GitHub ActionsKubernetesPrometheusGrafana

AI in ops

MCP serversClaude skillsAgent-assisted runbooks

Who this is for

  • Sysadmins and IT people looking at DevOps roles and wondering how much of what they already know still counts. Most of it does.
  • Self-taught engineers who can follow a tutorial fine, then freeze when the real thing behaves differently.
  • Anyone who has been paged at 3am and would like to hear someone talk about that honestly.

How I make things

  • If a video says it builds something, it builds it. I don't cut away from the hard part.
  • Errors stay in, because the debugging is usually the useful bit. A run where everything works first time teaches you very little about what to do when yours doesn't.
  • Every AWS build gets a real monthly figure and a billing alarm, so you know what you are signing up for before you follow along.
  • I only recommend things I use. If a video is sponsored it says so at the top, not buried in the description.

Sponsorship or collaboration: hello@devopswithlijo.com