Geek Culture
Published in

Geek Culture

Multicloud architecture patterns

This article describes common multicloud architecture patterns, deployments and network topologies. It is the second part of the multicloud trends article published some weeks ago [1].

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.

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.

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

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

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

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.

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.

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.

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.

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.