Abstract

“Migrating to the cloud saves money!” “Not running your own infrastructure reduces your bottom line!” “Lift and shift is a legitimate first step towards moving to the cloud!” These are all potential pitfalls if you’re not careful. Proper planning prevents piss poor performance. Using a real chaotic cloud migration as a guide, we’ll walk through the pitfalls of cloud migrations and how to avoid them and the terrifying vendor lock-in (when it makes sense).

Description

Introduction: What is “the cloud” and is it worth moving to it?

  • Opinionated Definition: Compute, storage, network, etc. optimized to work with high levels of redundancy and availability while being maintained and consumed by its users via APIs.
  • Build vs. Buy: It’s definitely worth moving to a cloud provider but consider doing it yourself too; it might be easier in the long run.
  • Colocating could be considered cloud if infrastructure is API driven (OpenStack, Kubernetes, Pivotal Cloud Foundry, etc.)
  • We shot ourselves in the foot by not planning and choosing a very aggressive deadline

Assumption #1: Migrating to the cloud saves money

  • If done right, yes. But, at my previous employer, it was a costly venture.
  • We did not optimize for cost
  • We planned on discounts but didn’t plan or execute how get discounts
  • Pay attention to asterisks!

Assumption #2: Not running your own infrastructure reduces your bottom line

  • CAPEX and OPEX still apply in the cloud.
  • The expectation is that when you help a cloud provider better predict their CAPEX they will pass some savings onto you.
  • We did not realize that early enough and did not plan accordingly

Assumption #3: Lift and shift is a legitimate first step towards moving to the cloud

  • Lift and shift then optimize is a good strategy
  • Those loops have to be very tight though
  • Take the time to optimize often
  • Increase density like you would in any datacenter

Planning is Vitally Important

  • Planning and observing!
  • Monitor everything; find holes in infrastructure and fill them, analyze bill and act often
  • Adopting cloud native concepts is important (Cron jobs to functions, containers to increase density, etc.).
  • Dedicating a technical person towards cloud utilization, spend, and cost optimizations is a wise decision.
  • Business logic really matters; having data to back up specs is important

Vendor Lock-in Kills

  • Your multi-cloud dreams will be fraught with roadblocks unless you plan effectively.
  • If you don’t think Microsoft, Amazon, and Google aren’t thinking of ways to make changing providers difficult for customers you are fooling yourself.
  • Eat your own dog food applies to infrastructure as well
  • Build your freedom and accessibility on top of compute, storage, and networking
  • Use vendor specific features as a way to augment personnel but always put a ticket in the backlog to replace them with something more flexible

Related Content