Special Halloween Edition: The 3 Scariest Mistakes Companies Make in the Cloud

Halloween is here, and that means our attention turns to scary things. Scary movies. Scary TV shows. Scary home decorations. Scary costumes. But when it comes to working with customers and clients on their cloud projects, sometimes I get quite scared and not in a good way. Are you ready? Let's go. Working with customers and clients in their cloud projects, sometimes I get quite scared. I get scared when I hear stories about how a company is preparing to migrate to the cloud incorrectly or when someone shares a misguided plan about how their organization is going to use the cloud, once it is fully migrated. Sometimes I hear stories that downright chill me to the bone. Don't make yourself the central character in one of these horror tales. Instead, avoid these scariest mistakes that companies make in the cloud. Here is the countdown of the top three scariest mistakes you can make in your cloud migration. Scary mistake number three, Stopping a cloud migration too early. During a cloud migration, things can get tense and things can get complicated. It may not be clear that everything will eventually smooth itself out, and your migration will be a success. Especially if this is your first migration and the cloud is new to you, you may see things happen to your application that you were not expecting. You might worry something is going wrong. But this isn't what scares me. What scares me is when people abandon their migration because they don't think it's working. This is very tempting to do. You see this huge mountain of work still ahead of you. You're weary, because of all of the effort you've already put into the migration, and you are worried because you haven't yet seen the advantages of the migration. Worse yet, it might look like things have gotten worse with the performance of your application while the migration is still in progress. This is what I call the Valley of Pain phase. It's the low point of any migration in my InfoWorld article, Don't Stop Your Migration, I talk about the importance of fighting against the motivation to stop the migration right here, when things are their absolute worst. The Valley of Pain is the period of time during the migration where you have invested in the migration and completed part of the process, but have not yet started to see the benefits of the migration. Instead, you are only seeing the downsides. Downsides that are actually an expected part of the migration process itself, and not an indication of what it's really like to operate in the cloud. Downsides seen in the Valley phase include lower application performance, higher cross cloud transfer fees, and increased code and architectural complexity. When people stop because the migration appears too difficult, they tend to stop at this point in the process: when application performance is at its lowest, when cloud usage fees are at its highest, and when application complexity is at its maximum. The truth is it's the worst place to stop. Instead, continue onward, work your way through the valley of pain, and you will start seeing the true benefits of the cloud migration as things begin to look better. You'll start seeing the advantages of the cloud showing through and your application will be better off because of it. Scary mistake number two, using a data center mentality. I get scared when I hear clients talking about the cloud as if it's simply an extension of their existing data centers. They try to describe the cloud using terms and capabilities that they are already familiar with for their existing data centers: server fleets, network bandwidth, capacity planning, warm and hot standbys and spare capacity. For me, this kind of talk is scary to hear because such terms should never be used by someone who is truly thinking in cloud terms. You see, all of these terms are about limits: how do you determine the limits of what your application requires and what do you do when you reach those limits? The cloud, however, basically doesn't have these sorts of limits. For example, answer this question: how many servers can I assign to my application if I receive a sudden increase in traffic? Well, in data center terminology, the answer depends on the number of warm standbys you have lying around, how much spare capacity you can bring online quickly, and your network bandwidth available But in cloud terminology, the answer is as many as are needed, because there are essentially an unlimited number of servers available to you. See the difference? Data center terminology is all about limits, not about expansion and growth. You're defining the limits of what you can accomplish, when the cloud is all about limitless growth. When you think about application limits, you also think about user limits, customer limits, sales limits, and lower revenue and availability. And those thoughts are scary. Scary mistake number one. Using serverless everywhere. Serverless computing is one of the bright, shiny new toys in the cloud. Imagine being able to write a program that can run at any scale without any computers allocated. It sounds like a miracle. AWS Lambda, for instance, the most popular service computing platform out there, sure sounds compelling. Unsurprisingly, a large number of companies begin to think, Why don't I just build everything using serverless computing? Queue the shivers running down my spine. I have heard this statement many times and sometimes from companies that should know better. On multiple occasions, I've had architects from large, cloud-first companies come to me and say proudly: We built this entire application using AWS Lambda. Isn't that great?" Well, no, actually. Serverless computing such as AWS Lambda is great, but like any tool, it can be overused. There are places where serverless computing is wonderful and places where it shouldn't be used. Overusing serverless computing can dramatically overcomplicate the architecture of your application. Additionally, serverless tends to reduce the deterministic performance of your application. Random scheduling fluctuations make your service API calls performance less consistent, and diagnosing performance related defects is almost impossible in a large serverless application. This is all very scary. Make sure you use serverless computing when it makes sense-- not anywhere and everywhere, just because you can. Beware of the scary mistakes companies make in the cloud. Hopefully you'll be able to sleep tonight after reading these three tales of cloud horror. Horror that is based on actual true stories. Take them as a warning and don't turn down that dark path. Instead, learn how to build and operate high quality, highly scalable, highly available applications in the cloud so that your cloud story doesn't end in the dark mist. Thank you for tuning into Modern Digital Business. We release new episodes every other Monday. But don't worry, most episodes aren't normally as scary as this episode. To make sure you get every new episode, when they become available, click subscribe in your favorite podcast player or go to mdb.fm/listen. If you want to learn more from me, then check out one of my books, courses, or articles by going to leeatchison.com and sign up for emails from me at mdb.fm/follow. Thank you for listening, and welcome to the modern and sometimes scary world of the modern digital business.