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
   

   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
    hello@hashicorp.com
    www.hashicorp.com
    

    View Slide