Some people have it, others want it: a test environment to conduct prior checks of system changes. After all, the productive operation of systems that are critical to the company needs to be protected. And the best way to do that is to maintain an infrastructure specifically for testing. But there are pros and cons associated with this kind of infrastructure. Our expert and MVP Eric Berg outlines the pertinent issues and shows how the cloud can offer a promising solution.
In most cases it will be necessary to have suitable hardware and licenses to run a separate test environment. So it’s hardly surprising that test infrastructure accounts for a hefty slice of a company’s budget. The system must also be looked after. For instance, the servers require maintenance, updates have to be installed, and back-ups need checking. All of this adds up to a tidy amount – and for what purpose, exactly?
Test environments are used to a greater or lesser degree, depending on the system and the specific case at hand. Some virtual servers and suchlike are used rarely, perhaps for a few hours during regular worktimes. But system use may rise significantly in other cases, for instance before rolling out a new software release. User acceptance tests – especially when performed on a global scale – place a heavy load on the infrastructure in particular.
The Problem: Test Environments Tend to Differ
Things go wrong from time to time, however many tests are conducted. Updates don’t produce the desired result, software refuses to work the way it should, or adverse side-effects make their presence felt. Almost automatically a user will think in situations like this: “Why didn’t they test it?”
But thats precisely the problem. A test is a test, no more and no less. In most cases a test environment will never look exactly like the productive infrastructure. The resource requirements, the hardware deployment or the load on the systems alone will ensure this. In consequence, testing in this kind of infrastructure will never be able to cover all eventualities.
So if we consider all these factors together, testing on a productive system seems to be the best solution. But how is that meant to work?
Snapshots as a Panacea?
Many companies have adopted a certain procedure due to the progressive virtualization of server resources: they create a snapshot of the virtual server before any update or change in the productive system. This lets them restore the system to its former state and continue operating in the event of errors cropping up.
Proceeding in this way has quite a few pitfalls, though. One of the most frequent errors is that snapshots are not cleaned up after an update. This may lead to obstacles of varying severity, depending on the hypervisor used. For instance, it’s a frequent issue that storage systems quickly become full, as differing data is stored separately after a snapshot.
This method can also cause problems in the system, for instance when updating a system with interdependencies with others, for instance an ERP system, which will affect the database as well during any update. So to roll back the system successfully, it is necessary to restore the database from a snapshot, as well as the ERP system itself.
Influences such as physical systems, differing hypervisors and load states shouldn’t be underestimated, either. So while snapshots can help, they are not the all-purpose remedy for test scenarios.
The Solution: A Copy of the Productive System in the Cloud
A possible solution to this quandary between imprecise test systems and risky open-heart surgery is to make a copy of the productive system. Here, replication mechanisms are used to create a mirror image of the system in an alternative infrastructure. So instead of investing in expensive and high-maintenance on-premises infrastructure, companies can benefit from the flexibility of the cloud.
Replication takes place in Azure, for instance. It is also a good location to put the replicated systems into operation for test purposes. Almost identical infrastructure can be deployed, as the physical and virtual systems from various hypervisors can be copied. Now it is possible to conduct tests on the productive system, without interfering with actual operations.
Besides reducing outlay on infrastructure, this method cuts operating cost as well. The system replication also copies all changes to the productive system – such as updates and co. – to the test world. What’s more, the systems can be activated for test purposes and then deactivated again afterward. This means that you will only incur costs for by-the-minute billing cycles during the active tests.
Test can be performed on productive systems in principle. And the cloud just adds flexibility and safety. It’s also possible to save money and create new scenarios.