Navigating the Many Definitions of Multi-Cloud

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.


Armon Dadgar

October 16, 2019


  1. ⁄ Making Sense of Multi-Cloud

  2. Armon Dadgar Co-Founder and CTO at HashiCorp @armon

  3. None
  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

  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


  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



  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?

  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

  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


  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