Toronto, working across North America
Available for contract work in Canada and the United States. I travel for meetings and workshops.
Delivered while leading cloud and DevOps infrastructure teams on client engagements. Client names and confidential detail are withheld; the diagrams are shown as architecture, not as customer data.
The architectures are the output. These are the four disciplines behind them. The first two take up most of my week.
Primary focus
I read the invoice line by line across AWS, Azure and Google Cloud, find where the spend really lands against where teams assume it lands, and turn that into rightsizing, commitment coverage and shutdown decisions. It runs every month, not once a quarter.
Tagging and showback so every team sees its own bill, and anomaly review so a runaway environment surfaces in days instead of at month end. Cost is a property of the architecture, settled at design time.
Primary focus
Security built into every stage of delivery instead of bolted on before release: image scanning and provenance, policy gates in the pipeline, managed identities and secret handling pulled out of application code, and a written answer to which role owns which control.
Built for estates inside a compliance boundary, where the security review decides whether the workload ships at all.
Core practice
Clusters built as products rather than installs. EKS, AKS and GKE with routing, scaling, observability and the release path designed in from the start. GitOps as the delivery model, so cluster state lives in Git and a rollback is a revert.
Core practice
Multi-cloud estates across all three providers: landing zones, networking foundations, availability across zones, and the enablement receiving teams need to run what they inherit. Infrastructure defined as code, so the estate is reproducible rather than remembered.
Three architectures where the security posture was the requirement, not an afterthought. These are the reference patterns I reach for in banking, insurance and any workload sitting inside a compliance boundary.
Engineering note. The real deliverable was ownership. Naming the controls is easy; deciding which role signs off a container image before it reaches production — developer, platform engineer or cluster operator — is what stops the argument recurring every sprint.
Engineering note. Designed for a workload that had to clear a security review before it cleared a functional one. An isolated App Service Environment behind Application Gateway and WAF is the shortest defensible path to that.
Engineering note. Built to deploy either way — into an existing landing zone hub VNet or standalone — so the pattern survives a network team that has already made its decisions.
The largest group in this portfolio, and deliberately so. Every one of these takes a commit and ends at a running workload — Jenkins, Argo CD, Cloud Build, CodePipeline and Flux, chosen to fit the environment rather than the other way round.
Engineering note. Build and deploy kept deliberately separate. Desired cluster state lives in Git, so a bad release is a revert rather than an incident.
Engineering note. Managed services end to end. There is no build server in this design for anyone to patch, and Cloud Run absorbs the request- and event-driven workloads that do not justify a cluster.
Engineering note. The observability layer was designed alongside the pipeline rather than added after the first outage. What operations can see during an incident is decided while the pipeline is still on paper.
Engineering note. GitOps without adding a vendor to an AWS-committed estate. Flux reconciles the cluster against ECR rather than a pipeline pushing into it, which keeps the cluster the source of truth for its own state.
Engineering note. Not everything belongs in a cluster. The team already ran EC2 and had no appetite for Kubernetes, so the design met the estate that existed rather than the one on the roadmap.
Engineering note. The one architecture here argued in commercial terms — earlier defect detection and shorter turnaround to market — because the sponsor was funding it on that basis, not on tooling.
Standing a cluster up is a weekend. Making it routable, observable, cost-aware and safe to deploy into is the job. Two builds that show the difference.
Engineering note. The complete path from DNS name to pod, drawn and agreed once. Most Kubernetes networking tickets exist because that path was never written down.
Engineering note. Pod placement modelled as a graph clustering problem instead of left to the default scheduler, then measured against two real workloads — an IoT estate and an e-shop — rather than a synthetic benchmark.
Not every regulated workload is allowed to leave the building. These two run on Red Hat OpenShift in a private network, where the ingress path, the east-west policy and the storage class are all decisions someone has to own.
Engineering note. Two rules carry most of the design. Applications address PostgreSQL through the Service FQDN, postgres.db.svc.cluster.local:5432, because Pod addresses change on every reschedule. And a StatefulSet buys stable identity and storage, not database high availability: production PostgreSQL HA needs a proper replication design or an operator, and saying so early avoids a painful conversation later.
Engineering note. The interesting work was the traffic policy table rather than the components. Writing down every allowed flow, and explicitly denying internet access to the backend and the database, turns a diagram into something a platform team can implement and a reviewer can check. The same caveat applies as on the PostgreSQL build: a StatefulSet is not MySQL HA, so the replication approach has to be chosen and validated on its own terms.
High availability is a claim until someone draws the failure path. These three cover redundancy, elastic capacity, and the cloud networking fundamentals a migrating team is usually missing.
Engineering note. The smallest design here and the one that proves its own failure path: remove an availability zone from the picture and the remaining half still serves traffic.
Engineering note. Elastic capacity and automated release in the same design, so a traffic spike and a deployment stop being two separate emergencies competing for the same on-call engineer.
Engineering note. Written as enablement for the network and infrastructure teams inheriting the estate. Provider differences are what bite during a migration, and they bite the people who were never briefed.
Two builds that reach past infrastructure into the operation itself — a broadcast media supply chain, and a forms process that was costing a business real money every month.
Engineering note. Eleven systems, several of them third-party media servers whose interfaces I did not control, integrated into one automated flow. The integration was consistently harder than the cloud services.
Engineering note. Event-driven from the first trigger — an email arriving, a blob landing, a function splitting pages, a Form Recognizer call — so each stage stays independently replaceable as the forms change.
One architecture that pulls together everything above — clients, real-time communication, microservices and managed data — inside healthcare's constraints.
Engineering note. Split so each team owns a functional domain and can release at its own pace, with managed identities carrying service-to-service auth so secrets largely leave the codebase.
A product of my own
A multi-tenant SRE and observability platform I designed, built and run — monitoring, APM, alerting and security advisories in one product, aimed at the ground Site24x7 and Datadog occupy. It is also where I test the architectural patterns on this page against a system I have to keep running myself.
Current credentials across the four platforms in this portfolio. Each one links to its issuer for verification.
The sequence behind every architecture above. Most cloud programmes come apart at the first phase, not the last.
I map the estate as it stands: workloads, constraints, compliance boundary and who owns what. That comes before anything is drawn.
The architecture is drawn and agreed with the people who will run it. Every diagram above started here.
Infrastructure and pipelines built to the agreed design, with security controls embedded as the work proceeds.
Automated tests in the pipeline, plus verification that the failure paths behave the way the diagram claims.
Deployment and handover, including the enablement the receiving network and operations teams need.
Ongoing maintenance and iteration. Timelines ran from six weeks for a simple build to several months for a full platform.
Feedback on engagements delivered by teams I led, paraphrased from client reviews.
Credited the team with bringing task-oriented focus to a technical job that badly needed leadership and direction.
Crockett Dunn, LLCHighlighted the team’s communication and its command of both AWS and Azure across the engagement.
Omnium Group CorporationNoted regular communication through a large deliverable, and deep subject knowledge in the Proxmox environment.
TellarcDescribed the engagement as a straightforward pleasure and said they would engage the team again immediately.
Andrew CarlsonSlots come straight from my calendar, so the times shown are ones I am actually free. Thirty minutes is enough to walk through an architecture in detail or give you a first read on your cloud bill. Most of my work runs remotely, and I travel across Canada and the United States for meetings, kickoffs and workshops.