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.

11ba9630c9136eef9a70d26473d355d5?s=128

Armon Dadgar

October 16, 2019
Tweet

Transcript

  1. 3.
  2. 4.
  3. 10.

    Practical Realities Costs Optionality Continuously Initial Cost Low Low Ongoing

    Cost None Medium Deferred Cost High None Analogy Stock Option Insurance
  4. 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
  5. 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
  6. 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
  7. 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
  8. 18.

    Application Delivery Workflows ▪ Artifact build and distribution ▪ Provisioning

    and managing infrastructure ▪ Application deployment ▪ Securing credentials and managing entitlements ▪ Monitoring and observability ▪ …
  9. 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
  10. 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
  11. 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
  12. 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)
  13. 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?
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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!
  20. 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.
  21. 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
  22. 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
  23. 47.
  24. 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