After you collect a few weeks' worth of data on what your network really pushes, you'll probably be surprised to find that the cores aren't really doing that much. If it's ancient 100Mb Cabletron gear, then you already know you have problems. But if it's modern stuff, you'll probably find that they're ticking over at idle, and maybe blinking slowly during the backup window. If you're using iSCSI for a virtualized infrastructure, you've probably already found whatever gremlins existed in the dedicated network gear you're using for that and are running without problems there.
Start peeling back the onion and looking at the services you provide. Databases can be worked pretty hard depending on the user load and the quality of the front-end code; storage can be beaten down by poorly written software that attacks it with tons of small reads and writes. But you may also find that the services you thought handled the heaviest loads actually run in the middle of the pack or even further behind. Meanwhile, a legacy application is kicking the crap out of a mostly forgotten four-year-old server.
Naturally, all of this boils down to proper and excruciatingly thorough network monitoring. If this doesn't exist and isn't used in every purchasing decision IT makes, then you're doing your budget -- and your organization -- a disservice.
Servers are meant to be worked. Load averages of 1.00 on Linux boxes are not bad things. I don't know how many times I've found folks who think that their Linux servers are overtasked when they sustain 0.75 1-minute load averages. If we're talking about a quad-core box in just about any socket permutation, a sustained CPU load of 3.00 would be when I'd start to think about a hardware upgrade. Anything less than that -- excluding loads derived from waiting for storage and network -- and all I'd see is a server that's doing its job with some room to grow. And with the prevalence of virtualization, you can easily add CPU and RAM resources to a virtual machine later on.
So rather than buying your sales guy a bigger boat, focus on the reality of what your plan really needs based on what you see from your existing infrastructure. Map that out, and then maybe bump the specs up a notch or two to assuage the nagging nabobs of negativity that will undoubtedly try to condemn this stance. You'll find that you can spend less in a variety of ways, from up-front cost to power and cooling, without sacrificing performance.
That's when you negotiate a raise based on overall IT cost savings -- so you can buy yourself a bigger boat.
This story, "How hard does your network infrastructure really work?" was originally published at InfoWorld.com. Read more of Paul Venezia's The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.