Azure Cloud Infrastructure & DevOps Engineer focused on Kubernetes, secure networking, CI/CD and production automation — I understand infrastructure from the application layer down.
| NAME | STATUS |
| api-service | ● Running |
| web-service | ● Running |
| worker-service | ● Running |
Verified outcomes from infrastructure and automation delivered at DSK Tech Wings.
I started with combined software and infrastructure responsibilities and moved steadily toward cloud infrastructure, Kubernetes and DevOps. I like owning a system end to end — building it, wiring the networking, deploying it, and being the person who figures out why it broke at 2am.
Most of my work sits at the boundary between applications and the platform they run on: containerising .NET and Python services, deploying them to AKS with Kubernetes manifests, designing secure Azure networking around them, and automating the path from a Git commit to a running pod.
I'm a Mechanical Engineering graduate who moved into software infrastructure and cloud engineering through hands-on implementation — which means I learn systems by building them, not just reading about them. That habit is why I keep a homelab and treat production troubleshooting as a core skill rather than an afterthought.
No progress bars — just the stack I actually work in. Filter by area.
Each card opens into an engineering case study: the problem, the architecture, and the result.
Built AKS infrastructure from scratch and deployed a multi-service enterprise application on it.
An enterprise application needed a home that could scale its services independently and update without downtime.
A cluster where each service scales and ships on its own, with a repeatable manifest-driven deployment model.
Internet │ DNS ─ TLS │ Ingress (nginx) │ ┌───────── AKS ─────────┐ │ Service A │ │ Service B │ │ Service C │ └───────────────────────┘ │ Azure SQL / Storage
Designed private, hybrid connectivity so users and services reach Azure data resources safely.
Data resources shouldn't sit on the public internet, but users and environments still need reliable access to them.
Private-only data access with a verified route for every consumer, no public exposure.
On-Prem / User
│
P2S / S2S VPN
│
┌──── Azure VNet ────┐
│ Application Subnet │
│ Private Endpoint │
│ Data Resources │
└────────────────────┘
An automated pipeline from a GitHub push to a rolling deployment on AKS.
AZURE_CLIENT_ID=******** AZURE_CLIENT_SECRET=******** ACR_NAME=portfolio-acr AKS_CLUSTER=portfolio-aks IMAGE=app:$GIT_SHA # kubeconfig generated at runtime # rollout: kubectl rollout status
Credentials shown as placeholders — never committed.
Three focused pieces of automation that removed cost and manual work.
An SFTP solution built on a VM that replaced a costlier transfer path.
A data-extraction workflow that halved the associated VM compute cost.
Standardised SSL across 20 sites with zero certificate spend.
A private "AI brain" I run in my homelab to learn emerging tech by building it.
A personal, local AI infrastructure project — not a commercial platform. It's how I understand LLM plumbing by running it end to end.
Laptop / Homelab
│
Proxmox
├── OpenWebUI
├── Ollama
├── FastAPI (Brain)
├── Qdrant
└── n8n
User question
→ FastAPI
→ memory retrieval
→ Qdrant
→ LLM
→ response
Traffic enters through DNS and TLS, hits nginx ingress, and fans out to independently scalable services inside the cluster, backed by Azure data services.
P2S/S2S VPN into the VNet, data locked behind Private Endpoints with private DNS, and NSGs controlling every subnet boundary.
GitHub triggers Jenkins, which builds a Docker image, pushes to ACR, then deploys to AKS with a rolling update using runtime-generated kubeconfig.
A local retrieval stack: OpenWebUI talks to a FastAPI brain, which retrieves from Qdrant and calls a local Ollama model — all on Proxmox.
Windows and Linux hosting: IIS and Nginx/Apache with reverse proxy, TLS termination, and DNS — the layer where most production incidents actually happen.
Tools are the easy part. These are the questions I actually ask.
Click a scenario to see how I actually work the problem.
Open to Cloud Infrastructure, DevOps and Platform Engineering roles — happy to walk through any of the architectures above.
Open to Cloud Infrastructure, DevOps and Platform Engineering opportunities.