Training is dead. You're never going to get it again, so stop asking.
When I moved out of PC support more than 15 years ago, I was lucky enough to find an employer who was prepared to sponsor me through an engineer-level certification. This required six weeks of classroom training, lab work, extensive home study as well as on-the-job training.
Today, my formal training is nonexistent. My last so-called PowerPoint and binder course was vendor-mandated and took place two years ago. Don't misunderstand: My day job requires me to be authoritative about multiple technologies, operating systems and topologies. I have to know and understand things that go far beyond what's printed on my business card.
Don't wait around for systems training
And that's precisely the point: If you want to further your career, there is no point waiting around for someone to approve a fancy systems training course. In fact, in a post-Dilbert world, a training request is practically an admission of your uselessness. To stay relevant you have to shoulder the burden yourself: Be your own sponsor and create your own lab.
That's a concept that would have been impossible when I began my career. To purchase servers and peripheral systems would have set me back six months' salary. With virtualization and ever lower x86 prices, setting up a learning laboratory is an achievable endeavor.
Indeed, many major network vendors provide virtualized versions of their appliances free of charge. Typically, these products may not be as full-featured or they might even be time-bombed after a certain period. But at a minimum you'll get a feel of the command line, the setup process and how the major components work. Spending a fortune is no longer necessary.
Buying your own laboratory environment
VMware, just to list one major supplier, provides a variety of free and evaluation editions that will get you up and running, and there are plenty of other choices. Install the hypervisor on your mostly idle gaming PC or alternatively invest in a dedicated rig. I use an HP N40L, which cost me a few hundred dollars -- including a 16 GB RAM upgrade. It boots quickly from an old USB flash drive and runs about six virtual machines concurrently. This includes clients, servers, routers, firewalls, application delivery controllers and management appliances -- everything I'm likely to need. I have found RAM to be the crucial factor -- not central-processing unit power or disk I/O. Alternatively, eBay is stuffed full of previous-generation x86 servers that would be more than adequate. Another option is to stick VMware Server on your laptop. I've found the convenience factor trumped by the RAM and disk space overhead, but whatever works for you.
In these cases, the license limitations are not normally a concern as the goal is to learn, not handle production throughput. Treat a 15-day courtesy license as a challenge to build your lab before the software expires. I find I learn most effectively through repetition and experimentation. Consider keeping lab backups "cheating"; force yourself to recreate what you need when you want to test something. If you can't get hold of a package you want, it's time to tap your LinkedIn contacts or other colleagues. Someone you half-know is bound to be able to fix you up; just be prepared to return the favor and share your findings.
The opportunity to advance your skills is now in your hands. Try to recreate aspects of your own production environment (if you have one) and try to find ways to do things better, even if you know you'll never get budget for it in the real world. The goal is to learn for your benefit and obtain the skills you need to ensure your continued success.
About the author
Glen Kemp is an enterprise solutions architect for a U.K.-based managed services provider. He designs and deploys network and application security tools, including access control, remote access, firewalls and other "keep the bad guys out" technologies. He is an experienced professional services consultant; delivering elephants and not hunting unicorns. His blogs can be found at sslboy.net and and at the Packet Pushers Podcast. Follow him on Twitter @ssl_boy.