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].
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.
