Currently
Software Developer in Cloud, Kubernetes and DevSecOps at Bridgemanimages, London. Since April 2023. AWS, EKS, Terraform, Argo CD and the pipelines that feed them.
01 About
Engineering, and
teaching it properly.
Two things live here: what I do as an engineer, and how AliSkool turns that into material other people can actually learn from.
Ali Albakri
I am a software developer based in Birmingham, working on cloud infrastructure, Kubernetes and DevSecOps. Day to day that means keeping AWS and Kubernetes environments healthy in production: EKS cluster upgrades, Karpenter and add-on lifecycle, Helm releases, backup and recovery workflows, cross-account operations and recovery, IAM and security hardening, and the reliability work that makes a platform unremarkable to run.
Delivery is the other half of the job. I build and maintain pipelines in GitHub Actions, CircleCI and AWS CodeCommit, with Argo CD handling GitOps deployment into Kubernetes, and I care about the parts that get skipped: keyless authentication through OIDC, deployments that verify themselves, and rollbacks that still work under pressure.
Across AWS that covers the services a platform actually runs on, from VPC, IAM, EC2, S3, Lambda and Route 53 through to ALBs, Auto Scaling, RDS, DynamoDB, SQS, EventBridge, CloudWatch and cross-account organisation design. Architecture decisions, cost and blast radius are usually the interesting part rather than the individual service.
Most of what I enjoy sits at the seam between application code and the infrastructure underneath it. I have shipped Symfony and PHP features and fixed production bugs on the same systems whose clusters and pipelines I maintain, automated operational workflows in Python across S3, Lambda and EC2 for asset delivery to clients including Google and Reuters, and reduced cloud spend by consolidating load balancers and fixing traffic paths that were leaving the network without needing to.
Before the cloud work I was building websites and content management systems in PHP and MySQL, and before that I studied electronics and electrical engineering. That order shapes how I teach: start from something concrete, then work upward, because the abstractions make far more sense once you have seen what they are hiding.
Certified
CNCF Kubestronaut: CKA, CKAD, CKS, KCNA and KCSA. AWS Certified Solutions Architect - Associate in progress.
Educated
MSc Electronics and Computer Engineering and BEng Electronics and Electrical Engineering, both at the University of Birmingham.
02 About AliSkool
Why this exists.
Most infrastructure tutorials hand you a list of commands. You finish with a working thing and no idea which parts mattered. AliSkool is built the other way round.
Learn by building
Every course is organised around one system you provision, deploy and can break. Reading about a CloudFront distribution and creating one are different skills, and only one of them survives contact with a real job.
Small systems, large concepts
The application in a course is kept deliberately trivial. A static site or a hundred-line API removes backend noise, so the difficulty budget goes on the infrastructure, the delivery and the security model instead.
Understand it, do not copy it
Each step explains what it is protecting you from. Why the bucket stays private, why the pipeline uses OIDC instead of stored keys, what breaks if you skip it. Commands you cannot justify are commands you cannot debug.
Practical first, theory when it earns its place
Manual first, so the moving parts are visible. Automated second, so the automation has an obvious reason to exist. Theory arrives when there is already a concrete problem for it to explain.
One continuum, not separate subjects
Cloud, infrastructure, software and physical engineering are usually taught as if they were unrelated. The roadmap deliberately spans all of them, from Terraform and Kubernetes down to microcontrollers and sensors.
Honest about what exists
Planned courses are labelled planned. Nothing is described as available before it is written, and there are no placeholder links to content that does not exist yet.
03 Contact
Get in touch.
Open to conversations about cloud and platform engineering work, and to requests for topics on the course roadmap.