Test and Development Environments
[dropcaps type=’square’ color=’#ffffff’ background_color=’#e04646′ border_color=”]I[/dropcaps]t’s pretty clear that production environments enjoy premier status in most data centers. Production gets the fastest storage, the biggest servers, and all of the supporting services which make the application magic happen. Meanwhile, the poor test and development (test/dev) environment doesn’t get all that much attention.
Let’s take a look at what the test/dev environment supports. Test/dev consists of important activities, which include:
- Testing new application versions as they are released in order to determine potential impact on production.
- Creating new custom software to serve the needs of the business.
- Having a place to perform unit testing and load testing for new software being created by developers.
In fact, in some organizations, even the developers’ development machines are virtualized, and they work against virtualized instances of production software to ensure that their efforts will translate well into production.
The State of Test/Dev Environments
In many companies, test/dev environments are often given leftovers and hand-me-downs. For example, production servers that have been decommissioned might be moved to the test lab or to a development lab. These servers are configured just like they were three to five years ago when they were originally purchased, and they generally do not have warranty support. Further, they use hardware that is one or two generations removed from current products.
The same goes for your storage systems that support the test/dev environment. Storage might consist of the old SAN that was removed from production. Or it might include a cheap array of disks which provide reasonable capacity but is lacking performance.
At first, this may seem like a reasonable thing to do. After all, test/dev is a lower priority than production, right? Well, there are a few reasons why test/dev is more important than you might think:
- Time is money — That’s the old adage. By using older, slower equipment in test/dev, you waste staff time that could be better spent doing other things.
- Development efficiency — Your developers are likely among your higher paid staff. The more you short-change their work environment, the slower they work and the less efficient they become. This leads to slower overall development time and increases time to market for new features, products, and services.
- Work stoppage — Not having a warranty equates to having non-existent or slow service, if and when equipment fails. Failure in test/dev means that a critical piece of your environment is no longer available.
The Impact on Production
In most organizations, it’s good to make sure that the test/dev environment resembles the production environment, especially when it comes to developing software and pushing it from test/dev to production. When there is massive variance between test/dev or when test/dev is not sufficient, bad things can happen, including:
- Perplexing performance — An inability to truly determine how well an application will perform in production means that you can’t quickly resolve performance related problems. When hardware between production and test/dev isn’t close, applications will probably run very differently. This means you can’t easily predict how well applications will operate.
- Elevated expenses — Some say that having underpowered hardware in test/dev actually makes sense since it means that, if an application performs well there, it’s guaranteed to work well in the more robust production environment. In essence, they’re saying that overbuilding production makes sense. That means that you’re buying resources you may not need.
- Insidious inefficiency — The fact is that having two complete sets of hardware doesn’t always make sense, even when it’s necessary.
- Dubious data defense — Many people don’t do data protection in test/dev since it’s not as critical as production. For those that do a lot of internal development, they often do take steps to protect code, but not always to the level that they do in production and they may leave test/dev more vulnerable than they would like.
When There Is No Test/Dev
There are companies that don’t have any test/dev environment. They don’t have the budget, the personnel, or the space to stand up a complete test environment, so they operate by directly updating production before performing complete testing. This is relatively high risk activity that can be disastrous if a mistake it made. We recommend having at least some kind of testing capability to make sure that updates to production don’t result in downtime.
Hyperconverged Infrastructure in Test/Dev Environments
Once again, the right hyperconverged infrastructure solution has the potential to address all of the challenges identified in the previous section. Further, with the right solution, you can also add test/dev capability to companies that may not have had it in the past.
There are a couple of ways you can stand up a test/dev environment using a hyperconverged infrastructure solution:
- Build a separate environment
- Add an additional node or two to production
- Use hyperconverged infrastructure for test/dev only
Each of these methods has its own benefits. Building a complete environment that mirrors production makes it possible to truly see how well applications will perform in the production environment and also provides plenty of capacity to allow development to take place. Figure 1 gives you a look at how such an environment might be structured.
Figure 1: Building out two environments to support separate test/dev and production scenarios
Further, this method makes it possible to use each hyperconverged environment as a replication target for the other. You can protect production by replicating it to test/dev and vice versa. When you stand up the environment like this, you can also take advantage of any global deduplication capabilities offered by your hyperconverged infrastructure platform.
This is a key factor in containing costs. In essence, you can deduplicate the entire environment, and, since test/dev mimics production, the capacity savings can be huge.
If you don’t need a complete replica of production, you can also opt to simply add an additional node to your existing production hyperconverged infrastructure environment. As is the case with building a completely separate test/dev environment, you will still enjoy the incredible capacity savings that come with global deduplication. This benefit is also for the same reason —the test/dev workloads mimic production, so even though there are a lot of identical blocks floating around the workloads, each of those only has to be stored one time.
When it comes to disaster recovery, you have a few options as well. With a separate environment scenario, you already know that you can do disaster recovery between the two environments via replication. With a hyperconverged infrastructure solution that deduplicates across the entire environment, you will save a whole lot of storage capacity. Also, if you choose to simply add nodes to production to handle test/dev needs, you can still replicate everything from production to a secondary site if you have one. Regardless, you will still be able to withstand the loss of a node in the cluster while maintaining operational production and test/dev capabilities.
There is also a third potential use case: using hyperconverged infrastructure for test/dev only. It’s entirely possible that you already have a well-running production machine and you don’t want to move it to hyperconverged infrastructure. There’s not reason that you can’t consider using the architecture for test/dev only. This will ease the administrative burden in test/dev and avoid the need to get too deep into the technical weeds for that environment. Things will just work. You won’t need to buy a separate SAN and you’ll get very good performance for this critical infrastructure arena. Further, since you will probably have a lot of different copies of the similar virtual machines in test/dev, you’ll be able to get great benefit from any data reduction services that may exist in the hyperconverged infrastructure solution.
With hyperconverged infrastructure, you will not have to maintain the IT skills around the dev/test SAN and other needs and will be able to focus the development budget on application development. There are also some other benefits that can be had by using hyperconverged infrastructure in test/dev:
- Allows you to keep pace with business needs by quickly turning around incremental asks in a production-like environment
- Ability to clone production environments and integration environments in minutes
- Having a well defined process that includes ways to push changes to production including creating backup of the original environment to have ability to roll-back
- Developers and businesses would like to adopt a SaaS model for test/dev and are looking for cloud like elasticity and ease of getting environments established
It’s clear that test and development environments can be significant assets, but they’re only useful if they’re leveraged in a way that supports the needs of the business.