The expectation of regular software updates – it's what developers are tasked with, and what users expect and demand. Increased functionality, better performance, and fewer bugs – often in a week or less. Automation of critical processes such as QA can help meet the gargantuan task of constant updates, but it can also send your software into a death spiral of user abandonment unless deployed correctly ...
The adoption of DevOps has shortened and simplified the application development lifecycle. But with an increased focus on speed to market comes an even greater risk that the application will fall short against its objectives. This risk is further accentuated when the application relies — as most do these days — on distributed networks.
To mitigate this, DevOps teams need a means of verifying, at every stage of the development process, how the application performs in the real world network environment.
So what we need, to make sure it's all going to work properly when we put it "out there", is a network that behaves like the real network, but that you can control.
Why not just use the real network itself? Because it's like the weather, it can be fine, cloudy, rainy, stormy, and you simply have no control over it. It is what it is, as they say. And that's even assuming your organization is going to let you introduce an untested application into the real network!
What you want is a network that can be "stormy" when you want, so you can make sure your application works even when the environment is being difficult. What you need is a way of make sure (sometimes called testing!) your application works in the final network.
Now, the problem with most "test equipment" is that it normally lives in a lab. You have to "go there" to use it. That's not much use to developers, operations people, network specialists and more.
What you need is an "extension" of your current, probably benign, network that behaves like a potentially unfriendly real world one. That means you can sit where you are, develop, test, do trial deployments, whatever, accessing current or proposed infrastructure through a Virtual Test Network extension of your network.
Virtual Test Network (Network Emulator) can recreate, on demand, a wide range of adverse network conditions, often encountered in real world networks, in which to test application behaviors. The icing on the cake is that individual members of the DevOps team can control the characteristics of their own bit of the virtual test network without trampling on somebody else's settings.
And a Virtual Test Network is not just for special phases like final pre-deployment testing. It's for everyday and everyone who shares responsibility for designing, developing and deploying applications. So it really should be regarded as a "Must-Have" tool for the DevOps team.
Frank Puranik is Senior Technical Specialist at iTrinegy.