Case Studies

Delivering solutions grounded in years of software and platform engineering.

From Our Own Application Portfolio

The harness and its skills in use on our own applications.

Claude Code Accelerators

Migrating Applications to the Multi-Stack Deployment Harness

Challenge

Several small applications (a research assistant, an account-planning tool, a party game) ran on AWS Fargate using a deprecated AWS deployment tool, each with its own configuration. Each migrated a new deployment pipeline without anyone re-learning how it builds and runs.

Solution

Our adopt skill has Claude read each application's existing deployment manifest, Dockerfiles and CI, then derive a new manifest for the new pipeline app.yaml from them rather than guessing ports, health checks or build contexts. A one-command bootstrap creates the per-application deploy role, GitHub environments and Terraform roots.

  • Findings caught during adoptions across the estate: a Redis dependency declared everywhere and used nowhere (deleted, not ported); a postgresql+asyncpg:// driver scheme a default connection string would have broken; local SQLite and JSON storage that wouldn't survive ephemeral containers

Outcomes

  • Adoption is mostly deletion: each application's pipeline is replaced by one manifest and two small Terraform roots
  • Blockers surfaced before provisioning, not after a failed deploy
Cloud Infrastructure

Shared Identity as a Singleton Platform Service

Challenge

Every game and app needs sign-in and entitlements, and users should have one identity across all of them. That state can't be duplicated per application or per blue/green colour.

Solution

A subscription service (Express, Cognito, DynamoDB and an admin console) was extracted from a monorepo whose scope had drifted. Its duplicate, never-applied Terraform was dropped, and it now deploys through the harness as a singleton: about 90 AWS resources from one manifest. Applications name their user registry logically, and the platform resolves the concrete pool.

Outcomes

  • Applications use the same identity variables whichever pool backs them, so moving an app to the shared pool is designed to be a one-line manifest change with no application code change
  • Large applies are checked for convergence and retried automatically, after a real "reported success, left work undone" incident

Client Engagements

Enterprise platform work behind our experience.

AWS Fargate

Self-Service AWS Application Platform for a Class Action Law Firm

Challenge

A class action law firm was building several containerized applications on AWS. It needed a standard way to onboard each new service, continuous delivery without long-lived cloud credentials, secure database access, and infrastructure its engineers could understand and change safely.

Solution

We designed and built a modular, self-service AWS platform in Terraform and GitHub Actions. A 12-module library provisions the full platform: three-tier VPC networking, a shared ECS Fargate cluster with public and internal load balancers, managed Kafka (MSK), Cognito authentication with optional Microsoft Entra federation, ACM certificates with automated DNS validation, cross-region Transit Gateway peering, and Secrets Manager wrappers. The ECS service and ECR modules are instantiated once per application from a single tested codebase, so every new service is onboarded the same way.

  • Continuous delivery: GitHub Actions pipelines for Terraform apply and destroy and for environment secrets, authenticating through GitHub OIDC federation. Short-lived, repo-scoped roles carry only the IAM privileges needed to provision infrastructure, with no stored access keys
  • State: Terraform state kept in S3, so no deployment depends on a file on one machine and handovers between pipeline runs stay seamless
  • Safe re-runs: idempotent scripts for orphaned-resource cleanup and secret-key drift detection, built into the pipeline so automated retries stay safe
  • Database access: an SSM-only bastion module with zero SSH ingress, gated entirely by IAM through Session Manager
  • Day-2 tooling: on-demand database tunnels, interactive ECS container shells and a guarded pre-production teardown script, reducing reliance on the AWS console

Outcomes

  • A smooth transition to continuous delivery: infrastructure and applications ship through pipelines rather than console changes
  • New services onboard through the same reusable modules instead of one-off stacks
Cloud Foundry

Cloud Platform Engineering Enablement for a Large Public School District

Challenge

A large public school district ran a multi-foundation VMware Tanzu Platform for Cloud Foundry (TAS). The district needed repeatable lifecycle operations, single sign-on through its corporate identity provider, and a clear path to production for applications.

Solution

We administered and automated the foundations end to end. The work covered tile install, upgrade and repave, foundation backup and disaster recovery, and application onboarding, all through a defensive Windows batch automation suite built on the OM CLI, cf CLI and uaac. We integrated SAML SSO with Microsoft Entra ID across three independent UAA installations. We also guided the "Path to Production" workflow: development, then pull-request review, then production approval through Jenkins CI/CD.

  • Platform lifecycle: TAS install, upgrade, repave and DR through Ops Manager and the OM CLI; BOSH Director troubleshooting, instance access and support-bundle collection; capacity and sizing for the production rollout
  • Identity: SAML SSO with Microsoft Entra ID, UAA client provisioning, and Entra group-to-scope mapping across the Ops Manager, BOSH Director and CF UAAs
  • Certificates: generation, wildcard rotation and expiration monitoring across Ops Manager and Gorouter

Outcomes

  • Platform administration moved to version-controlled, declarative configuration
  • One sign-on through Entra ID across every platform UAA
  • A maintained reference library of more than 15 documents (installation guides, UAA/SAML architecture, DR runbooks, one-page ops cheat sheets), plus stakeholder briefings on roles, responsibilities and platform tooling
Kubernetes

Self-Service Platform Modernization for a Global Investment Bank

Challenge

The bank was modernizing its IaaS compute platform and in-house self-service "XaaS" system, and needed Kubernetes to fit its container strategy, reclaim idle capacity, and reduce the toil of building and patching images.

Solution

We provided reference architectures and ran Proof of Value exercises, and contributed the high-level design for the XaaS upgrade: VMs on request through vRealize Automation, cluster lifecycle through Tanzu Mission Control, and a Knative runtime with scale-to-zero. We demonstrated database-as-a-service for Kubernetes backing services with Crossplane, and introduced Cloud Native Buildpacks and polyglot onboarding templates. GitOps deployment used Flux and Kustomize from the bank's own repositories.

  • Platform: vSphere with Tanzu, OpenShift, Tanzu Application Platform, Knative
  • Delivery: Cloud Native Buildpacks, Flux, Kustomize, Backstage-based accelerators
  • Backing services: Crossplane claims for DBaaS
GPU at the Edge

GPU-Enabled Kubernetes in Retail Stores for a Multinational Pharmacy Chain

Challenge

A vendor's GPU workload had to run in individual store locations, managed centrally, with GPU nodes reserved for the workloads that need them.

Solution

We developed the reference architecture and runbook: custom Kubernetes nodes with NVIDIA Tesla GPUs, taints to keep non-GPU workloads off them, Harbor to replicate container images to each store, and Tanzu Mission Control for security policy and access. We also worked with the software vendor to convert its Docker Compose configuration into Kubernetes Deployments and Services.

Where It Shows Up Today

  • Translating an application's own run configuration into a platform's native form is exactly what our Adopt and Stacks accelerators automate
API Gateway

Secure, Resilient Gateway for a 100-Million-Member Organization

Challenge

A nonprofit membership organization hosting its web applications on a Tanzu platform needed its API gateway to deliver security, high availability and resilience, and more headroom on the platform.

Solution

We worked with the cloud platform team to configure the gateway for security and high availability. We recommended GraalVM and Spring Native to cut memory use and startup time, freeing platform capacity, and coordinated an expert review of the RabbitMQ cluster's migration to quorum queues.

  • Technologies: Tanzu platform, API gateway, GraalVM, Spring Native, RabbitMQ

Ready to see what we can do together?

Let's discuss how we can help accelerate your initiatives