Cloud app slow? Blame the app, not the cloud

Those who complain about cloud performance often overlook the obvious. It’s the application, dummy

Florida Gopher Tortoise
Craig ONeal (CC BY-SA 2.0)

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. 

Related:

Copyright © 2017 IDG Communications, Inc.