Hybrid cloud architectures

A hybrid architecture keeps part of the estate on-premises and part in AWS. It is often the first step into the cloud, because it delivers a benefit without requiring anything to be decommissioned, and it is often the end state, because latency, data residency or a physical dependency makes a full move impossible.

The patterns that work share a property: the two halves are loosely coupled, so neither has to know much about the other and either can be changed without a coordinated release.

Pattern 1: cached storage in front of S3

An AWS Storage Gateway appliance at head office presents a file share to users and stores the data in Amazon S3, keeping frequently accessed files in a local cache. Branch offices run their own gateway against the same bucket.

Users see a normal file share; what changes is that the authoritative copy is in S3 rather than on an array somebody has to buy, back up and replace. Durability comes from S3, capacity stops being a procurement question, and branch offices get access to head-office data without a site-to-site replication scheme.

This is the usual first hybrid pattern precisely because the risk is low and reversible: no application changes, and the appliance can be removed if the answer turns out to be wrong.

Pattern 2: middleware into a queue

An on-premises ERP system emits master-data updates. Middleware in the corporate landscape picks them up and posts them to an Amazon SQS queue. Worker instances on EC2 poll the queue and apply the updates to DynamoDB, where cloud-side applications read them.

The queue is what makes this work. The ERP knows nothing about AWS and does not have to stay available while the workers run; the workers can be scaled, restarted or redeployed without the ERP noticing; and a backlog during an outage is absorbed rather than lost. Middleware is often the cheapest place to introduce cloud services into an estate whose core systems cannot be touched, because it already exists to translate between systems.

Pattern 3: VMware workloads on AWS

Organisations with a large VMware estate can move it to AWS without converting the virtual machines. Amazon Elastic VMware Service (Amazon EVS) runs a VMware Cloud Foundation environment on EC2 bare metal instances inside the customer’s own VPC. The vSphere interface, the operational runbooks, the third-party tooling and — importantly — the IP addressing all survive the move, which is what makes this a relocate rather than a rehost.

From there the environment sits inside a VPC alongside the rest of AWS, so individual workloads can be modernised onto managed services afterwards rather than as a condition of moving.

The older approach — the AWS Management Portal plug-in for vCenter, which imported VMs into EC2 from the vSphere client — has been withdrawn. Material describing it is describing a tool that no longer exists.

What these have in common

Each pattern puts a boundary between the two environments that both sides can rely on: a file share, a queue, a hypervisor API. That boundary is what lets the on-premises side stay unchanged while the cloud side evolves, and what lets the migration proceed one component at a time instead of as a single cutover.