With Halloween just around the corner, I’ve been thinking lately about scary things. The truth is, I sometimes like being scared when watching a scary movie or reading a scary book. 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.
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. I sometimes hear stories that chill me to the bone.
Don’t make yourself the central character in one of these horror tales. Better to avoid these three scariest mistakes that companies make in the cloud so you can live to see another day.
Scary mistake #1: 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 you were not expecting, and 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. You see this huge mountain of work still ahead of you. You are weary because of all 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, in the Valley of Pain, when things are at their absolute worst.
The Valley of Pain is the point 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 the cloud. Downsides seen in the valley phase include lowered application performance, high cross-cloud transfer fees, and increased code and architectural complexity.
When people stop because a 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 their 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 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 #2: Holding on to a “data center” mentality
I also get rather scared when I hear clients talk about the cloud as if it’s simply an extension of their existing data centers, another one of the big mistakes companies make in the cloud. They try to describe the cloud using terms and capabilities 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 has no limits.
For example, answer this question: How many servers can I assign to my application if I receive a sudden increase in traffic?
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 how much network bandwidth is available.
In cloud terminology the answer is, As many as are needed, because there are an unlimited number of servers.
See the difference? Data center terminology is all about limits, not about expansion and growth. You are 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 #3: 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, the most popular serverless 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?”
Cue 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 our 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 over-complicate 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 a performance-related defect is almost impossible in a large serverless application.
That is all very scary. Make sure you use serverless computing when it makes sense, not anywhere and everywhere just because you can.
Beware the scary mistakes companies make in the cloud
Hopefully, you’ll be able to sleep tonight after reading these three tales of cloud horror—based on actual events! 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 story has a happy ending instead.
More articles from Lee Atchison: