Scaling out Horizontally, Not Just Vertically.
Here we are in an age of automation, consolidation, virtualization, optimization and the proliferation of a dozen other terms and technologies that are enabling IT organizations and users to do more with less and from just about any location. We’re building clouds and service catalogs, virtual desktops and creating IT service providers. The skills required by IT organizations continue to grow in leaps and bounds. No more can you just be “the router engineer” or “the backup engineer”, you’re faced with learning other technologies. Not so much learning, but cross training. How can you design any IT system without knowing how other parts work? The inter-dependencies are deep, and are only getting deeper. There was a day when you had discrete systems. A server, with a NIC and a SCSI adapter connected to a LAN and a disk array. The server was managed by the server team, the LAN by the network team and the array by the storage team. The line of demarcation was the cabling or the NIC/SCSI adapter. There wasn’t much need for the LAN team to work on the server or the server admin to work on the array. Some might say, “Times were simpler back then.” Maybe, but the silos were taller and their walls thicker.
That was then, this is now. There are switches that run on the server like the Nexus 1000v. There was a time when “internal storage’ meant a server with 20 internal drive bays. Now storage companies are demoing running VMs inside their arrays. In BigData environments, we move the data closer to the compute, maybe it’s time to move the compute closer to the data? Is specialization of skills fading and generalization emerging?
So now we’ve got server folks learning LAN, LAN folks learning SAN (see: FCoE) and everyone learning server virtualization.
Are we missing anything?
I don’t mean vi or emacs. I mean being able to intelligently and accurately convey your thoughts and ideas to others over both written and oral mediums. If you can’t write it, people can’t read it. If you can’t explain it, they can’t understand it. Why do babies cry when they don’t get their way? They’re frustrated in part because they don’t have the ability to tell you something. The same holds true in IT. I used to laugh back in college, about why would I ever need to be able to write a technical document? Guess I was wrong.
It’s one thing to have the knowledge of how to do something, it’s another problem entirely on how to get it onto paper, Powerpoint or .pdf so that others can understand what you’re trying to say. I’ve met the brightest of engineers that can understand the most complex of topics, create and deploy optimal infrastructures and will probably have no problems taking this doozy of a CCIE exam. Btw, I believe this exam covers everything in the datacenter with the exception of deploying an FM-200 fire suppression system. However, these same engineers will take dozens of classes to further hone their skills, go to industry conferences and spend days in the lab. Driving their technical knowledge to a razor’s edge. The struggle they often find is often because they haven’t taken a course or had any additional instruction in how to convey their brilliance.
They may understand their own style or methodology, but for the org to succeed others must understand it as well. It’s not just the written word, but the spoken one as well. We use powerpoint to create “6 bullets, next slide; 6 bullets, next slide” torture sessions and wonder why the rest of our team dreads when we fire up the projector.
Maybe it’s time we engineers scaled out horizontally, not in the direction of adjacent or complimentary technologies, but for those soft skills that will help us communicate better with our fellow admins, DBAs and sysops.
Who knows, maybe they’ll stay awake next time.
RTFM that you wrote.