How often is the network rev’ed? How often are the apps that run on it rev’ed? What’s the ratio between the two? 1:3? 1:5? 1:10?

The exact answers depend upon a lot of things, of course.

The most fundamental may be the definition of the network itself, which is a lot grayer than it used to be. Is a virtual switch running w/in a hypervisor part of the network, or part of the server? What about a web app firewall or an L4-7 device that does app-specific redirects, rewrites, content switching, caching, etc.?

App type and industry matter as well. E-commerce apps, Web 2.0 apps, and other Internet-facing apps typically get rev’ed much more frequently – multiple times/month in many cases – than intranet ERP apps. And certain industries depend much more on Internet facing apps than others.

Regardless, in most cases app rev’s happen far more frequently than network rev’s. Or put another way, app-time moves a lot faster than network-time. This is a problem, especially when services that live in the network – services like web app firewall or other L7 services – need to be rev’ed as part an app’s lifecycle, since changes to the app can require changes to the policies in the supporting L4-7 devices.

This discontinuity between app-time and network-time has a lot of repercussions: organizational repercussions, repercussions on how multi-tenancy is handled, and repercussions on how underlying infrastructure gets incorporated into application dev and test environments.

For dev and test, the more a given network service’s lifecycle is governed by a specific app’s lifecycle, the more critical it is that the network service be incorporated into the the app’s entire dev and test lifecycle. And for this to happen, it must be easy to make the network service pervasive across all the various dev and test labs supporting the app.

In mid-July (July 12), Skytap announced the availability of NetScaler VPX virtual appliances in the Skytap Cloud. Skytap has made significant investments to optimize the Skytap Cloud for dev and test purposes – for example, the ability to snapshot and clone multi-VM environments, the ability to support complex network topologies, and role-based collaboration functionality to help coordinate large dev and test teams.

NetScaler is a device that is almost always managed as part of the network. However, NetScaler is part of the (growing) group of network solutions that provides some fairly sophisticated L4-7 capabilities – things like web app firewall, content manipulation like rewrites and redirects and content caching – that are very application centric. As such, these app-centric capabilities really need to tested with the app during the entire dev and test cycle, rather than just validated when development is complete.

What’s slick about NetScaler is that NetScaler VPX virtual appliances offer the same functionality as NetScaler MPX physical appliances. Not the same performance (though a NetScaler VPX can push 3 Gbps), but the same functionality. With NetScaler VPX available in the Skytap Cloud, a lab manager can easily create a template of not just the application, but use NetScaler VPX to include network-based L4-7 services.

Since NetScaler VPX and MPX have identical functionality, the dev and test sandboxes running in the Skytap Cloud can mirror, the functionality running in production, regardless of whether the production infrastructure uses physical or virtual appliances. And, with NetScaler VPX Express – the free version of NetScaler VPX – incorporating core L4-7 functionality into every dev and test instance doesn’t impact licensing costs.

The net effect of this is better network reliability. When the network (or really any piece of shared infrastructure) and an app collide, and something breaks, it is typically the network that gets blamed. Generally, these collisions occur during change management. By making app-centric network services available throughout the dev and test lifecycle, the network itself becomes part of the app’s lifecycle.