What I Build — A Technical Services Profile

If you’ve landed here from LinkedIn or a referral, this is the longer answer to “what do you actually do?”

The short version: I design and build infrastructure, and increasingly I’m the one deciding what infrastructure gets built. I have done so for 25 years — across datacentres, managed service environments, banking platforms, and my own homelab — using everything from Windows Server and VMware to OpenStack, Red Hat, and modern cloud-native stacks on Kubernetes. My current role is setting cloud and containerisation strategy for a regulated banking platform: the reference architectures other engineering teams build against, the guardrails that keep a POPIA and PCI-DSS environment audit-ready, and the FinOps governance that keeps cloud spend accountable at group level.

The long version is below.

Where It Started

#

My first computer was an IBM machine running DOS — Word Perfect installed, monochrome display, no colour, and it took a while to boot. I was in high school. I knew immediately that this was the future.

That conviction led me to study Computer Science formally, and I have spent every year since working deeper into the field. Like Moore’s Law playing out in real time, I watched computational devices get faster and smaller — from that desk-bound IBM to a notebook to a mobile device with more processing power than anything I first touched. The technology changed; the obsession didn’t.

The Foundation: Banking, Networking, and Managed Services (2002–2019)

#

My career began at Absa Bank (2002–2006) providing technical support for internet access and email in a regulated banking environment — an early lesson in what uptime and security mean when money is on the line. From there, MWeb Business (2006–2008) took me into Cisco networking full-time: routing and switching, site-to-site and remote-access VPNs, and fully managed Cisco firewall deployments for business and enterprise clients. This is where I developed the networking fundamentals that underpin every infrastructure design I do today.

Then almost 12 years across IT Technologies and Syrex, designing and managing infrastructure for dozens of clients simultaneously. This wasn’t commodity IT — it was the kind of work where a misconfigured multi-site Active Directory trust, a botched Exchange DAG failover, or an improperly sized VMware cluster brought down production for someone’s business.

At Syrex I owned the full stack across clients:

• Highly complex Microsoft Server designs — multi-site Windows Server 2000 through 2012 R2 domain architectures, Active Directory trust relationships, Exchange 2003 through 2013, IIS-hosted applications, MS SQL, and MSSQL Always On
• VMware ESXi virtualisation — consolidating multi-client workloads onto HA hosts, vSphere management, DRS clusters, snapshot-based backup workflows, and capacity planning across environments of varying scale
• Linux — RHEL/CentOS, Apache, Bind DNS, Postfix/Dovecot, iptables, KVM, and Xen hypervisors
• Networking — managed switches, VLAN design, routing, BGP fundamentals, and VoIP (Asterisk)

This period shaped how I think about infrastructure: understand what breaks, design for failure, test your assumptions, and document obsessively. Twelve years of being the escalation point for high-priority incidents across multiple clients gives you a very direct view of what poor architecture costs.

The Pivot: Open Source, OpenStack, and Red Hat (2015–2019)

#

While managing client environments at Syrex, I began architecting fully open-source infrastructure stacks — replacing proprietary tooling with OpenStack private clouds, Red Hat platforms, and Linux-first designs. The economics were compelling; the engineering was demanding. Getting OpenStack right requires understanding the full networking stack (Neutron, OVN, BGP), storage (Ceph, LVM), compute scheduling, and the operational discipline to manage what is genuinely complex distributed software.

This is also when I completed my Postgraduate Diploma in Software Engineering at the University of Liverpool. The programme reinforced something I had learned operationally: technology decisions have consequences beyond the server room. My research covered:

• Cloud security and data sovereignty — who owns your data, where it lives, and what the regulatory implications are when it crosses a border
• Risk management failure patterns — why organisations fail at risk management and how communication breakdowns create blind spots
• Software safety in critical systems — the Therac-25 case study as a lens for understanding what happens when software replaces hardware safety controls without equivalent rigour
• IT professionalism and ethics — what it means to be accountable for the systems you build and the advice you give

These aren’t abstract topics. They surface in every architecture decision involving sensitive data, regulated workloads, or systems where failure has a real cost.

Cloud-Native and Banking (2019–Present)

#

At eBucks (FirstRand Group), I moved from managing infrastructure to designing platforms for one of South Africa’s largest banking loyalty programmes. The constraints are different at this scale: POPIA, PCI-DSS, group security policies, audit requirements, and a regulatory environment that does not forgive careless architecture.

As Technical Team Lead (2019–2024) and now Cloud Architect (2024–present), I’ve moved from delivering individual solutions to setting the cloud and containerisation strategy the wider organisation builds against. That means translating POPIA and PCI-DSS requirements into reference architectures other engineering teams adopt rather than reinvent, owning landing zone design and IAM governance at scale on AWS and Azure, running the FinOps programme that governs how the group spends on cloud, and driving the containerisation strategy moving the organisation toward EKS and AKS adoption.

The banking context also sharpened my thinking on hybrid cloud design. Most organisations in this space aren’t starting from a greenfield cloud environment. They have on-premise VMware estates, legacy workloads, data residency constraints, and engineering teams who have never opened a kubeconfig. Hybrid cloud isn’t a compromise position — it’s an architecture discipline that requires understanding both sides of the boundary deeply.

The Homelab: Where Theory Meets Production

#

I maintain a four-node Proxmox cluster running a production-grade Kubernetes environment (k3s or RKE2) that serves as both a testbed and a living portfolio. Everything here runs as it would in a real production environment — no “it works on my laptop”:

• Terraform + Ansible for full IaC — VM provisioning to application bootstrap, reproducible from scratch
• Cilium as CNI with kube-proxy replacement, eBGP (ASN peering with the router), Hubble observability, and dual-stack IPv4/IPv6
• ArgoCD GitOps with sync-wave ordering across the full application stack
• Argo Workflows + Argo Events for event-driven CI/CD — Gitea push webhook triggers an Argo Workflow that runs Hugo builds, BuildKit multi-arch image builds (amd64 + arm64), SonarQube scans, and Trivy CVE checks; Kargo handles promotion through preview and production stages before anything touches production traffic
• Sealed Secrets, Keycloak OIDC (SSO for all services), Vaultwarden, Netbird WireGuard mesh
• Prometheus + Grafana + Graylog + Fluent Bit — full observability, not just metrics
• CloudNativePG 3-node PostgreSQL cluster and MariaDB Galera — production-grade databases
• SonarQube, Trivy Operator, OWASP ZAP — shift-left security baked into every pipeline

When I recommend Argo Rollouts with pre-promotion testing, it’s because I’ve operated it — I’ve written the Playwright tests, debugged the k6 threshold failures, and traced Cilium eBGP routes when something went wrong at 2am. When I tell a client their hybrid cloud design has a data-sovereignty gap, it’s because I’ve read the legislation and built the guardrails.

What I Can Do For You

#

At Principal level, this isn’t about delivering one project and moving on. It’s setting architecture strategy for a platform or an organisation — writing the reference architectures other teams build against, translating regulatory and security requirements into guardrails that get baked into pipelines rather than checked after the fact, and owning the trade-offs when “greenfield cloud-native” collides with a decade of on-premise VMware and a board that asks about FinOps every quarter. It’s also cross-team technical leadership — architecture reviews, pairing with engineers, mentoring the people who’ll own these systems after I’ve moved on — because a platform that depends on one person’s head isn’t a platform, it’s a liability.

That’s the day job I’m looking for. My breadth means I can operate across the full estate, not just one layer of it:

Alongside my full-time role, I also take on scoped consulting engagements where the problem fits this table — scoped, documented, and delivered with the same rigour I apply to production systems. But that’s the exception, not the model. If you’re hiring for the role described above, that’s the conversation I’m actually here for.

Get in touch · View Resume · Connect on LinkedIn