As networking engineers, we're dealing with a monster of our own creation. We built our networks as glimmering conduits of unbiased transport, quickly and flexibly adapting to any traffic or business need. We welded together smooth tubes over which any packet could travel, virtually daring the business to try to break them. And we're comfortable knowing that as long as our network monitoring solutions generate capacity planning reports, we'll get even bigger and better toys to play with.
As such, it's almost inconceivable to us that it's not our ordered universe of responsiveness that drives our engineering. Instead, it's boxes of snake-like applications. The hard-to-swallow truth is that applications have always run the show when it comes to networks. This reality can be extra difficult to accept in organizations where the systems team is fronted by a less senior and often frazzled sys admin who -- if not wearing a red fire helmet and rubber boots -- at least always carries the faint scent of smoke and ash. Nonetheless, it is a truth we must come to terms with.
The 'no subnetters' allowed club
Yet it also doesn't help that some systems teams only engage net admins as needed and don't always ask us to join their lunch crew. They don't resent us per se, but they're aware of the higher compensation, task independence, higher job satisfaction and increased responsibility and authority of many networking engineers. Let's instead just say that many are on a senior administrator career path, often in networking, but they're not yet there and this can create frustration that sometimes manifests itself in unfortunate ways.
You'll have the opportunity to do your engineering the right way the first time, rather than becoming stuck with expedient, shortcoming-filled, reactionary implementations.
Common symptoms include application-related change tickets that have a habit of blazing across the network desk, but get stuck with the systems team -- usually tangled in prioritization and task switching overhead. This isn't only about how systems teams feel about network administrators, though. The reality is systems administrators are often overloaded with dozens of competing and unique tasks that can be difficult to prioritize efficiently. This actually presents a great opportunity for network administrators.
Lead guru, lead
Forget the bees buzzing around inside applications and focus instead on their interfaces. In doing so, you'll quickly realize your network engineering skills can grease skids and ensure the effective delivery of applications and services in a way both users and their business owners will love.
Applications are nothing without networks. They use interfaces to connect clients, need low-latency storage to work efficiently, send vMotion images around control networks and hammer wide area networks with disaster recovery backups. It's usually left up to the systems team to sort out these issues and then open network tickets for each interface element.
Rather than sitting idly by waiting for this happen, consider proactively developing change templates for the most common application types and making these part of your network workflow. Then go ahead and let your sys admins worry about the gorpy tasks like installing certificates, fiddling with configuration files and applying patches while you quickly optimize quality of service, configure monitoring, ensure access security and dispatch connectivity and routing issues.
This will do a couple of things for you. First, it's good karma; the systems team will appreciate it. Second, and more important, it will demonstrate leadership and stewardship to a highly influential group: the application business owners.
But wait, there's more, and you won't have to wake up early
Virtualization increasingly makes important parts of the data center network opaque to traditional management techniques, and we need the application team's assistance to reach past it. There was a time when individual hypervisors were the black boxes, but at least they had four network interface cards to monitor. Now, however, whole racks are being connected with virtual backplanes, blurring the lines between network, storage and compute. None of the problems have disappeared; in fact, on the contrary, as complexity has increased so has the challenge. And while consoles fix the easy issues, system administrators need networking engineers more than ever to debug the really tricky issues. Eagerness to assist these efforts can go a long way to increase your visibility on the team.
As a bonus you'll become valued counsel for the larger infrastructure engineering team. And now that you are armed with strategic plans well in advance, your portion of the ensuing change tickets will always be completed first, as if by magic. Best of all, you won't be playing catch-up. You'll have the opportunity to do your engineering the right way the first time, rather than becoming stuck with expedient, shortcoming-filled, reactionary implementations. And how often must those shortcomings be remedied post-production? Remediation never happens during business hours -- it's only during planned outages at two o'clock on Sunday mornings.
This was first published in February 2014