Cloud Deployment Patterns

M. Ali Syed,
Head of Cloud & Chief Architect, EMEA, Virtusa.

The simplest cloud adoption would be using a single public cloud platform. But, life is rarely this simple, specially with the large enterprises. Because workloads, infrastructure and processes are unique to each organisation, the cloud strategy must be adopted to their specific needs.

There are mainly two kinds of cloud adoption models:

1. Hybrid cloud (public cloud connected to private compute environment)

2. Multi cloud (more than one public cloud interconnected and/or connection to private compute environment)

The business drivers behind why an organisation might want to adopt any of the above models, is discussed in my previous article on "Polycloud strategy".

The business and development requirements of a specific workload will determine what cloud deployment Pattern to use. While at the same time, operational and architectural requirements, along with the selected pattern will determine which Network topology to use for the application deployment in the cloud. Below we will look into common patterns and networking topologies for cloud deployments.

Deployment Patterns

Every application in an organisation will place some requirements and constraints on architectural decisions which will result in different kinds of cloud deployment patterns. Some of the common patterns are categorised in two sections:

1. Distributed deployments of application - where application is deployed in a compute environment which suits it best. Not necessarily the whole application but every tier could be in different compute environment so that it can benefit from the unique characteristics of compute environment.

2. Redundant deployments of application - where same application is deployed in multiple compute environments to increase capacity or resiliency.

Distributed Deployment Patterns

Thinking about the constraints and limitations that application might have had prior to cloud adoption, these patterns help in capitalising on native features that each cloud environment offers.

1. Tiered - Most applications are of multi tier architecture, and here each tier is matched with its best environment depending on which compute services can be utilised. This is based on Multi-tier architecture, where e.g. frontend could be in public cloud and its logic and data tier could be in private compute environment. This is the most common pattern which is an enabler to cloud adoption as migrating the presentation layer to the public cloud is mostly an easier job compared to the rest of the tiers.

2. Partitioned - This is where each application (in its entirety or not) is moved to a public cloud environment. An organisation may end up with some applications running on GCP while some on AWS (determined by application's needs). Of course, the interconnectivity between the applications remain, giving combined benefits of a multi cloud deployment.

3. Analytics - Applications where transactional and analytics systems are decoupled (or loosely coupled) and where the analytics tier gets its data via an API. This is where the analytics tier is deployed in a public cloud whereas the transactional workload stays in the private compute environment.

4. Edge - Applications which are time critical and are deployed in locations where continuous or reliable connectivity to the public cloud is not possible. This is where the time critical workload is deployed on-premise (private compute), while the administration plane and other workloads of this application are deployed on the cloud. When the connectivity between the environments is achieved the data is brought back into sync.

Redundant Deployment Patterns

These are the patterns where same application is deployed in multiple compute environments with the aim of achieving increased capacity and resiliency.

1. Environment hybrid - Application that will commonly have production environment running in private compute and other non-production environments in public cloud.

2. Business continuity - Application that has mirror running in another compute environment. Typically production running in private and a DR running in public cloud. The aim is to achieve high resiliency.

3. Cloud bursting - Application that is deployed in private compute environment but is able to burst into public cloud for extra capacity, and when the load reduces, the application is able to contract back to private environment only. This requires high level of automation and is difficult to achieve. Adoption of PaaS (e.g. Kubernetes) does make it easier to achieve.

Network Topologies

Connecting multiple cloud environments in a secure and reliable manner is a key to successful hybrid or multi cloud deployment. Below are some of the common network topologies which are used in cloud deployments suitable for either hybrid or multi cloud deployments.

1. Mirrored - Network of private and public cloud mirror each other. E.g. when production is running in private and non-prod environments are on public cloud. The private and public cloud must mirror each other in network design.

2. Meshed - Network that spans over private and public cloud environments in a flat networking fashion where workloads on both ends can communicate with each other over private RFC 1918 IP addresses.

3. Gated Egress - Network where traffic flow is only allowed to egress from public cloud to private cloud. This is typically where application's presentation layer is in public cloud and is communicating with logic tier via the API that is deployed on private compute environment.

4. Gated Ingress - Network where traffic flow is only allowing incoming connection from private cloud into public cloud. This is typically where API servers are deployed in public cloud and the application / workload is in private compute environment.

5. Gated Ingress & Egress - The combination of the above two where API servers are deployed on both private and public cloud environments, hence, connectivity is allowed both ways.

6. Handover - Network connection which allows storage services of public cloud to accept incoming data from private compute environment. This is typically used for data archival where data is sent for longer term storage or even for sending small messages