SOA and Server Consolidation

There are two key Virtual Server design patterns that can be worth their weight in gold for designs like this:

1) "Bounceback" virtuals

2) Network virtuals

For scenarios like this, it's common for one application container to need to access some other service behind the BigIP - for example you've got a web app that needs to call some other Web Services layer to get something of interest (a very common setup in Portal-type applications).

To help wire this all together in a solid way that will scale, you can simply use a "bounceback" virtual server. In other words, the application servers call the web services tier like normal, but it's actually a virtual server that points to the web services tier. Note that you may need to turn on SNAT here because if the systems in question are on the same VLAN you'll have routing issues.

This design pattern allows you a whole bunch of flexibility that you wouldn't otherwise get with static mappings, and I've personally gotten a ton of mileage out of bounceback virtuals.

The other useful pattern is a network virtual server, which essentially forwards packets. But again, the BigIP adds a bunch of value that you'd otherwise not be able to get. For example, let's say that you've got a farm of XML-RPC systems that live on a specific network that the BigIP can see,and the XML-RPC systems all listen on, say, port 9090. You can setup a virtual server that looks like this:

    
 0.0.0.0:9090

which forwards to the destination network.

What does this buy you? As it turns out, XML-RPC tends to hate Nagle's algorithm. By passing this flow through the BigIP it's a trivial exercise to customize your tcp profile and disable Nagle's, which in turn enhances your entire app delivery architecture.

Powerful stuff.

-Matt