One of the challenges with moving an application from an on-premises environment to the cloud is complacency. The shift appears to be so easy that developers and IT staff might assume that the application will work just the same once it reaches the cloud. They'll minimize testing and QA and proceed with a quick rollout.
That's when the complaints start. If you're lucky, complaints will be the worst of it. If you're unlucky, your application will end up completely offline.
So how should an IT organization smartly approach this seemingly quick and easy process to get that app moved successfully into the cloud? Start with cloud performance testing.
Best practices for cloud performance testing
Use of public cloud services has changed almost everything about how organizations run their IT systems. For applications, cloud computing offers unmatched scalability and less management overhead. All of that is of hypothetical benefit, however, until an application is properly prepared for its new cloud home.
This article is part of
Commit to real application testing
Application developers too often start the application and see that it gets past the splash screen -- but that is not application testing. When the person who developed the application is the one testing it, again, that is not actual application testing. You need users to run through all aspects of the app.
This sort of thorough testing is even more critical with a multiserver application. The application might function, but can you generate reports? What about the speed of data transfers? These functions will probably work well on site. But they may fail in the cloud, where you have additional layers of security that may not have existed in your on-premises environment.
Security measures that block application communications aren't the developer's problem, at least not directly. Still, to come up with a suitable fix, you'll need the skills and cooperation of both the development and IT ops teams.
You want to avoid situations where IT admins and developers end up playing blame games at the same time your users grumble about an application that is not working as expected. Without cooperation, the IT team may decide to simply remove security protections and throw extra resources at the problem in hopes of a quick resolution.
Prevent an app's communication breakdown
Inter-application communication can be one of the biggest gotchas in moving an app to the cloud. Cloud environments typically have more security restrictions on internal communications than do on-premises environments. You'll need to be ready for that.
Construct a complete map of which servers, ports and communication paths the application uses before you move to the cloud. Oftentimes, this communication data is simply unknown -- and if you move to the cloud before you learn it, you will likely struggle to pinpoint exactly what's happening in a new environment full of unfamiliar settings. Your efforts to map application communications can save you hours or even weeks of troubleshooting later. And since you pay for every CPU and RAM cycle in the cloud, delays can be costly. After all, cloud use means cloud expense.
Be sure an app can carry the load
Outside of functionally, it's important to test your application at load as well. Too often, once something works it gets put into production because, well, it works. An application with a dozen users is one thing, but can it function properly when the count of concurrent users hits thousands or tens of thousands?
This is where you need to look at your autoscaling setup. While the cloud can scale to almost unlimited resources, your application must be prepared to take advantage of that, or else you're going to have performance problems. Load-testing software simulates large groups of users, so you can see how your application will behave as usage scales up. This also gives you the ability to tune any autoscaling settings you'll have in the cloud.
It's important to remember that there are different types of application testing, and each has its place. A performance tool tells you what is going on, as a snapshot in time or over time. Load test tools are designed to see how well the app holds up under expected conditions. A further step is stress testing, which hammers your environment to determine the app's breaking point. These tools and test techniques work together; one does not replace another.
Load testing won't be always be possible, so consider a soft launch for the application. While this often requires more steps to ensure the data is kept in sync between the old and new environments, it gives you an option to revert back to the on-premises environment if the cloud environment doesn't work as expected. Falling back to the on-premises version doesn't mean your efforts have failed -- it gives you the chance to correct the issue in an orderly manner, and not in the midst of a chaotic event.