[DVXPL26] Pragmatic multi-cloud architecture: designing for resilience and portability beyond the hype

Today, most of our applications are hosted in the cloud. But what if we leveraged multiple providers for a single application or platform?

The theory is attractive: cherry-picking the best services from each provider to build the ultimate architecture. The reality? Cloud providers that are "more equal than others" and a labyrinth of technical complexities—where network latency, fragmented data, and incompatible APIs threaten both your SLAs and your peace of mind.

In this session, we will tackle the challenge of designing a multi-cloud platform based on a real-world use case.

From defining bounded contexts to addressing production hurdles, security, and API design, we will navigate the pitfalls inherent to this architecture while highlighting essential best practices.

Finally, we will explore how a thorough understanding of customer needs and a pragmatic risk analysis can guide design choices to deliver a coherent, end-to-end vision.

Transcript

1. #DevoxxPL Pragmatic multi-cloud architecture: designing for resilience and portability beyond the hype
2. 76% of organizations already use a mix of hybrid, on-premise and public-cloud infrastructures. Global Market Insights 2
3. Among the organizations utilizing public cloud infrastructure, 21% have adopted a multi-cloud strategy. Accelerate State of DevOps Report ― DORA/Google Cloud 3
4. What does that mean? 4
5. 81% of multi-cloud users cite managing complexity as their top operational challenge HashiCorp Strategy Survey / Gartner 5
6. Alexandre Touret Principal Software Architect 6 @touret.info blog.touret.info alexandre@piaille.fr alexandre-touret
7. Agenda • What is a multi-cloud platform? • Why? • Design a multi-cloud platform from the ground up • What about customers? • Common pitfalls • Wrap-up 7
8. What is a multi-cloud platform? 8
9. What IS NOT multi-cloud? 9 Different teams for different platforms AND use cases
10. What IS NOT multi-cloud? 10 Hybrid Cloud ≠ Multi-Cloud
11. What IS multi-cloud? 11 Best-of-Breed Redundancy (BCP) Cloud agnosticism
12. Why this pain? 12
13. The main reasons 13 Vendor Lock-In Avoidance Best-of-breed Services Compliance
14. Reality 14
15. Additional human costs • Training • Infrastructure As code setup • Partnerships • Standards • … 15
16. Vendor Lock-In Avoid the usage of cloud specific features Evaluate the impacts of reversibility and the risks of switching 16
17. Cloud Agnosticism “Let’s deploy our stack on Kubernetes, we will then be fully agnostic” 17
18. Your users won’t care about it! Your users want ONE unified service NOT a multi-cloud platform 18
19. Let’s design a multi-cloud platform 19
20. The user’s needs • Real-time tracking of vehicles • Data analytics and reporting • Predictive maintenance and route optimization • Customer-facing applications • Payment processing services 20
21. Strategy Choose the best products (Best-of-breed) Make partnerships with other pure players if needed Avoid reinventing the wheel and streamline implementation costs 21
22. The methodology 22 Bounded contexts Data ownership Business processes Choice of solutions NFR Vendor Lock-In assessment
23. Bounded Contexts 23 Real-time tracking Data analytics and reporting AI & Machine Learning Customer- facing Payment processing
24. Targeted solutions 24 Bounded Contexts AWS GCP Real-time tracking of vehicles AWS IoT Core GCP IoT Core Data analytics and reporting AWS Redshift GCP BigQuery AI and machine learning for predictive maintenance and route optimization AWS SageMaker GCP Vertex AI Platform Customer-facing applications AWS Elastic Beanstalk GCP App Engine Payment applications AWS EC2 GCP Cloud compute
25. What about implementing a new solution? 25 It depends… Architect’s typical answer
26. Interactions 26 Real-time tracking Data analytics and reporting AI & Machine Learning Customer- facing Payment processing Consider cross-cloud providers transactions wisely (i.e., as two different systems) Use the same standards as for remote connections Spoiler alert: you will get exceptions
27. At a glance 27
28. The fallacies of Multi-Cloud Distributed Programming • The network is reliable • Latency is zero • Bandwidth is infinite • The network is secure • Topology doesn't change • There is one administrator • Transport cost is zero • The network is homogeneous 28 https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
30. Loosely coupled systems 30
31. Loosely coupled systems 31
32. How to mitigate latency issues? 32 Timeouts "Avoid saturating resources / avoid f v “ Circuit breakers " ' m “ Graceful degradation "What is left of my MVP?" Retries "Mitigate intermittent unavailability" Exponentional Backoff "Avoid the domino effect"
33. To sum-up 33 Clear Boundaries & contexts Explicit Data flows Pinpoint cross-cloud transactions Check whether you need to synchronize data
34. Non-Functional Requirements (NFR) 34
35. The SLA trap 35 99% 95% I need a 99% SLA
36. Few guidelines • Try to create specific cross-cloud transactions with lower expectations (performance, SLA) • If you have strong throughputs, evaluate alternative solutions such as caching • Feel free to challenge your NFR vs your design (and the other way around) 36
37. Compliance 37
38. Compliancy at glance 38 HIPAA HDS KRITIS PSD2 PCI-DSS CERD OIV
41. Isolation • Don’t mix sensitive / non-sensitive workloads • Isolating sensitive workloads may simplify the security scope (audit, delivery) 41
42. Security 42
43. Identity & access management 43 • Each cloud platform handles its own technical users and IAM policies. • There are completely independent Technical Users • Keep only one SSO • Federate the Identity Providers End users
44. Authorization 44 Policy 1 Policy 2 An example using RBAC
45. 45 Authorization on customer-facing apps only Authorization on both
46. Many Identity Providers (IdPs) 46 John Doe John Doe Mapping of roles through claims W/ Keycloak : Advanced Claim To Group
47. Data 47
48. Data ownership 48 Real-time tracking Data analytics and reporting AI & Machine Learning Customer- facing Payment processing Where is the cars data repository? Where is the user data repository?
49. Synchronous vs Asynchronous 49 f m m
50. Pros & Cons 50 & w T T & N w w & T w x Asynchronous Synchronous
51. Data portability: The replication trap 51 v
52. Users mapping 52 J J Email, ID, address,…
53. Personable Identifiable Information (PII) • You can manage PII at every stage of its lifecycle independently with every cloud provider • You must have an end-to-end overview of how data is managed 53
54. Performance & FinOps 54
55. Network latency & costs: The real enemy 55 55 I need to reach my API under 100ms T1 + T2 + T3 < 100ms ? T1 T2 T3
56. Network Latency vs FinOps: Trade-offs from Day 1 56 • Co-locate the landing zones in the same geographic region (e.g., Paris) • Check SLO and mitigate risks • “ ” • Prefer Internet over dedicated VPN • Track Egress costs
57. Example • 100 TPS • 0,5 KB request payload • 1KB response payload ~260GB per month 57 Internet V N /
58. Vendor Lock-In 58
60. (How) Am I locked? 60 Use case AWS /GCP Alternative Cost of migration Real-time tracking of vehicles GCP IoT Core MQTT broker Data analytics and reporting GCP BigQuery Databricks AI and machine learning GCP Vertex AI Platform IBM Watson Customer-facing applications AWS Elastic Beanstalk MS App Azure Payment applications AWS EC2 Any VM
61. What about instantiating my own MQTT broker? 61 It depends… Architect’s typical answer
62. Multi-Cloud from a customer’s perspective 62
63. API: Hide fragmentation to users Two separate public API = Poor UX 63 Set up a global API gateway on any of the cloud providers and unify the interfaces (API, error handling) Use Back-For-Frontend
64. Implement specific Observability on every cloud platform Depending on the volumetry, merge the metrics (e.g., every 2 min) Implement global observability (from end to end) Create global dashboards & alerts 64 Gather metrics, observability figures Observability: One dashboard to rule them all
65. Common pitfalls 65
66. Top 3 pitfalls to avoid 66 Over-coupling services across cloud Bidirectional data sync Ignoring network cost upfront Compliance bolted on later
67. One more on the roll… 67 Forget the customer’s perspective while designing
68. Wrap-up 68
69. Architecture Decision Checklist Which workloads stay together? 69 What NFRs per workload? Where compliance friction? What data sync strategy? What about the network budget? How to provide a unified interface?
70. Checkout the strategy Identify the bounded contexts Challenge your choices with the costs and SLO Assess and challenge your choices with the NFR 70 Canvas Pinpoint the target cloud solutions API / Observability unification
71. To sum up 71 Multi-cloud is not a silver bullet Complexity is real Check the strategy out upfront Think from a customer’s perspective Be pragmatic!
72. Want to go further? • https://blog.touret.info/2026/03/12/multi-cloud-from-the-trenches-part1/ • https://blog.touret.info/2026/04/16/multi-cloud-from-the-trenches-part2/ 72
73. Thanks QQ 73 Alexandre Touret @touret.info blog.touret.info alexandre@piaille.fr alexandre-touret