Capacity alone won’t assure good cloud performance

Many people believe that workloads in the cloud always perform better because public clouds have access to an almost unlimited amount of resources. Although you can provision the resources you need—and even use serverless computing so the allocation of resources is done for you—the fact is that having the right amount of resources is only half the battle.

To get good cloud performance means you have to be proactive in testing for performance, not be reactive and wait for an issue to arrive in production. After all, performance depends on much more than raw capacity.

I strongly encourage testing. If you’re using devops to build and deploy your cloud application workloads, your testing for security, stability, and so on are typically done withcontinuous testing tools as part of the devops process.

But what about performance testing?

Truth be told, performance testing is often an afterthought that typically comes up only when there is a performance problem that the users see and report. Moreover, performance usually becomes an issue when the user loads surpass a certain level, which can be anywhere from 5,000 to 100,0000 concurrent sessions, depending on the application. So you discover a problem only when you’re got high usage. At which point you can’t escape the blame.

An emerging best practice is to build in performance testing into your devops or cloud migration process. This means adding performance tests to the testing mix and look at how the application workload and connected database deals with loads well beyond what you would expect.      

This means looking for a performance testing tool that is compatible with your application, the other devops tools you have, and the target cloud platform where the application is to be deployed. Of course, a “cool tool” itself is not the complete answer; you need testing engineers to design the right set of testing processes in the first place.      

Ironically, although devops itself ( as both a process and tool set) is all about being proactive in terms of testing, most devops processes that I’ve seen don’t do much performance testing, if any at all.     

Withouth that testing, you can’t answer the question “When will my cloud workload hit the performance wall?” Instead, your users find out for you, and you may discover it’s time to look for a new job.