Navigating the Many Definitions of Multi-Cloud

As an industry, we use the term “multi-cloud” in variety of contexts without any nuance. Digging in deeper, you find that there are many different definitions of multi-cloud, but they can roughly be summarized as workflow portability, workload portability, traffic portability, or data portability. In this talk, we try to define each of these variants and go into the nuance of what each means. You can be multi-cloud with any one of them, and they don’t preclude each other. However, there are very different approaches and implications for each version.

Transcript

1. ⁄ Making Sense of Multi-Cloud
2. Armon Dadgar Co-Founder and CTO at HashiCorp @armon
4. The Transition to Multi-Cloud Traditional Datacenter “Static” Dedicated Infrastructure Modern Datacenter “Dynamic” AWS Azure GCP + + + Private Cloud +
5. Flavors of Multi-Cloud Data Portability Workload Portability Workflow Portability Traffic Portability
6. ⁄ Data Portability
7. I want the option to move my data
8. I want my data continuously available
9. Understanding Costs T0 T1 T2 T3 T4 T5 Option Continuous
10. Practical Realities Costs Optionality Continuously Initial Cost Low Low Ongoing Cost None Medium Deferred Cost High None Analogy Stock Option Insurance
11. Designing System Architecture ▪ Upfront "investment" in design ▪ Proprietary cloud services are a one way street – DynamoDB, CosmosDB, Spanner, etc. ▪ Prevent both optional and continuous data portability
12. Enabling Optionality ▪ Optionality requires that the systems are at least common ▪ Can use hosted versions of widely available systems – MySQL, PostgreSQL, etc. ▪ Provides Optionality – Compatible interface (and maybe implementation) – Ability to import/export, not in real time
13. Enabling Continuous Replication ▪ Continuous requires that the systems support real-time replication ▪ Modern Cloud Native data systems – CockroachDB, Cassandra, etc. ▪ Provides Continuously available – Compatible interface and implementation – Real time replication
14. Data Portability ▪ Understand your need for optionality vs continuously available ▪ Both require upfront systems design and discipline ▪ Cost profiles vary dramatically depending on workload
15. ⁄ Workflow Portability
16. I want the ability to provision and deploy to multiple environments
17. CLOUD A CLOUD B ON PREMISE ?
18. Application Delivery Workflows ▪ Artifact build and distribution ▪ Provisioning and managing infrastructure ▪ Application deployment ▪ Securing credentials and managing entitlements ▪ Monitoring and observability ▪ …
19. The Cloud Landscape DYNAMIC STATIC Dedicated vCenter CloudFormation Resource Manager Cloud Deployment Manager vCenter vSphere EKS / ECS Lambda AKS / ACS Azure Functions GKE Cloud Functions vSphere Various Hardware Proprietary Proprietary Proprietary Hardware Identity: AD/LDAP Identity: AWS IAM Identity: AzureAD Identity: GCP IAM IP: Hardware Private Cloud AWS Azure GCP Provision Operations Secure Security Run Development Connect Networking
20. A Common Operating Model with the HashiCorp Suite C++ Provision Operations Secure Security Run Development Connect Networking Private Cloud AWS Azure GCP CloudFormation Resource Manager Cloud Deployment Manager Proprietary Proprietary Proprietary Identity: AzureAD Identity: GCP IAM Identity: AWS IAM
21. Rich Ecosystem * Lots of options, just a few examples for illustration ▪ GitHub for version control ▪ CircleCI for testing and continuous integration ▪ Artifactory for package management ▪ Kubernetes for application deployment ▪ DataDog for observability ▪ PagerDuty for alerting
22. Workflow Portability ▪ Design common workflow with support for multiple environments ▪ Use agnostic tools in the delivery process ▪ Can use cloud services for application middleware! – Separate delivery process from runtime dependencies – Sticky runtime services cause "pinning" to an environment ▪ Workflow portability does not need data portability (visa versa)
23. ⁄ Workload Portability
24. I want to move my workload between environments
25. APP CLOUD A CLOUD B
26. APP CLOUD A CLOUD B
27. Superset of data and workflow portability!
28. Enabling Workload Portability ▪ Migrating an application requires all upstream dependencies – Avoid proprietary services – All internal services must architect with same requirements ▪ Vast majority of applications require their data – Need to choose between optionally versus continuously available – How often is migration expected?
29. APP CLOUD A CLOUD B
30. Partial Migration ▪ Migrate stateless (frontend) services ▪ Avoid migration of upstream services and data ▪ Massive penalties for network traffic! – Expensive Bandwidth – High Latency ▪ Specialized architectures with complex caching and data management
31. APP CLOUD A CLOUD B
32. Special Case: Stateless! ▪ Requires stateless or static data set ▪ Financial modeling, large scale simulations, testing infrastructure, etc. ▪ Requires workflow portability, but not data portability ▪ Enables cost arbitrage, especially with spot pricing
33. Workload Portability ▪ Requires design for data and workflow portability ▪ Very limited access to cloud services ▪ Impractical for most use cases and organizations ▪ Motivated by hedging against lock in – Workflow portability and optional data portability more practical
34. ⁄ Traffic Portability
35. I want to shift traffic between environments
36. APP APP CLOUD A CLOUD B
37. Traffic Portability Front-end Only ▪ Ingress traffic can reach any frontend ▪ Request may touch multiple environments ▪ Useful for caching and reducing latency ▪ Requires workflow portability
38. Traffic Portability Partial Failover ▪ Data maybe sharded by region ▪ Some backend systems and data replicated between regions ▪ Improves High Availability and Disaster Recovery ▪ Requires workflow portability ▪ May require limited data portability
39. Traffic Portability Full Failovers ▪ Ingress traffic can reach any frontend ▪ Request contained to environment ▪ All systems and data replicated ▪ Max High Availability and Disaster Recovery ▪ Requires data, workflow, and workload portability!
40. Traffic Portability ▪ Ingress only much simpler ▪ Partial/Full generally limited to "web scale" companies ▪ Motivated by lock in, business requirements (e.g. Walmart / Federal contracts), migrations, high availability, disaster recovery, etc.
41. ⁄ No Portability!
42. I want to use multiple environments
43. Signs of No Portability ▪ Using sticky and proprietary services ▪ Lack of common workflows ▪ Applications are pinned to a single environment ▪ Traffic must be forwarded to appropriate region by application ▪ Few initial design considerations, optimizes for day 1 agility
44. Challenges of No Portability ▪ Day 2 operations more challenging ▪ Makes future portability more complex and expensive ▪ Workflow fragmentation causes Day 2 management headache ▪ No HA or DR benefits ▪ Minimal hedge against lock in or negotiating leverage
45. Worst of all worlds!
46. ⁄ Conclusion
47. Flavors of Multi-Cloud ▪ Data Portability ▪ Workflow Portability ▪ Workload Portability ▪ Traffic Portability
48. Design with Intent ▪ Multi-Cloud inevitable for large organizations ▪ Understand the requirements and choose tradeoffs with intent and clear eyes ▪ The "no portability" or no strategy approach is generally worst of all approaches
49. Thank You hello@hashicorp.com www.hashicorp.com