Multicloud architecture patterns

A quick snapshot of the different patterns that this article will cover, which are split between distributed and redundant deployments [2].

Summary of patterns

Distributed deployment patterns

These patterns are most useful when you need to leverage some characteristic, property or feature of a cloud provider.

Tiered hybrid pattern

The classic tiering usually consist of frontend and backend applications. Frontend dealing with end users, customers, consumers or combination of them. Frontends are stateless, in which performance and elasticity is really fundamental to cope with unpredictable workloads. Plus typically dealing with lots of changes, so benefiting of the agile mindset. Backends store data securely under regulatory requirements; and should change less frequently.

The idea in this architecture pattern is to migrate each application, picking a not so complex application first, and then continue case by case. There are 6 cloud migration strategies, typically known as the “6 Rs” (Rehost, Replatform, Repurchase, Refactor, Retain, Retire) [3]. So, an architectural decision will need to be made for each case.

Once migrated, they access the backend via the API gateway centralising cross-cutting concerns such as security, rate limiting, API policies, etc.

Tiered hybrid pattern

This is a good pattern when you are in the middle of the migration journey and the company cannot commit to do it all at once, which is always the case unless it is a simple case.

Partitioned multi-cloud pattern

If portability is a concern for you, then this pattern offers the ability to shift workloads from one cloud provider to another as required. Main advantages are lock-in risk mitigation, ability to pick best features from each provider and regulatory reasons.

Achieving workload portability and consistent tooling across multiple cloud environments increases development, testing, and operations effort. Portability comes at a cost. In order to maximise portability, consider containers and Kubernetes.

Partitioned multi cloud pattern

Cloud analytics pattern

Enterprise Architectures usually consist of transactional and analytical systems. Transactional systems are used to perform every day operations for finance, sales, inventory, pricing, etc. And analytical, typically decoupled from the others due to the different nature and rate of change.

The idea of this pattern is to have analytical workloads in the cloud and feed data back if required. The cloud storage can be implemented with a data lake pattern and use buckets for ingress traffic.

Cloud analytics pattern

Edge hybrid

There are cases in which you cannot rely on 100% connectivity; such as vehicles that are connected intermittently, factories that have availability service level agreements that exceed the link capabilities, stores that need to process critical transactions and a link downtime is not a possibility.

The edge hybrid pattern addresses these challenges by running time- and business-critical workloads locally, at the edge of the network, while using the cloud for all other kinds of workloads. In an edge hybrid setup, the internet link is a noncritical component that is used for management purposes and to synchronise or upload data, often asynchronously, but is not involved in time- or business-critical transactions.

It is also advisable to keep CI/CD practices aligned between the edge environment and the cloud.

Edge computing hybrid pattern

Summary of distributed deployment patterns

5 relevant aspects to be considered when deciding the appropriate architecture: speed of changes (agility), ease of scale, network topology options, security concerns, and reliability.

Distributed deployment patterns

Redundant deployment patterns

These patterns are most useful when you need to increase capacity or resiliency of the overall architecture.

Hybrid environment

In this pattern, public cloud environments are used for development, testing and UAT and then private data centre for Production. Reasons to use this architecture could range from regulatory constraints, Production hardware only available on premise and/or third-party licenses that prevent production workloads in the cloud.

Hybrid environment pattern

All environments must be functionally equivalent, that is the architecture, APIs, and versions of operating systems and libraries are equivalent, and systems behave the same across environments. However, staging and performance testing environments will need to be achieved on-premise.

This pattern could work well, if starting the journey to the cloud, and you want to replace lower environments first; or have agility of creating and bringing down environments easily as need arises.

Business continuity hybrid and multi-cloud

In this pattern the Disaster Recovery environment is implemented in the cloud providing a cost benefit of being able to create it for DR testing and then bringing it down. Also, in case of DR being triggered, using infrastructure as code the DR environment can be created faster hence reducing the Actual Recovery Time.

Business continuity hybrid pattern

The other alternative of this pattern is to have your production environment in one provider and fail over into another, however, less common as usually you can achieve availability requirements within one provider.

Cloud bursting

If you have applications with bursty workload that fluctuates unpredictably, and do not want to over provision during most of the year for some periods of intensive workload. This pattern could be an option and particularly useful for frontend stateless cases in which scaling up and down is possible.

The idea of the cloud bursting pattern is to use a private computing environment for the baseline load and burst to the cloud temporarily when you need extra capacity.

Cloud bursting pattern

This pattern is a good option if you already have on-premise investments that act as a base for most of the year, then you do not need to maintain the extra capacity for the whole year.

Summary of redundant deployment patterns

Redundant deployment patterns

Conclusions

Making decisions on these architecture patterns are complex and will typically involve several company stakeholders with different concerns. This article is a good starting point to understand options and vocabulary on this space. Each situation will require thorough analysis of trade-offs and even various patterns can be used to achieve the Enterprise solution.

References

[1] Multicloud patterns and trends by Pablo Iorio

[2] Hybrid and multi-cloud architecture patterns by Google Cloud Architecture Center

[3] The 6 R’s of cloud migration

Disclaimer

This is a personal article. The opinions expressed here represent my own and not those of my employer.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Pablo Iorio

Pablo Iorio

654 Followers

I enjoy thinking and writing about Software Architecture. To support my writing you can get a membership here: https://pablo-iorio.medium.com/membership