Considerations for creating a VM for a development environment
Just because admins are working in a test/dev environment doesn't mean they can be lax about creating VMs. There are several items to consider, including licensing and compliance.
There are a number of considerations virtualization administrators should take into account when creating a VM for a development environment or testing.
Most organizations utilize test/dev VMs for various purposes. Such a VM might be used as a platform for application development or as a tool for testing configuration changes before they are put into production.
Because test/dev VMs aren't used in production environments, they are sometimes created in a somewhat relaxed manner. For example, little attention might be paid to service-level agreement adherence or to VM performance, but that could lead to issues down the road.
Could the VM ever be placed in production?
When creating a VM for a development environment or testing purposes, it's generally assumed that the VM will never be transitioned into production. However, the widespread use of containers in development environments has caused some organizations to rethink this assumption.
Containers can be used for application testing, and then transitioned to the production environment without modification. It's technically possible to do the same thing with VMs, but doing so means that the test VM must meet all of the same security and compliance requirements as a production VM.
Licensing considerations
As a general rule, organizations must have licenses for any software they use. However, test/dev environments might be the exception to the rule.
Microsoft, for example, allows Microsoft Developer Network (MSDN) subscribers to use unlicensed software in non-production environments -- with some caveats. If the organization has acquired the software through MSDN or a similar service, it must ensure that the subscription enables the software to be used in the intended manner.
Some organizations operate free trial software on test/dev VMs. Although this approach can greatly reduce licensing costs, the organization will need to consider whether the tests can be completed within the trial period.
Finally, it's necessary to consider, once again, whether the test/dev VM will ever be migrated into the production environment. If such a transition ever occurs, then the VM will need to adhere to the same license requirements as any other production VM.
VM sprawl in the lab
Another consideration is the potential for VM sprawl. The subject of VM sprawl is commonly discussed with regard to VM lifecycle management within production environments, but is rarely discussed as it pertains to lab environments. Even so, sprawl prevention can be just as important in a test/dev environment as it is in production.
As we all know, IT pros tend to be very busy. When creating a VM for a development environment or to be used for some sort of test, it's easy to abandon it once it has served its purpose. The problem with this, however, is that, over time, it's easy to forget why the VMs were created in the first place. As such, the VMs could end up taking up space indefinitely because no one is really sure whether the VMs are safe to delete.
When creating a VM for a development environment, the creation process should be documented. At the very least, the organization needs a record of who created the VM and what it's being used for. This will make it much easier to implement VM lifecycle management in the test/dev environment.
Compliance considerations
The idea of bringing up regulatory compliance within a discussion of test/dev environments might seem counterintuitive, but compliance is a very real consideration.
The idea of bringing up regulatory compliance within a discussion of test/dev environments might seem counterintuitive, but compliance is a very real consideration. Whether an organization is developing a new application or testing a configuration change, sample data is often required.
Organizations are increasingly adopting copy data management as a tool to enable their development staff to test using real data, but without the cost and complexity of making a physical copy of the data. Any time that real data is used for testing purposes, any regulations pertaining to the use of that data will automatically extend to the testing environment.
VM isolation in the lab
One more important consideration is that of isolation. Test/dev environments are, by their very nature, prone to error. If there was no potential for error, then a testing environment wouldn't be needed.
Because errors and other unexpected events can occur in test/dev environments, it's critically important for the VMs within those environments to be isolated from the production network. A test workload should never have the potential to interfere with anything running in the production environment.
Although test/dev environments have a reputation for being somewhat carefree, setting up such an environment isn't an opportunity to abandon the best practices and controls used throughout the organization. IT pros creating a VM for a development environment or testing must ensure that they are both safe and legal.
