What you’ll learn:
- Be sure to understand how your applications will interact with a cloud environment.
- Emphasize app efficiency to minimize the impact of cloud-native architectures’ complexity.
- Comprehensive validation breeds understanding of cloud workloads.
Last winter, when the “Big Three” hyperscale cloud providers (Amazon, Google, and Microsoft) announced Q4 earnings, they revealed a surprising trend. After years of nonstop growth, the rate of public cloud adoption was suddenly slowing. Despite seemingly every enterprise, public agency, and telecom provider on the planet pursuing a cloud strategy, customers were scaling back cloud investment. What was happening? Had businesses discovered that all of those cloud benefits we keep hearing about were just myths?
No, use of the cloud really does improve speed, flexibility, scalability, and more. In the long run, just about every organization will run at least some of their applications in cloud, whether public, private, or hybrid.
The dip in growth rates was just an inevitable correction to a common misperception among hyperscale customers—that using the “cloud” means cost savings. Facing a slowing economy and a need to trim budgets, many businesses took a closer look at their cloud spending and realized it was far higher than anticipated.
Among other benefits, the cloud can provide cost savings, but that doesn’t happen automatically. Moving to the cloud means relying on someone else’s infrastructure for fundamental aspects of how your applications behave. If you don’t have a clear understanding of how applications will interact with the cloud environment ahead of time—and how to best optimize them for this new world—you might not get the expected performance. Not only that, but you might also end up paying much more than is necessary.
Navigating Cloud Complexity
When hyperscalers tout cloud benefits like improved response times, efficient scaling, and getting closer to customers, those advantages are all real. The problem is that the actual performance and costs you’ll see after migrating have very little to do with anything the cloud provider is doing, and everything to do with how you write and deploy your applications. Too many organizations still assume they can just hand applications over to a public cloud provider, and they’ll just work. But that’s not the case.
Think of migration along the lines of building a house. Anyone can go to Home Depot and buy lumber, bricks, and roofing, but the same raw materials can produce vastly different homes. That’s also true in the cloud.
Everyone uses the same basic building blocks, and hyperscalers can advise you to some extent, but at the end of the day, you’re the builder. If you decide to put the kitchen in the basement and the only bathroom in the garage, you’ve still built a “house.” It has a roof. You won’t get rained on. But you probably won’t enjoy living there.
The importance of optimizing for the cloud has only grown in recent years as the industry shifts to cloud-native architectures. Containers and microservices bring real improvements in flexibility and efficiency, but they also make software architectures far more complex (see figure).
Even when businesses rewrite applications to be cloud-native—which is the correct strategy whenever possible—they often fail to ensure that they’re writing them to run efficiently. Add the wrinkle of hybrid deployments, such as on-premises applications that can burst into the cloud, and things get even more byzantine. Your own elements now interact with cloud elements in highly complicated ways, making it hard to predict how applications will perform or what they’ll ultimately cost.
The only solution is to thoroughly test applications in new cloud environments before pushing ahead. But most organizations still don’t. That’s due in part to the continuous deployment mindset that many businesses have adopted. If you’re constantly pushing out updates, you don’t have to worry about how you deploy in the cloud, right? If something breaks, you’ll just fix it with the next update.
However, if you haven’t optimized efficiency, continuous deployment won’t address that. Nothing is broken. Your users are fine. You’re just spending far more than necessary to keep them happy.
Competitive pressure to move faster doesn’t help either. It’s common, for example, for developers to write applications with very resource-heavy requirements just to get them working. But in the rush to market, they often skip the optimization step that’s supposed to come next. No one considers how much those excess resources really cost until the bill comes much later, and often after the developer has already moved on to another project.
But as more customers now realize, the meter starts running the moment you deploy. And the cost of inefficiency can get very high, very quickly.
Validation Before Migration to the Clooud
How can you avoid these missteps? The answer is comprehensive validation, so that you fully understand the performance, security, and resource consumption of every cloud workload in both peak and off-peak scenarios. Test for:
- Performance: Start by measuring an application’s current performance, so that you have a baseline. Next, you can (ideally) start the process of rewriting it as a cloud-native application. But while containers can theoretically run anywhere, that doesn’t mean they’ll run equally well or efficiently. You’ll need to thoroughly test performance in all scenarios, especially in complex hybrid cloud deployments.
- Resiliency: How does the application hold up under peak traffic loads? How well does it recover from failures? Resiliency is part of the reason why you’re paying for a hyperscaler, but failover performance and costs can vary greatly depending on how you’ve written the application. Architect intelligently, and you won’t need the most expensive cloud services. The only way to tell is to exercise failure states, measure results, and cost-optimize.
- Security: Moving to a cloud adds new security complexities, as you’re now both physically and logically distributed. It’s critical to thoroughly validate that all policies are implemented properly and that your security posture remains airtight. It’s also now critical—and often overlooked—to understand how your cloud applications perform while under attack.
- Cost: Cloud providers offer myriad services, APIs, and configuration choices, giving you thousands of options for implementing an application. But every decision can affect your costs, sometimes dramatically. Pricing is often based on microscopic measurements—how many times an application writes to a hard drive, how many bytes pass between locations—and it’s almost impossible to accurately predict what a given option will cost. The only solution is to test all scenarios with real traffic. Therefore, you can quantify the value of each choice or change.
Cloud migrations get complicated, but the recipe for success is straightforward. Capture comprehensive profiles for all applications across compute, storage, networking, and more. Measure resource consumption, traffic volumes, latency, and other factors, so that you can make informed choices about cloud options.
The good news, once you recognize the proper role of testing, is that you can avoid costly cloud missteps. You can move faster, because now you can push out cloud-native software with confidence, knowing it will work intended for a price you expect.