Tweet
Tweet

Slide 1

Slide 1 text

⁄ Making Sense of Multi-Cloud

Slide 2

Slide 2 text

Armon Dadgar Co-Founder and CTO at HashiCorp @armon

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

⁄ Data Portability

Slide 7

Slide 7 text

I want the option to move my data

Slide 8

Slide 8 text

I want my data continuously available

Slide 9

Slide 9 text

Understanding Costs T0 T1 T2 T3 T4 T5 Option Continuous

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Data Portability ▪ Understand your need for optionality vs continuously available ▪ Both require upfront systems design and discipline ▪ Cost profiles vary dramatically depending on workload

Slide 15

Slide 15 text

⁄ Workflow Portability

Slide 16

Slide 16 text

I want the ability to provision and deploy to multiple environments

Slide 17

Slide 17 text

CLOUD A CLOUD B ON PREMISE ?

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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)

Slide 23

Slide 23 text

⁄ Workload Portability

Slide 24

Slide 24 text

I want to move my workload between environments

Slide 25

Slide 25 text

APP CLOUD A CLOUD B

Slide 26

Slide 26 text

APP CLOUD A CLOUD B

Slide 27

Slide 27 text

Superset of data and workflow portability!

Slide 28

Slide 28 text

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?

Slide 29

Slide 29 text

APP CLOUD A CLOUD B

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

APP CLOUD A CLOUD B

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

⁄ Traffic Portability

Slide 35

Slide 35 text

I want to shift traffic between environments

Slide 36

Slide 36 text

APP APP CLOUD A CLOUD B

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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!

Slide 40

Slide 40 text

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.

Slide 41

Slide 41 text

⁄ No Portability!

Slide 42

Slide 42 text

I want to use multiple environments

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Worst of all worlds!

Slide 46

Slide 46 text

⁄ Conclusion

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Thank You [email protected] www.hashicorp.com