Cloud app slow? Blame the app, not the cloud

cloud question mark
NETSCOUT's take...

What is your plan for migrating applications to the cloud? Do you lift-and-shift existing applications as is or refactor them before migration? The following article offers some practical advise on how to avoid pitfalls in the cloud migration process.

It’s 7:00 a.m., and you’re in the office early. You’re hoping that nobody else is accessing the public cloud the company uses and that the inventory application will perform well for a change. However, even with just a handful of users on the cloud at that time of the morning, performance is still lackluster. 

The knee-jerk reaction is to blame the cloud provider. The provider is, of course, the host of the application and data thus any performance problems fall on its shoulders, right? Wrong.

Nine times out of ten I’m finding that performance issues are due to application design and the selection of enabling technology, rather than issues with the cloud infrastructure. Keep in mind that if you’re at capacity in a public cloud, you can simply add more. You can even scale on-demand as needed.

But in the case of our slow inventory app, those tricks just aren’t working. 

Back to a rule that I’ve repeated many times:  Crappy on-premises applications moved to the public cloud are just crappy applications in a public cloud.  

What’s happening is that enterprises moving to the public cloud are not looking at the application design, or the use of databases, middleware, or other enabling technology, before they push the application into the cloud. It compiles, it links to the database, data is flowing, good to go.

The reality is that the application will not only perform poorly, but will likely increase your cloud bill by 50 or 60 percent as the public cloud struggles to deal with an application that is not designed properly. Common issues are inefficient I/O, chatty applications, and non-optimized database queries—and those are only a few of the dozens of things that typically go wrong. 

The resolution to this problem is something that most folks in enterprise IT don’t want to hear: The application needs to be refactored. This will include making tweaks to the design and making some parts of the application leverage cloud-native features, such as native I/O, database caches, and a bunch of other tricks to make your applications run well on a cloud, or any platform for that matter. 

I hate to be the cloud buzz-kill here. But make sure you budget time to redo poorly designed applications as they migrate to the cloud, or no matter how early you get to the office to use that crappy cloud app, it will never be early enough. 

This article was written by David Linthicum from InfoWorld and was legally licensed through the NewsCred publisher network. Please direct all licensing questions to [email protected].


As the article illustrates the application migration process starts with analysis of your application reliability and responsiveness on-premises before the act of migration. Even if the plan is to lift-and-shift existing applications it is still necessary to assure that they perform well in their existing environment before the migration. For information on best practices and cloud migration strategies see the following report by the ESG Analyst firm: ~ Michael Segal, Area Vice President, Strategic Marketing, NETSCOUT