Speaking with delegates at a Cloud World Conference, I discovered that many are still taking a chance with their mission-critical applications. There seems to be a belief that in order to discover how their apps will work in a real world network, like a WAN or Cloud network, their only option is to conduct tests using the live network.
I was kinda surprised! I mean when do they do this?
At night! — The network loading won’t be the same as that encountered in normal office hours.
During the day! Apart from the risk to the business, if they do have an issue how can they replicate it again to test their fixes?
Some customers even contemplate producing a replica (in part at least) of the live network, until they see the bill, then they stop, give up and say the network is too difficult and put it out of scope!
I thought about the world of aviation and I think the IT world should take a leaf out of their book. How do they teach a pilot to fly their aircraft safely in normal day-to-day conditions and also in extreme conditions encountered more rarely? Do they send them up in a real aircraft and wait for bad weather? No, they use an aircraft simulator. Result: pilots are trained to keep us safe even in conditions that are rarely encountered. This industry does not say “the weather is out of scope”!
Companies that want to ensure that their applications will work in the best and worst network conditions need to do the same thing. Network emulation does for IT what a simulator does for the aviation world, by recreating a wide range network conditions but it’s still not generally used. We either trust that everything will work out OK, or it’s not important, or then again we may not be aware of what can go wrong.
Users of online SaaS applications like Facebook, Google Mail, Google Apps, Skype, Salesforce etc. will have certainly come to understand the issues of poor network on the performance of those applications, with pages not refreshing properly, and generally slowness to load and build them. While there’s not much either the user or vendor can do about that, as the networks in question are public networks, what the vendors can do is to build and test their applications on the assumption of a poor network and thus optimize their applications for less perfect network experience.
Another example comes from a company who learned the hard way! They had applications that worked perfectly well in the field, they had many datacenters in different countries, each datacenter serving a local community of users. Of course, we all know how expensive this is and so, like many of us, their plan was to consolidate their infrastructure into one great big global virtualized datacenter and deliver the application over the network. This move caused the applications to be incredibly slow on start up. Had they deployed a network emulator to simulate the new environment, then they could have easily predicted these issues and therefore they could have solved them before impacting users.
Network emulators are networks in boxes and they can replicate any kind of network you want from a WAN, Satellite, GPRS, WiFi, Mobile, MPLS etc, and you can add varying network conditions from good to poor (repeatably) and start to run the applications exactly as if in “real world” networks.
It makes a lot of horse sense to fully de-risk how things are going to work before rolling out any applications or indeed make any changes to your network environment. Otherwise you will only find out after the applications are live in the field. And now if they don’t work — your horse has bolted. Good luck with getting him back!
This article was first published on APMdigest.com