When you purchase a high-end storage array, it is not generally advised that you half fill the racks and then forget about it, purchasing a new empty rack to fill when next you need high-end storage.

Knowing how the firmware is configured on a BIG-IP, we can chat about some of the more interesting aspects of hardware, firmware, and devices overall. One of the truly interesting bits to me is the proclivity of many organizations to purchase a high-end, bladed ADC system and not fill the rack. I remember way back in the day when my cohorts in the networking and storage (FC SAN) spaces had to worry about the backplane on a switch and how much it could actually handle compared to the sum of the ports you could put on the front. But that isn’t as much  a concern with ADCs (or much of anything else these days), purpose-built devices tend to have plenty of bandwidth on the backplane, and you don’t buy an ADC based off of commoditized hardware that you expect to drop blades into.

But there are a reasonably large number of organizations that have purchased a bladed ADC and then either done nothing more with it than the original purpose, or gone out and bought separate ADCs (normally from the same vendor!) to do new tasks.

And the question there is… Are you really maximizing your infrastructure that way?

We are going through a whole cycle of storage consolidation because our storage needs were met in this manner. There was corporate storage, divisional storage, departmental storage, and in many places team storage, all growing at the same time with no oversight and lots of “we’re completely out of space” at one level while another was overflowing.

We, as an industry,  need to apply the lessons learned there to our usage of ADCs. Sure, you might have purchased that blade rack for project X, but when you kick off project Y, do you really want to purchase all new hardware, or could you drop a couple of new blades into the rack and use any  of the methods various vendors offer to partition off those blades as separate entities? Of course you could. And it would normally be more economically feasible. Of course there are cases where you can show going a different route might cost less, but there are some other considerations to be made. Like power consumption of a whole new device versus a blade, and management of a whole new device versus another interface on an existing device, and of course the cost of setting up and configuring a whole new device versus utilizing the configuration already in place for the other blades and modifying it.

From the F5 perspective, we have attempted to minimize the pain of an all-new configuration with iApps, a very cool feature that handles the details for you, but they won’t initially configure the device, and blades will do a lot of that configuration for you. Indeed, if you are just expanding the capacity of an existing environment, that is automatic. Only if you’re doing new things – new apps, new ADC functionality, new segmentation – do you have to do configuration. If you’re not an F5 customer, you can of course check with your vendor, but I’m willing to bet you’ll have less work putting blades into existing chassis.

And don’t forget that a modern ADC is capable of doing a lot of things. If you’re looking for new LAN/WAN/security/application delivery functionality, check into what can go into your ADC rack while you’re looking at other options. It is entirely possible that the ADC you have could perform the functionality you need, with a single (or simplified) management interface, leaving staff more time to deal with the 10 million other issues that come up in an IT shop in the course of a year. If your ADC is underutilized, it might just be possible that you could start using your ADC for the given purpose with just a license key, saving even more time, and likely some money too.