$30 off During Our Annual Pro Sale. View Details »

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
Tweet

More Decks by Armon Dadgar

Other Decks in Technology

Transcript


  1. Making Sense of Multi-Cloud

    View Slide

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

    View Slide

  3. View Slide

  4. The Transition to Multi-Cloud
    Traditional Datacenter
    “Static”
    Dedicated
    Infrastructure
    Modern Datacenter
    “Dynamic”
    AWS Azure GCP
    + + +
    Private Cloud +

    View Slide

  5. Flavors of
    Multi-Cloud
    Data Portability
    Workload Portability
    Workflow Portability
    Traffic Portability

    View Slide


  6. Data Portability

    View Slide

  7. I want the option
    to move my data

    View Slide

  8. I want my data continuously
    available

    View Slide

  9. Understanding Costs
    T0 T1 T2 T3 T4 T5
    Option Continuous

    View Slide

  10. Practical Realities
    Costs Optionality Continuously
    Initial Cost Low Low
    Ongoing Cost None Medium
    Deferred Cost High None
    Analogy Stock Option Insurance

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide


  15. Workflow Portability

    View Slide

  16. I want the ability to provision and
    deploy to multiple environments

    View Slide

  17. CLOUD A
    CLOUD B
    ON PREMISE
    ?

    View Slide

  18. Application Delivery Workflows
    ▪ Artifact build and distribution
    ▪ Provisioning and managing infrastructure
    ▪ Application deployment
    ▪ Securing credentials and managing entitlements
    ▪ Monitoring and observability
    ▪ …

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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)

    View Slide


  23. Workload Portability

    View Slide

  24. I want to move my workload
    between environments

    View Slide

  25. APP
    CLOUD A CLOUD B

    View Slide

  26. APP
    CLOUD A CLOUD B

    View Slide

  27. Superset of data
    and workflow portability!

    View Slide

  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?

    View Slide

  29. APP
    CLOUD A CLOUD B

    View Slide

  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

    View Slide

  31. APP
    CLOUD A CLOUD B

    View Slide

  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

    View Slide

  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

    View Slide


  34. Traffic Portability

    View Slide

  35. I want to shift traffic between
    environments

    View Slide

  36. APP APP
    CLOUD A CLOUD B

    View Slide

  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

    View Slide

  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

    View Slide

  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!

    View Slide

  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.

    View Slide


  41. No Portability!

    View Slide

  42. I want to use
    multiple environments

    View Slide

  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

    View Slide

  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

    View Slide

  45. Worst of all worlds!

    View Slide


  46. Conclusion

    View Slide

  47. Flavors of
    Multi-Cloud
    ▪ Data Portability
    ▪ Workflow Portability
    ▪ Workload Portability
    ▪ Traffic Portability

    View Slide

  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

    View Slide

  49. Thank You
    [email protected]
    www.hashicorp.com

    View Slide