Cloud Architecture

All three hyperscalers. Every layer of the stack.

Azure, AWS, and Google Cloud — I have shipped production systems on all three, and I’ve moved workloads between them. Lift-and-shift when speed matters, full refactor when the architecture deserves it, serverless where the workload is bursty, and Kubernetes where the platform needs to be portable. I don’t sell one cloud; I architect for the one that fits — and I make sure you can leave it if you ever need to.

Multi-Cloud, For Real

Fluent on Azure, AWS, and Google Cloud — not certified-and-hoping.

Most engineers know one cloud and translate. I have carried production responsibility on all three: a mainframe-to-Azure banking modernization serving ten million users, distributed ML on AWS EKS for Koch Industries, and an active enterprise AWS → GCP healthcare migration where I map services one-to-one — Lambda to Cloud Run, DynamoDB to Firestore, HealthLake to the Google Healthcare API. Knowing all three is what lets me recommend the right one.

What I Build in the Cloud

Six cloud disciplines, delivered on Azure, AWS, and Google Cloud.

Migration & Lift-and-Shift

Rehost, replatform, refactor, or rearchitect — I scope which of the four fits each workload, then execute. On-prem to cloud, cloud to cloud, mainframe to microservices, with hybrid coexistence patterns and identity/network bridges to keep the business running through long migration windows. I don’t hand over a deck — I ship the migration.

Serverless & Event-Driven

AWS Lambda, Google Cloud Run and Cloud Functions, Azure Functions and Durable Functions — compute that scales to zero when idle and to a spike when it isn’t. I wired Azure Durable Functions over legacy SQL for an oil & gas platform and run Cloud Run services on an active healthcare migration. Pay for work, not for waiting.

Kubernetes in the Cloud

Production clusters on AKS, EKS, and GKE — GitOps delivery with Flux, KEDA event-driven autoscaling, and stateful workloads done properly. When the workload should be portable across clouds, Kubernetes is how I keep it that way. See my Kubernetes work

Cloud Data Platforms

Warehouses and lakehouses on BigQuery, Synapse, and Databricks; ingestion with Event Hub, Kinesis, Pub/Sub, and Kafka; database migrations from SQL Server, Oracle, and DB2 to cloud-native stores. The data layer is usually the hardest part of a cloud move — it’s also the part I lead with.

Infrastructure as Code

Reproducible environments defined in code — Terraform, Pulumi (C# / TypeScript / Python / Go), and Terragrunt with OpenTofu on a current GCP engagement. If it isn’t in the repo, it doesn’t exist: every environment stands up the same way, every time.

Cloud Security & Compliance

KMS and envelope encryption, least-privilege IAM, VPC segmentation, and secrets management on all three clouds — with HIPAA, banking, and insurance compliance postures designed in from the first diagram. See my security work

Cloud, Drawn Out

Two patterns behind every cloud program I run — the migration decision path, and portability by design.

1 · Every workload gets the right “R” — not the same one

A migration that lift-and-shifts everything overpays forever; one that refactors everything never ships. I assess each workload and route it: rehost what’s stable, replatform what needs managed services, refactor what earns it, and retire what nobody will miss — then optimize cost and operations once the estate has landed.

flowchart LR
    ASSESS["Assess -- inventory, dependencies, compliance"] --> DECIDE{"Per-workload decision"}
    DECIDE --> RH["Rehost -- lift-and-shift, fastest path"]
    DECIDE --> RP["Replatform -- managed DBs, containers"]
    DECIDE --> RF["Refactor -- serverless, microservices"]
    DECIDE --> RT["Retire -- decommission the dead weight"]
    RH --> LAND["Land -- hybrid identity and network bridges"]
    RP --> LAND
    RF --> LAND
    LAND --> OPT["Optimize -- cost, performance, runbooks"]
                
Rehost, replatform, refactor, retire — decided per workload, not per slide deck.

2 · Portability by design — use the cloud, don’t marry it

Managed services are worth using and worth abstracting. On my current healthcare migration I built a fully unit-tested Pub/Sub abstraction layer so the platform can move between Google Pub/Sub and Kafka without rewrites — the same discipline I apply with containers, IaC, and open interfaces so the business keeps its leverage at renewal time.

flowchart TD
    APP["Application services -- containers, tested business logic"] --> ABS["Abstraction layer -- messaging, storage, identity interfaces"]
    ABS --> AZ["Azure -- AKS, Functions, Event Hub, Synapse"]
    ABS --> AWS["AWS -- EKS, Lambda, Kinesis, HealthLake"]
    ABS --> GCP["Google Cloud -- GKE, Cloud Run, Pub/Sub, BigQuery"]
    IAC["Infrastructure as code -- Terraform, Pulumi, OpenTofu"] --> AZ
    IAC --> AWS
    IAC --> GCP
                
One codebase, three landing zones — the cloud is a choice you keep making, not a door that locks.

Cloud in the Wild — Real Engagements

Six engagements across the three hyperscalers — migration, serverless, and Kubernetes under real load.

Healthcare · AWS → GCP

Healthcare Cloud Migration — AI-Driven, Cross-Cloud

An enterprise healthcare interoperability platform moving from AWS to Google Cloud — AI agents porting the FHIR/HL7 codebases, Cloud Run and Pub/Sub on the receiving end, Terragrunt/OpenTofu standing it up, and the HIPAA posture preserved throughout.

Banking · Azure

Fiserv — Mainframe to Azure for 10M Users

As Business Solutions Architect on a mainframe-to-Azure banking modernization serving ten million users, I helped distributed microservices replace legacy cores — and set the architecture patterns that sixty developers built against.

Manufacturing · AWS

Koch Industries — Distributed ML on EKS

A production-capacity forecasting platform on AWS EKS with KEDA event-driven autoscaling — parallelized feature processing and inference scaling against per-business-unit demand across multiple Koch companies.

Insurance · Azure

FM Global — Full Azure GIS Platform on AKS

A property-risk GIS platform delivered on Azure end to end — an AKS cluster running a satellite-imagery analysis pipeline with KEDA autoscaling and Databricks integration, with a 50-developer team led to delivery.

Oil & Gas · Serverless

Azure Durable Functions over Legacy SQL

Serverless where it counts: Azure Durable Functions orchestrating long-running workflows on top of a legacy SQL estate for an oil & gas platform — modern elasticity without waiting for the full replatform.

Wealth Management · AWS Serverless

AWS Step Functions in Financial Services

At a national wealth-management and tax-advisory firm, I built serverless account-maintenance workflows on AWS — Step Functions orchestrating Lambdas behind API Gateway, Cognito authorization scopes, and CloudFormation/Serverless-framework stacks — paired-tested with QA and delivered into UAT.

Need an architect fluent in all three clouds — not loyal to one?

Lift-and-shift, serverless, Kubernetes, data, and security — on Azure, AWS, and Google Cloud. I pick the right cloud for the workload and deliver it hands-on.