Platform Decision Through Hands-On Proof

Global hospitality company evaluating container platforms to underpin its modernization strategy. Multiple teams with competing priorities and no shared vocabulary. Strong-willed leaders building what they wanted rather than what internal customers needed. No product function and no prioritization strategy.

Measured OutcomePlatform decision validated through parallel proof-of-concept with real workloads. 1TB daily observability aggregated from 2,000+ edge instances. Monolith decomposed into production microservices.
Investor Takeaway

What looks like a technology decision problem is often an organizational trust problem underneath. Hands-on proof resolves both: it eliminates the most expensive source of platform strategy failure and gives competing teams a shared, evidence-based language to move forward.

4Platforms Evaluated
1TBDaily Log Volume
MicroservicesArchitecture
EnabledQA in Production

A global hospitality company was trying to decide whether to move to containers, whether Kubernetes was the right orchestration layer, and if so, which platform. I was brought in as an advisor to create a team, build competing environments, and let the work decide. Within the first week, I identified that the real issue was not technology. It was a deep lack of trust between multiple teams, compounded by strong-willed leaders building what they wanted rather than what their internal customers needed. There was no product function and no clear prioritization strategy.

The Engagement

Working with the internal Director, I built a common language, a shared definition of what the platform needed to do, and a pipeline strategy that enabled internal engineering teams to consume the Kubernetes environments we were creating. This was the foundation that made the technical bake-off productive rather than political.

I designed, built, and automated four competing Kubernetes platforms using Terraform: OpenShift, EKS, GKE, and Tanzu TAS. Each was evaluated through real workloads, not slide decks. Engineering teams operated each environment hands-on through a structured bake-off, and the platform decision was made on demonstrated capability. AWS EKS was selected.

In parallel with the platform evaluation, I architected an aggregated logging platform ingesting 1TB daily from 2,000+ edge software instances, replacing fragmented per-site logging with a single observability layer. I led the decomposition of a monolithic Java application into distributed microservices with a full CI/CD lifecycle, and implemented Istio service mesh so QA could test release candidates directly in production using traffic routing and header-based tracing. Container security scanning was integrated into the CI/CD pipeline before any workload reached production. I built training programs for development, operations, and security teams covering container operations and CI/CD workflows.

Results

  • 4 Kubernetes platforms evaluated through parallel hands-on proof, replacing a process that would have relied on vendor presentations and analyst quadrants.
  • AWS EKS selected based on demonstrated capability with real workloads.
  • 1TB daily log volume aggregated from 2,000+ edge instances into a single observability platform.
  • Monolith decomposed into production microservices with automated build, test, and deploy pipelines.
  • QA gained production-safe testing through service mesh traffic routing, eliminating the dependency on separate staging environments.

Facing a platform decision?

If your evaluation process relies on vendor demos and feature matrices, there's a better way to find out what actually works at your scale.