Managing infrastructure, a newbie's guide: Simple stuff you need to know
Even if you do know it all already, it never hurts to refresh the basics
We all have IT and telco infrastructure equipment that's getting older. Time marches on and few of us have the funds or resources to renew everything when it reaches its official point of being written off by the bean-counters.
We all, then, have some kind of legacy kit clinging onto its existence – even if it doesn't quite meet the stereotype of that dusty “crucial” ACC Congo router that's been sitting doing something mysterious since 1997.
Here's a seven-step guide to dragging your infrastructure kicking and screaming into the current century.
1. Draw a hardware obsolescence timeline
The first thing to do is get ahead of the obsolescence curve, and you need to consider the two types of hardware you own: stuff that's out of date, and stuff that will be out of date at some point.
It's worth noting that just because something's no longer considered current in terms of your finance department's depreciation model doesn't mean you have to throw it out: for instance, I just picked a Cisco switch at random and it doesn't stop being formally supported until six years after they stopped selling it.
You must, however, draw yourself a timeline for all the devices you rely on so you can budget over time for their replacements.
2. Standardise your networking
If you have a mish-mash of network technologies and vendors, bring them together into as few as possible (preferably one). This doesn't mean you absolutely need to go and spend £5,000 per switch for top-end blue-chip hardware, but make sure you go for something that is at least a well-known name, supports all the right networking standards and has a proper management layer and proven performance.
These days it's rare to find anything but Ethernet network technology, although I did just find a 24-port Cisco Token Ring switch on eBay for £56... I think I'll stick with boring old Ethernet!
Incidentally, don't think you have to go mad and put in 10Gbit/s Ethernet to every phone, printer and desktop – just standardise on the vendor and pick multi-speed switches at the access layer to make life easy.
3. Look to the cloud
Just as your hardware has a finite lifetime, so does your software. Again, draw a roadmap that shows you the relative dates when your apps will need to be upgraded, and well in advance of the death of each app look at how you might implement the next version.
I can't help liking Office 365 and the cloud-based flavour of Websense (or ForcePoint Triton as I'm meant to call it these days), for instance, and in both cases I've historically been known to abandon the standard local-install version for a more usable, flexible cloud-based alternative.
I'm a big believer in cloud-based storage, too: I just can't help thinking that virtualising at least your low-performance storage into the cloud (your offline data archives, for instance) is going to grow massively in popularity over the next couple of years.
4. Integrate your applications
This sounds like a biggie, but actually what I'm getting at is that you should integrate the authentication for as many of your applications as you possibly can. Legacy apps with their own internal user databases are a terrible time-sink when it comes to support and maintenance, not to mention the issues with ensuring accounts are disabled effectively when people leave the company.
Whether you go for a cloud-based authentication engine or simply put together an internal AD/LDAP-based system, you really need to move from a vast number of disparate authentication databases to one (or, at least, as few as humanly possible).
5. Virtualize your servers and storage
Running a single operating system on a physical server is incredibly last year, and is a very uneconomic way of utilising the power of the server unless you absolutely need a socking big single-purpose box (a vast multiprocessor calculation engine, for example, or a whopping database server). Likewise, virtualized storage: by using SAN-based storage (which is dead easy to implement using iSCSI on 10Gbit/s Ethernet) you get the advantages of de-duplication with no real performance hit.
If your server kit is powerful and reasonably new you can even consider repurposing it as a virtualized setup. Start by picking one of the lesser-used boxes, shifting its workload to another machine, and installing a virtualized setup on it; then do the same with the remainder, gradually migrating the physical devices onto the growing virtual environment.
6. Consolidate to fewer suppliers
The days of application-specific providers are pretty much over. Fifteen years ago you could justify working with several dozen providers, particularly if you had reasonably esoteric software and hardware requirements; today the average organisation can work quite happily with two or three partners, as well as perhaps the odd one or two specialists if there's something that really only has one source.
That doesn't mean you have to consolidate the applications themselves, just the companies you partner with (for instance I know several database specialist vendors that are equally good at both Oracle and SQL Server, so why not adopt a good one to cover both and use each area of expertise more and less as the workload varies). I'm not proposing you put all your eggs in one basket, but a small set of suppliers equals reduced management overhead and economy of scale.
7. Don't be scared to push the boundaries
Matthew Pierce, Flickr
Finally, we've all heard horror stories about companies that have adopted “bleeding-edge” technology and have been bitten on the bum. But how often is that actually true? Some years ago I worked for an organisation that had two distinct halves: the “we must provide a stable service” half which insisted on working with established technology; and the “we want newer, faster NOW” half which pushed the boundaries.
In fact, the latter was more stable: they responded more quickly when a software patch came out; they were the only part of the organisation not to be clobbered by broadcast storms because they had a routed, segmented network; and they had high-speed WAN connectivity first by doing some innovative tunnelling instead of waiting for the rare-as-hen's-teeth “approved” router to arrive.
I'm not daft enough to use the Service Pack Zero version of any new Windows release, but you should not be afraid to look to the future and try something new.
What we now call “tomorrow” will soon be renamed “today”. ®