Building Hybrid Cloud Across Boundaries

Architecture when you control one side of the system.

The situation

Amazon RDS on VMware extended the AWS managed-database experience into on-premises vSphere environments. Enterprises could provision and run databases in their own datacenters while managing them through the interface they already used in the AWS cloud.

The premise was that a lot of data was not moving to the public cloud any time soon — for reasons of regulation, latency or plain gravity — and that those workloads still deserved managed-service tooling. It was a bet on hybrid cloud as a durable category rather than a transitional one.

I led architecture on the VMware side. AWS led theirs. Neither of us had authority over the other.

What made it hard

Strategically. Hybrid cloud was not yet an obvious place to invest. The prevailing story was migration to public cloud, and this was a bet that a meaningful share of workloads would stay where they were and want better tooling in place.

Technically. AWS’s managed-database experience assumed an environment AWS controlled end to end. A customer’s vSphere estate is not that environment. Hardware varies, networking varies, and operational practice varies enormously between sites. Bridging an automated control plane to an environment it did not control meant that most of the assumptions on each side did not hold on the other.

Organizationally. There was no single chain of command. Decisions were made jointly between two companies with their own priorities, their own release processes and their own reasons to move at their own speed. Escalation did not converge on one person.

What I did

I owned architecture on the VMware side: how the on-premises environment would present itself to the AWS management plane, where responsibility sat on each side of the boundary, and what the interface between them had to guarantee.

Most of the work was making two sets of assumptions meet. That meant establishing what each side could rely on from the other, and being precise about it, because in a cross-company system an unwritten assumption is not a shortcut. It is a future outage with two owners.

We went from concept to launch in about a year.

AWS owned their side of the architecture and their own roadmap. A joint programme structure handled release coordination and go-to-market. My side was the VMware architecture and the contract between the two.

The decisions

Native control plane, or bridge to AWS

The fork. Build an independent VMware-native management experience for these databases, or bridge back to the AWS management plane customers already used.

The call. Bridge.

The cost. A permanent dependency in both directions. The product needed connectivity, and it needed both companies’ roadmaps to stay compatible over time. That dependency is part of why it did not survive later changes in portfolio priorities. It was the right call for the customer experience, and it tied the product’s life to a relationship neither company had committed to indefinitely.

Broad launch or narrow launch

The fork. Hold for broader database-engine support and deeper automation, or launch narrower and sooner.

The call. Narrow, in about a year.

What we gave up was enterprise needs we knowingly deferred to later versions — and later versions have to arrive. A narrow launch buys time to learn and spends the window in which a product has to prove itself. That window turned out to be shorter than anyone expected.

What changed

Amazon RDS on VMware launched, roughly a year from concept, as a joint AWS and VMware product. Enterprises could run databases in their own datacenters and manage them through the AWS interface.

The original product was later deprecated as portfolio priorities changed on both sides, and after Broadcom’s acquisition of VMware. Products get retired. What I take from it is not the lifespan.

It is that I architected a system where I controlled one half, agreed the seam with a partner who controlled the other, and shipped it in a year. That is a different discipline from architecture inside one company.