As mentioned in Part 1 of this series, most IT organizations must face the challenge of controlling and managing diverse resources that rarely work together. Managing servers, applications, and network technology regularly requires ad hoc tools and processes. Different application languages, protocols, and even different staff with special techniques ensure that almost every technology solution is a one-off experience.

One area where this presents considerable complexity is when companies begin to embrace “grid” or “utility” computing strategies. It is impossible to miss industry publication headlines covering “grid” or “utility” computing these days. While some tout the dream of auto-magically adaptive servers and networks, others warn that the concept will never work. Whatever the case, the concept of grid computing is intriguing for many and may offer significant cost savings for many. Further, recent advances in technology from the likes of Oracle, Microsoft, and HP suggest the technology building blocks are starting to make the dream a pragmatic reality.

What might surprise some is that grid computing benefits are ready today, even with existing infrastructure. As with application updates, the intelligent network device (i.e. BIG-IP, 3-DNS, Link Controller, FirePass) serves as conduit for IP traffic as well as a control point. Think of it this way; BIG-IP takes a whole group of servers running an application and virtualizes them as one IP address. When a client requests that address (or URL), BIG-IP can decrypt SSL, intelligently balance requests, facilitate application persistence based upon IP payload if required, and even handle health checks for each server in the group. Administrators can also add and remove servers to the group depending on application need or periodic maintenance right from the GUI or CLI.

Now here’s the cool part. The iControl API is to external software applications what the GUI/CLI is to a network administrator. It enables applications (with some help from developers, of course) to tell BIG-IP to do specific things. This can include associating servers with a specific application represented by a virtual IP address, checking the number of existing connections to a particular server node, or even halting new requests to specific servers.

So, imagine a scenario where a company has 40 servers (or, “grid”) deployed throughout the datacenter. Each server is an identical configuration running an instance of the 4 distinct applications (or Web services) that the data center delivers. Based upon predicted traffic levels (as estimated by the business groups) and known performance capabilities of the servers (as defined by the IT group), 20 servers are allocated to application “A”, 10 to application “B”, 5 to application “C”, and 5 to application “D”. In this scenario, servers associated with a specific application via BIG-IP only actively deliver that application.

At this point, everything is perfect. The system is tuned and ready to address the anticipated traffic. But, we all know things usually work differently, right? For instance, marketing (with a 5-minute “heads-up”) decides to kick off an end-of-quarter promotion to boost sales. Before you can spell “S-O-S”, application C, the application required to support the campaign, with its five servers, is starting to sweat like never before. The servers (5) representing only 12.5% of the available capacity are getting 80% of the total traffic! Overloaded is not even close to the correct term; you are more concerned that silicon on each server is going to melt.

The team in the network ops center runs around, scrambling to call in the server reserves, entering command-line instructions to assign more random servers to application C, restarting failing servers, all the while fielding calls from marketing asking, “Why can’t our customers buy our products?”

Does this sound familiar? OK – let’s take a deep breath to enable everyone’s pulse rates to return to their normal operating levels.

Now, there is another option. Remember, the network device can be a control point and by building some basic application logic that talks to BIG-IP via iControl, much of these reactive measures can be automated, from anticipating application problems to managing the process of moving servers from one application group to another.

For example, by coding existing application components (EJBs, COM objects, etc.) to pass exceptions when they reach a certain memory threshold, the exceptions could trigger requests to BIG-IP via iControl to procure an additional server for assistance. Or, by setting basic connection limits to a particular application (via virtual server), once the limits are met, more servers can be requested from a relatively underutilized application and associated with the application in need.

The application could look at all remaining server groups and perform some calculations based upon known connections to each application group and compare it with available server resources. At this point, the application could intelligently determine which application has the most resources available to “release” and then send instructions via iControl for BIG-IP to release five servers from application A and associate them with application C to better handle the requests.

Further, the iControl application could set timers to periodically check all thresholds and release “borrowed servers” back to their original configuration. Or, continue to provide more servers from other application groups until the optimal grid resource associations are established. Rules could even be included to establish a minimum level configuration – one that ensures that each application always has at least two servers to handle requests.

Since each server in this scenario is running an identical configuration, no provisioning is required speeding the ability for a server to provide assistance without delay. This can ensure that customers see the information they are expecting, marketing stops calling, your pager no longer beeps persistently, and you look like the IT rockstar that you happen to be!

This is just another example of how the network device can go beyond load balancing and intelligent traffic management. With the ability for applications and the network to communicate via an API like iControl, it can also serve as control point to help ease burdens of day to day maintenance as well as create new approaches for realizing the benefits of new computing concepts such as grid computing.

Tell me what you think? Would this solve some of your challenges? Email me at

Want to get started? Try the Quickstart Guides for Java, .NET, and Perl.
Have questions? Post them in the DevCentral Forum.