Multi-cloud architecture patterns
This article describes common multi-cloud architecture patterns, deployments and network topologies.
Overview of multi-cloud vs hybrid patterns
There are different situations that may eventuate. The most common case in large companies is that the company is running/managing/upgrading one or more data centers, called on-premises or on-prem.
Usually the first step of the cloud journey is to get some presence in a public cloud provider, hence having on-prem plus one cloud provider. This is a hybrid architecture = on-prem + one cloud provider.
In many cases, what happens is that one cloud provider has a better offering on a certain vertical, e.g., data or a SaaS of preference only runs on a given cloud provider. In this case, we end up with the original on-premises plus two or more cloud providers. This is called hybrid and multi-cloud = on-prem + two/more cloud providers.
Also, there are cases in which a company started in the cloud directly. Usually, the company will start with one provider; and then potentially extend to another, may be due to the better offering on a given service/s or looking for redundancy. This is called multi-cloud = two/more cloud providers.
Overview of the multi-cloud and hybrid patterns
A quick snapshot of the different patterns that this article will cover, which are split between distributed and redundant deployments [2].
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
