The Top Mistakes You'll Make When Moving to the Cloud

I should've posted this article 3 years ago. I still see customers making the same mistakes they did 3 years ago when they move their workloads to the cloud. I'll show you the most common mistakes and how to avoid them.

This post is a collection of the most common mistakes I see customers make when moving to the cloud. I’ve tried to keep this as short and easy-to-read as I can. Not an exhaustive list. Hopefully there is some insightful stuff here, stuff that goes against the conventional wisdom.

Cost Control

If you are moving to the cloud to control costs, you’re doing it wrong (at least initially). Facts are:

• It’s hard to do an apples-to-apples cost comparison. The simplest reason is because on-prem data center costs tend to be capital expenses and the cloud is almost entirely operational expense. And those capital expenses tend to be spread out over many cost centers and time horizons. It’s hard to track the numbers for comparison purposes.
• You’ve built your datacenter infrastructure and applications given a set of assumptions regarding how your datacenter operates. The cloud is NOT an on-prem data center. You need to think differently when you develop applications and how you support them. When you initially “lift and shift” to the cloud you will pay more because you haven’t yet optimized your applications and strategy.

Don’t make these mistakes:

• Don’t try to use pricing calculators and expect their answers to be close to what your actual spend will be. Cloud expenses are buried everywhere. Instead, have a rough budget to move ONE app to the cloud. Migrate it. Wait a month and examine the bill. What line items were you NOT expecting to see? Is data egress higher than you thought? That’s common. Now, how can you creatively fix that?
• PaaS is never cheaper, at least initially. I call this The PaaS Tax. It will cost you more to use PaaS than to run the same workload in IaaS. Initially. Remember, the paradigm is different from “datacenter” to “cloud”. PaaS becomes cheaper when you leverage PaaS scaling. Since you can’t really scale something like SQL Server in your data center, most people forget this. But in the cloud you can scale down your SQL Server when it is lightly used. That’s how you save money.

Auto-scaling is the best way to initially control costs. I can help you with this, for free! Contact me. ›

• Storage expenses are the smallest line item cost, but can add up quickly when you factor egress charges and bandwidth. Don’t forget this. Using tiered storage and smarter caching can totally eliminate many of these charges. Not to mention they may make your app feel much faster.

Not Having a Good Cloud Strategy

the cheapest vendor is rarely the best…or…understanding your cloud vendor’s business model

Let’s take AWS and Azure. Clearly I’m biased since my employer is Microsoft. But I can be dispassionate too. Frankly, AWS is a fine cloud provider. Their services are top notch. And they tend to often be a bit cheaper than Azure. Sometimes they even have certain features before we do in Azure. But costs are “a race to zero” and features tend to quickly equalize. No one has an advantage for too long.

Here’s the TWO real issues you MUST think about before choosing a public cloud vendor

• Think about your cloud vendor’s business model. Will your infrastructure provider someday be your biggest competitor?
• If the stock market or economy tanks, will your cloud vendor raise its prices to remain profitable and appease Wall Street?

Amazon has only been profitable since 2017 and they haven’t even been profitable every quarter since. In fact, the only profitable division is AWS. This isn’t the case for Microsoft. Microsoft’s revenue and earnings are quite stable and predictable. Microsoft’s PE is much lower, actually about half of Amazon’s, meaning that MSFT stock will tend to fall LESS during stock market corrections. In the worst of times, will your infrastructure provider screw you on price?

Now imagine you are a pharmaceutical services company in 2017. You happily deploy to AWS because it is cheaper and you like the services better. Your developers swear by it. They’d never use Microcrap. That is the Evil Empire. Microsoft threatens the world with its software licenses! Then Amazon buys PillPack. Your vendor is now actively your competitor…overnight. What do you do? Do you still use Amazon (your competitor) as your infrastructure provider? Do you think Microsoft or Google or Alibaba will compete in your space?

The cloud is riddled with vendor lock-in

When using a PaaS service, be aware of vendor lock-in issues. If you do need to move cloud vendors someday, will you be able to? If this at all concerns you, be careful with PaaS. Perhaps containers are a better choice.

Understand security models

AWS has a wildly different security model than Azure. Understand your options for authentication and authorization for your candidate vendors. Understand the cost differences too.

Other concerns:

• Will your cloud vendor backup/replicate your data outside of your political boundary?
• Many PaaS services are public endpoints (that’s how they get scale and profitability). Are you ok with that?
• Understand Separation of Responsibilities. What is your responsibility and what is your vendor’s?
  • Who is responsible for your data integrity and how is that handled?
  • If a service goes down and your vendor won’t fail over to another region, can you manually do it? How?
• Does your network traffic flow over the public internet when moving around your cloud vendor’s regions? Or does your vendor use “dark fiber”? Do you get charged for that? How reliable and stable is it?

Need to do a cloud migration? Need a second opinion? I actually do this stuff everyday. Engage with me for your next assignment ›

Smartly Leverage the Cloud

Not every workload needs to go to the cloud. And you don’t need to begin by “lifting-and-shifting” individual workloads to the cloud. Consider, instead, these alternatives to begin your cloud journey:

• use the cloud for elasticity on-demand. Have your applications, especially front-end servers, leverage the cloud for scaling.
• advanced DR workloads. Why pay for a second DR data center? This is also a great way to get started on your cloud journey. Your staff gets training on cloud paradigms on their schedule. If done correctly you can simply “failover” to your cloud provider and your initial lift-and-shift is complete.
• CDNs are also a great way to dip your toe in the water.
• Pre-baked AI (Azure calls them Cognitive Services) as well as Big Data and Data Science tools are wildly expensive to deploy in your data center, but frankly are cheap in the cloud. The ancillary benefit is that if (when) these projects fail you didn’t have a huge capital project to continue to amortize.

The point is: you don’t need to lift-and-shift existing applications to begin leveraging cloud economics.

Application Optimization is the Key to Cost Containment and Performance

Here are the general phases most companies use to move workloads to the cloud. You can definitely tactically combine features of multiple phases together:

• Phase 1: lift-and-shift (Rehost)
  • VMs are wholesale moved to the cloud
  • the cloud tends to be more expensive for VM hosting, leading to buyer’s remorse. You can never just stop at lift-and-shift
  • this is a good place to start, just note that it’s the beginning, not the destination
• Phase 2: leveraging PaaS (Refactor)
  • move workloads to PaaS where you are no longer managing “Operations”. This allows you to focus on solving business use cases. You want to get out of the HADR and backups business. Let your cloud vendor worry about that.
  • PaaS is generally a bit more expensive (see the “PaaS Tax” above) but ultimately you can lower costs using smarter scaling
• Phase 3: Rebuild for the Cloud
  • rebuild your application so it is cloud-native.
  • use microservices
  • Utilize caching, serverless compute, containers

Moving to the Cloud - Anti-Patterns

Regardless of which phase you ultimately want to get to, there are some anti-patterns that will need to be refactored or your cloud migration will likely fail.

• Chatty applications need to be made less chatty
  • webpages and processes that pull a hundred rows from a database in RBAR (row by agonizing row) fashion will never perform on the cloud
  • IO is the slowest part of any system and this is exacerbated in the cloud. This is why cloud vendors insist you always consider a judicious use of caching.
  • underestimating bandwidth requirements is common. It’s also quite difficult to properly estimate your real on-prem bandwidth requirements.
• polyglot persistence
  • not everything needs to be stored in a SQL Server. Database-as-a-Service is the highest-priced PaaS. Think about what you store in your SQL database today. Does that data really lend itself to a SQL database? Could it work better in a key store? Or an object store? The only data, IMHO, that truly needs to be in a relational database manager is data that ultimately needs to be reported on. Any other data can be persisted more cheaply elsewhere.
• Use microservices
  • When your application is decomposed you can then scale individual components vs entire systems. It’s that simple
  • Most webapps have a handful of functions that require 80% of the processing. Imagine if you could find just one of those functions that could be refactored as a serverless Azure Function or AWS Lambda Function, which could then be scaled independently from remainder of your application. That could save you some serious bucks.
  • Containerization (in general) will help you think in a decomposed manner.

• Have a DevOps strategy and insist on scripting everything with automated build/deploy
  • Gone are the days of having runbooks/manuals with page-after-page of instructions to rebuild a VM.
  • The more you can script and automate your application the more you will understand it and be able to make smarter decisions in the future.
  • Always think in terms of being “ephemeral”. If I accidentally delete some service or VM I should be able to click a button or run a script and have a replacement available within minutes.
    • The side benefit of this is: you don’t need HADR for the compute services any more. Only your data. So…
• Whenever possible, separate “compute” from “storage”
  • In the past your data was locked up in your database server. Don’t do that in the cloud.
  • Try to persist your data to an object store (S3, blob) where individual applications and users can choose the compute engine to match their needs.
    • If my data is in a blob store I may choose to use Databricks to query it and you may choose to use a data warehouse. What I don’t want to do is make a copy of data whenever I want to use a different compute engine. Avoid ETL.
    • Gone are the days where you couldn’t do analytics queries on an OLTP system for fear of performance degradation or lock escalations. Think in terms of the “logical data warehouse” or “semantic query tier”.

Are you convinced your data or cloud project will be a success?

Most companies aren’t. I have lots of experience with these projects. I speak at conferences, host hackathon events, and am a prolific open source contributor. I love helping companies with Data problems. If that sounds like someone you can trust, contact me.

Thanks for reading. If you found this interesting please subscribe to my blog.

Related Posts

• Convert Databricks DBC notebook format to ipynb
• New Presentations and Workshops
• The Top Mistakes You'll Make When Moving to the Cloud
• I'm Speaking at 'Philadelphia Azure DataFest: Advanced Analytics and Big Data Conference' on Friday, December 7
• Azure Databricks Demos