How To License Test And Development Environments in The Cloud

Finding the right software licenses for test and development environments is a science in its own right; after all, not only do the requirements change all the time, there are also numerous restrictions. Maximilian Hoppe explains why cloud solutions like Microsoft Azure can be a practical and inexpensive alternative.

Compared to standard users, developers have very different software licensing requirements. After all, the routine ‘tools of the trade’ include far more software products in a wider range of forms such as open source, proprietary or entirely in-house programs. Then there are the continual updates and changing interfaces. It are precisely these factors that make it so challenging to find the best form of licensing for this environment, without paying over the odds or stumbling into a compliance trap.

Restrictions in the Use of Test Environments

This is why software vendors like Microsoft offer special developer licenses for IT specialists that provide significantly more leeway. They include subscriptions for Visual Studio 2017 licenses that are intended to ensure better integration of Microsoft Azure. But most developer licenses have clear restrictions. Only certain server products are available to the users, for instance depending on the edition. These servers are governed by strict rules and must not to be used for test purposes outside of the development environment – which will certainly seem a little strange at first glance.

In regard to Microsoft, “test configuration” means infrastructures to install new software, to ‘test’ whether it is compatible with current infrastructure, and then to remove it completely. In contrast, using constant updates and patches on a fully mirrored infrastructure or with open interfaces to actively used servers would be productive use that needs to be licensed accordingly.

These two environments need to be ring-fenced to remain compliant in this area. The delimitation can be organized along technical lines or by applying strictly logged group policies. It ensures that users only access developer software with Visual Studio and do not need double licenses.

Licensing Risks in Productive Environments

Developers tend not to ask themselves questions in regard to licensing laws. Instead they focus more on technical issues such as the best way of handling continual updates that may jeopardize internal security. For instance, while Word applications with integrated macros mean that updates are urgently recommended for practically every edition, Cloud products are modified more frequently. Classic on-premises applications will usually receive annual or bi-annual updates. But cloud editions can be updated up to once a week.

Test environments are also built to accommodate these frequent changes. Naturally, vendors like Microsoft have adjusted to this situation as well, and now offer companies the option to decide on update cycles more or less at their own discretion. But only at a premium.

To return to the example above: At first glance, many companies may consider it sensible to use old hardware as a test environment. Because hardware that has been in use for four years is completely amortized, and new gear can then be put in.

But this leads to a frequently neglected licensing risk: Migration and isolation (for instance in Oracle databases) only work if the licensing status is included in the equation as well. Some vendors see these setups not as test, but as productive environments. And sometimes it’s minor aspects that lead to double licensing in the event of a software audit:

• Is the system installed on the same hardware infrastructure?
• Could the test environment be deployed immediately if the productive system crashes (mirrored backup)?
• Does the AD access the productive and test environment, which could make it an integrated system?