SmartClient Ajax RIA system

Isomorphic Journal

Subscribe to Isomorphic Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Isomorphic Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Isomorphic Authors: Hurricane Labs, Michael Bushong

Related Topics: Isomorphic Journal

Blog Feed Post

Certified Application to Network Isomorphism Engineer, anyone?

There has been a recurrent debate over the last few years on the future of CCIEs, or more broadly network engineers as we know (and love) them today. While certainly calls for the “death of the CCIE” are certain to grab eyeballs, as always the more probably truth is more nuanced and tricky to predict. Certainly change is coming, but it is important to understand the true value of the present network engineer and how that maps into the future we expect.

Why would network engineers die?

Apart from a deadly virus outbreak transmitted by TCPDump, or for the true preppers out there – the distant alien race whose network engineers have all died out and who are coming to claim ours – the vast disappearance of all network engineers is most likely hyperbole. Yet it is probably fair to say that specific skills that network engineers have long used to compare or present their own value, attributes like the CCIE certification, are diminishing in the value they present to the market. The reason is pretty simple – while a CCIE (or JNCIE, etc) certification implies a thorough knowledge of overall network engineering theories and concepts and a detailed understanding of protocols, what is usually being valued is how that knowledge applies to the practical application of running a specific type of networking gear. That is, the CCIE measures the skill of the practitioner relative to a set of configuration and operational tasks that are required to run a given vendor’s  gear. Certainly this skill set is generally transferable (with a given learning curve) across multiple vendors, mostly because at a gross level, most networking gear operates the same, with some differences in nomenclature or certainly some nuances in operational behavior that have to be re-learned.
But in reality, what the network engineer provides for an organization is far far greater than her ability to operate a router or a switch or a large routed/switched network. A valuable network engineer is highly skilled at translating the “what” needs of business people – sometimes translated to more concrete application or service requirements – into the “how” speak of networking. This is a skill in isomorphism – i.e. mapping a set of information from one context to another context in a way that preserves the form or shape of that information. This is a truly invaluable skill for any enterprise as the form and shape of business-centric or even application-centric requirements will always be different from the form and shape of data transiting wires as packets and photons. And while many network engineers today represent that value in a CCIE badge number, it should not be mistaken how valuable this inherent isomorphism skill really is.

But what about SDN and Application-centric Networking?

In the classical (architectural) definition of SDN (one which I personally hate!) – which is the “separation of data and control plane” it is hard to see how this would in any way diminish the role of even the most bits-and-bytes CCIE holder. Programming a control plane, whether its done with configurational hints, cues, and workarounds via CLIs and scripts is not actually that much different than explicitly telling the control plane what to do with formal flow rules. In fact, its better thought of as a subset of, or an additional tool in the toolkit for, the traditional network engineering skill set. Certainly there is some evolution required in terms of programming skill set, but that is hardly a paleolithic meteor in the making.
There are more (with fully acknowledged bias, what I would consider ‘advanced’) views of SDN whereby the network attempts to provide a more direct set of tools to map the application context to the network context via a set of abstractions and data models that help bridge that divide. The most evident examples of this are Cisco’s ACI (leveraging the Group-based Endpoint data model and abstractions) and Plexxi’s own Affinity model. The logical conclusion of many is that once a controller can understand the data model of the application world – it can configure and operate the network itself without the network engineer providing that isomorphic translation skills. Right?


And here is where nuance kills a good headline. The truth is that if these types of network approaches take hold – it certainly does change the role of a network engineer. But it doesn’t change the inherent value that hides behind the CCIE badge. While the configurational knob twiddling and in-depth knowledge of specific vendors various eccentricities may be hidden by a good controller, taking a specific set of inputs and outputs (business requirements) and a more detailed set of application constructs and effectively mapping them to a data model that fuels the network requires that skill – that ‘business quotient’ – that truly defines a good network engineer. And while some network engineers may continue to value themselves as highly skilled practitioner of vendor gear, the more intuitive have already begun transforming their internal and external view of their value to more explicitly describe how they put applications in motion versus how much they know about vendor xyz. That is, the future network engineer will be highly skilled at forming a given network’s data model in a way that matches their specific business’s security, operational, and performance needs and ensuring the output is what is expected. So who wants to be CANIE #1 ?


[Today's Fun Fact: The first food eaten in space by a U.S. astronaut was applesauce. And 50 years later John Glenn face palmed when he realized 'awesomesauce' could have been all his.]

The post Certified Application to Network Isomorphism Engineer, anyone? appeared first on Plexxi.

Read the original blog entry...

More Stories By Michael Bushong

The best marketing efforts leverage deep technology understanding with a highly-approachable means of communicating. Plexxi's Vice President of Marketing Michael Bushong has acquired these skills having spent 12 years at Juniper Networks where he led product management, product strategy and product marketing organizations for Juniper's flagship operating system, Junos. Michael spent the last several years at Juniper leading their SDN efforts across both service provider and enterprise markets. Prior to Juniper, Michael spent time at database supplier Sybase, and ASIC design tool companies Synopsis and Magma Design Automation. Michael's undergraduate work at the University of California Berkeley in advanced fluid mechanics and heat transfer lend new meaning to the marketing phrase "This isn't rocket science."