As a performance tester, does the word “cloud” scare you?
I hope not. I hope it doesn’t wake you up in a cold sweat in the middle of the night. I hope the cloud isn’t responsible for that chill you feel down your spine when you think you’re all alone…yet somehow you know you aren’t.
It’s not like we’re talking about clowns here.
Almost every functional department in a business is thinking about how the cloud applies to them. The benefits are clear – it is easier for geographically diverse teams to access and collaborate over data, it is convenient for users, and it can cost far less. When it comes to performance testing, the benefits of the cloud are very compelling. All that load you need to generate to truly test your application can come from external, elastic, on-demand sources. You don’t have to build it out yourself.
However, you may also perceive some challenges that might prevent you from conducting load testing from the cloud. For example: data. If you come from a bank or an insurance company, or some other security-focused organization, you may be trained to say, “We can’t touch the cloud because it puts data at risk.” However, that statement is only as true as the data that goes into the cloud. Feeding a load test with dummy data that simulates users doesn’t put any sensitive information at risk, so this is an area where the cloud could be a great fit.
In this week’s post, we want to talk about some of the challenges you may face when load testing from the cloud and clear up any misconceptions that might exist.
First Of All, Why Test From The Cloud?
We know that most of you have heard of the general benefits of the cloud, but what specifically do performance testers get from cloud-based load testing infrastructure?
First, you can set up load generating machines and perform scalable tests on-demand, to simulate data usage spikes. These tests are much more realistic than tests done inside your own data center because they come from outside the data center, so they validate all the components of the delivery chain including the firewall, DNS, network equipment, and ISP.
Furthermore, load testing in the cloud helps you evaluate the real-world effects of third-party components, such as content delivery networks, analytics servers, and ad servers. There’s also an economic benefit: you can pay for what you need, without having to maintain a lot of hardware that sits unused most of the time. You also save time in that you can set up a machine once and then replicate it through automation tools.
Yes – there’s a lot to love about the cloud. Now, let’s talk about overcoming the hurdles.
What Are The Challenges And Misconceptions?
There are a few key challenges that you may have on your mind when it comes to performance testing in the cloud. Some businesses excel and conquer right out of the gate but for others, it’s a learning process. Here are some key issues and how to address them.
Perception: Troubleshooting Across The Delivery Chain Is Complicated
Anytime you conduct load testing, there’s a good chance you’ll find problems all over the place. Your job is to figure out which problems actually matter. You may think that the cloud will obfuscate those problems and make it more difficult to troubleshoot. How do you tell which layer in the delivery chain contains the actual issue?
Your basic monitoring system will tell you information like the number of hits, response time per request, bandwidth at each layer and even code bottlenecks. If one performance issue is the root cause, you’ll have enough information to resolve the problem. But if multiple variables are the cause, it’s harder to find.
Your best bet is to separate the problems within the firewall from those outside the firewall and start from there. You can use the cloud to isolate subsets of the delivery chain to better help you find root cause problems. Overall, your cloud performance testing can be combined with instrumentation that exists within the app to help you gain even better visibility into where problems exist.
Finally, remember that if it seems like the cloud is creating extra work, it’s worth it because the cloud is a more realistic environment. That means your testing will more closely mimic what users actually experience. You may have more layers to work through, but the end result will be a better test.
Perception: Tests Reproducibility Is Difficult To Achieve
You may think that if you don’t own the cloud, reproducing tests and findings is much more of a challenge.
To some extent that is true. You need to see how fixing performance defects can improve performance, but in the cloud you don’t have all the control you’re used to in a wholly-owned environment. Your sliver of the cloud may actually be a virtual server on a large shared system. You might wonder, “What resources do I actually have and where is the contention?
We all know why Testing in Production (TiP) is important – because it happens in the most realistic environment of all, your production environment. The cloud is similar, as it is not immune to bandwidth limits and traffic in its data centers. In fact, it changes every day. You need to work towards making the environment in the cloud more stable, while improving metrics and overall performance.
If you are concerned about reproducibility, you can embrace the diversity. Your tests are more realistic and that’s exactly what you want. Leverage the variability of the cloud, but tighten up the repeatability within your own environment. That way, you’ll get the test reproducibility you need.
Perception: I Can’t Move All My Testing To The Cloud
Some think that if you make a decision to use the cloud, that means you have to move every aspect of your QA infrastructure to the cloud. This couldn’t be farther from the truth.
You don’t actually need tons of load generators operating all the time. Moving performance testing to the cloud doesn’t mean moving all of your testing to the cloud or even all of your performance testing. Even the highest traffic producing applications were originally tested on a small population, in a controlled data center – and very likely, portions of those apps still are.
Don’t be afraid to test internally and in the cloud simultaneously. You may only need a few machines to run a structure like that, so it can be more cost effective. Use the cloud for what it’s good for: broad scale, distributed load, and test realism. Use your internal environments for constrained and isolated tests so you have no need for overly expansive infrastructure maintenance. Balance the cloud with internal assets and you’ll do just fine.
Perception: The Cloud Will Be A Security Risk
People are very concerned about security and privacy, but cloud providers have all sorts of experts on staff for security. In fact, there’s a good chance that your cloud provider is actually better at security than you can be in your own data center.
If you have real regulatory and/or compliance issues, be cautious and select a provider carefully. Ensure that your service providers are developing virtual private clouds and client partitions in accordance with regulatory guidelines and best practices. Be particularly conscious about data, as data that is stored in a remote location beyond an organization’s legal reach may complicate things. However, if you can keep sensitive data internal, and use dummy data externally, you’ll find exposure will go way down.
Remember, you can use load testing in the cloud without moving all your data to the cloud. So, performance testing in the cloud could be a great way to accelerate a business process without changing your core security policies. (See more security issues of testing in the cloud here.).
Challenge: Unintentional DoS
When you conduct load testing from the cloud, your operations team is going to get a whole bunch of traffic from a single IP address or a set of them. This can look exactly like a legitimate denial of service attack. In a DoS attack, hackers try to bring your website down by flooding it with traffic, so legitimate visitors can’t get in. Security teams look for these patterns and your load test happens to look like one.
Be sure to inform your operations and security teams about your cloud load testing strategy and the schedule. That way they can recognize that the flood of traffic is real and intentional, and they won’t shut down your tests and destroy the work you are doing.
Challenge: Skewed Analytics
Similar to DoS attacks, your load testing can have an unintended side-effect on analytics. Marketers use Google analytics and all sorts of other site instrumentation to monitor how users are doing, evaluate key performance indicators, and draw conclusions. They make decisions on this data about how to change the site and where to invest.
For eCommerce sites, this data is critical for driving revenue. Your load test can mess it up, if people think what you’re doing represents real traffic. Be sure to set up your systems so they filter out your load testing traffic from the cloud and don’t count it as “real usage.”
The Silver Lining To Cloud Performance Testing
While there are certainly challenges to cloud testing, it pays to keep your feet on the ground and head out of the clouds. Keeping your entire team informed about your performance testing plans and potential problems. This will reduce the amount of time and data lost. Set yourself up for success and you’ll be able to enjoy the silver lining to cloud performance testing.