Testing on GCP
Before you deploy an application in production on Google Cloud Platform, you should test the application and its associated infrastructure to see how it will perform under different conditions. In this short course, we’ll give a quick overview of load tests, resilience tests, and vulnerability tests.
- Describe load tests, resilience tests, and vulnerability tests.
- Anyone who deploys applications on Google Cloud Platform.
- Experience with deploying resources on Google Cloud Platform.
Before you deploy an application in production on Google Cloud Platform, you should test the application and its associated infrastructure to see how it’ll perform under different conditions.
There are at least 3 types of tests you should run:
Load tests (where you stress your application with a heavy load)
Resilience tests (where you see what happens when various infrastructure components fail), and
Vulnerability tests (where you see if your application can withstand hacker attacks)
Ideally, you should run load tests before you put your application into production. Your tests should be designed to simulate real-world traffic as closely as possible. You should test at the maximum load you expect to encounter, which can admittedly be difficult to predict for some applications, but hopefully, you’ll have a reasonably good idea of how much traffic you’re likely to get. You should also measure how your Google Cloud costs increase as the number of users increases.
If you’re expecting a wide variation in how much traffic you get, then you should also test how your application performs when traffic suddenly increases. Resilience testing is similar to disaster recovery testing because you’re testing what happens when infrastructure fails, but the difference is that in resilience testing, you’re expecting your application to keep running, with little or no downtime.
One common testing scenario is to terminate a random instance within an autoscaling instance group. Netflix created software called Chaos Monkey that automates this sort of testing. If your application in the autoscaling instance group is stateless, then it should be able to survive this sort of failure without any noticeable impact on users. Since cyber-attacks are extremely common these days, your organization should put processes in place to test the security of your applications. Here are a few important ones:
First, ideally, your software development team should have a peer review process with developers checking each other's code for security flaws. Second, you should integrate a static code analysis tool, such as the vulnerability scanning feature of Google's Container Analysis service, into your Continuous Integration / Continuous Deployment pipeline to automate security checking.
Third, at least once a year, you should run penetration tests on your applications and infrastructure to see if they are vulnerable. You can either do this yourself or contract a third party to do it. Other cloud providers typically require that you request permission before you perform penetration testing on your cloud infrastructure. Surprisingly, Google does not require that you contact them.
Google also provides a useful tool called the Web Security Scanner. This service connects to the base URL of your application and follows all of the links in it while scanning for vulnerabilities, such as cross-site scripting, mixed content, and outdated libraries. It can scan applications hosted in App Engine, Compute Engine, and Google Kubernetes Engine.
And that’s it for this lesson.
Guy launched his first training website in 1995 and he's been helping people learn IT technologies ever since. He has been a sysadmin, instructor, sales engineer, IT manager, and entrepreneur. In his most recent venture, he founded and led a cloud-based training infrastructure company that provided virtual labs for some of the largest software vendors in the world. Guy’s passion is making complex technology easy to understand. His activities outside of work have included riding an elephant and skydiving (although not at the same time).