Moving Test Environments to the Cloud
Moving Test Environments to the Cloud
Testing is one of the more simple ways to determine if your organization is ready to move to cloud technology.
Join the DZone community and get the full member experience.Join For Free
How often do you get questions like "Have you gone to the cloud yet?", or "Why aren’t we in the cloud?", or a myriad of others along those same lines? People still talk like the cloud is a destination. I discussed this tendency last year in a blog, The Cloud – Is it your actual destination? For all the hype surrounding cloud, the benefits are real. IDC forecasts global public IT Cloud services spending to reach nearly $108B by 2017. Gartner expects that by 2016 the bulk of IT spend will be for the cloud. Those are pretty impressive numbers. The challenge is to remember that cloud is technology - it’s a vehicle, a conduit to help you provide value to the business.
The real challenge is determining what should move to the cloud. Do I go to the public cloud or build a private cloud? Is hybrid the right choice? What benefits provide the best value to the business? Do I move everything?
These are just some of the questions that you should be asking yourself. There is no simple one-size fits all answer. No technology, including cloud, negates the need for good design and planning. How does one make sense of this? You need to put a process in place that identifies, weighs and balances the business needs with the technical challenges.
One potential area to look at as a first step is your test environments. I can already see some of your eyes rolling, but let’s take a look at some of the potential benefits of doing that.
The Challenge of QA and Performance Test Environments
In-house QA and performance test environments have always presented challenges, and many times been the forgotten stepchild in the development process. Every group wants:
- their own isolated, dedicated test environments
- to run on independent build/test/deploy schedules
- to be able to quickly configure/deploy/test changes both on cycle and for hot fixes
- to performance test for scale, load, and capacity so they can understand breakpoints before going live
In an ideal world with unlimited resources and money, this would be easy. Unfortunately in the real world, setting up those kinds of dedicated testing environments tends to be constrained by cost, space, and resources. Hardware/space/resources need to be shared, scheduled, and may run into conflicts. The end result is shared resources, scaled down in size, which may or may not be a good representation of the production environment. Keeping large amounts of hardware around that is not utilized all the time becomes a hard sell, and not one that is usually won. Sharing these resources helps, but inevitably there are schedule conflicts, one project impacting another during the testing cycles. Striking a balance is a pain point many of us are all too familiar with.
Stand Up, Deploy, Test, Breakdown, Repeat
Public cloud providers can be a viable option to help address the challenges discussed. Instead of the classic purchase, configure, and support your own hardware environments, you go to the cloud provider. The public cloud providers have three key benefits to address the testing challenges.
- You can obtain your own dedicated testing environment resources when you need them
- You only pay for what you use
- You can configure for dynamic resource usage, allowing for true performance testing for application scaling and identifying breakpoints
On demand testing resources when you need them. Stand up a test environment, deploy your app, test it, and break it back down when you are done. Dynamic scaling for performance. Sounds wonderful, what’s the catch? No technology negates the need for good planning and design. The cloud is no exception. To take advantage of the benefits the cloud can provide for your testing needs, there are some items to consider and plan for in order to succeed.
- Develop a set of setup configuration and deployment scripts for your cloud environment. All public cloud vendors provide a scripting mechanism for setup, deploy, and breakdown of environments. The added benefit of doing this is you have a standard, repeatable mechanism for standing up a consistent testing environment. Make sure to place these scripts under source control.
- Develop a test data management strategy. If you have one already, revisit to determine if there is any impact caused by moving into the public cloud space. (See my recent blog on test data management in the cloud). As with the environment setup, develop and maintain scripts so that you have a repeatable process for standing up both the environment and data.
- Dynamic scaling is only helpful if your application is designed for horizontal scalability. Again, plan and design are key to be able to leverage the benefit.
Does it Make Sense for Your Organization and Needs?
Using public cloud infrastructure as a service offerings for test environments can definitely have benefits. It can also be an attractive first step and toe in the water for your organization's foray into the world of cloud. Is it for everyone? Not necessarily. You need to evaluate your readiness and ability to leverage the benefits that can be found.
If you are facing the testing challenges discussed, this step could be for you. Success is not automatic. If you don’t already have a well-disciplined DevOps process, this could be a good step in developing one. As discussed, standardizing, scripts, source control, process, are all critical to leveraging the cloud for your test environments.
Cloud technology will not make the magic and success happen. It does provide the opportunity and capability. With proper planning and design, using test environments as your first step, it very well could be the right choice for your organization to start its successful leveraging of cloud technologies.
This post is brought to you by Cloud for Tomorrow.
Published at DZone with permission of Ed Featherston . See the original article here.
Opinions expressed by DZone contributors are their own.