lukasz.bromirski.net

aviate, navigate, communicate

does SDN means end of the world for CCIE?

quite recently Piotr Jabłoński, one of the best architects and consultants in Polish Cisco Systems office presented session very similar to this post topic during our CCIE club meeting. independently, this topic is often brought back on CCIE.pl forum, and Mirek Burnejko asked for couple of comments with regards to growth of whitebox networking.

so… does rise of SDN really mean end of the world for CCIE?

yes and no.

let’s define first what’s SDN at all, because as you can imagine - there’s bunch of definitions. so, for the sake of the post, lets assume SDN is:

Software Defined Network - architectural framework separating control and forwarding plane, in addition to which, control plane may steer number of forwarding planes at the same time

of course it’s far from being excellent, but shows a general trend - while discussing SDN most of us assume automatically that programmability (and automation) is closely related to cooperation with applications (software) and network (in generic terms - both software and hardware). this means we’re able to steer network constructs using software using some abstract policies.

so, now my three points:

first of all, SDN is nothing new - it is an evolution. natural movement bringing closer software developers to network engineers. and while it’s often said that SDN is nothing new because ‘such solutions were already done in the past’, it’s not entirely true. control and data plane was separated in the past (like for example in ATM networks when Ipsilon demonstrated tag switching, or ATM with switched circuits concept or the modular routers and switches where control plane is steering the underlying device or network), but there was no easy way to actually integrate this using software layer by someone not expert in the specifics of this solution from software and hardware point of view. and even when you were an expert - most of the time there was no API.

created by Gartner in 1996 concept of Service Oriented Architecture talked sharing of features and applications above siloses - traditionally consisting of network, compute and storage. you can find echos of this concept in IBM professional services offering of that time, or Application Oriented Networking architecture by Cisco. they essentially meant to integrate those siloses, but the only thing they did was - build higher-layer reference architecture, as API was not present, and cooperation needed building platform specific interfaces. SDN nowadays creates this common denominator - APIs between network and applications.

so the nowelty, apart from just creating the APIs is the scale on which it is happening - a lot of different companies, groups and people have access to broad portfolio of hardware to experiment with. as a certified engineers and consultants, we can bring a lot of value because interface is one thing, but logic how to use the interface is another thing.

from this perspective, you can say SDN has three layers:

  • belonging to equipment vendors, having northbound interface, towards abstraction layer; from good old SNMP, to NETCONF (and Yang models), BGP LS, PCEP and some other
  • abstraction layer with API - like OnePK from Cisco
  • SDN controller layer - things like Cisco APIC, Junipers Contrail or open OpenDaylight.

so, does it take a CCIE to understand it? no, but it helps. does it mean that need to have CCIE available will stay at the current level? i’d risk to say that it will even grow in time, as the number of solutions built today is enormous, and only some of them will be commercial success. you need to however remember, that opening up APIs suddenly ‘flattened’ networking world - you don’t have to be wealthy company anymore to play with big networking setups. they can easily run on your laptop. learning is easier and cheaper, and programming - reachable to anyone.

secondly, evolution is natural. i currently hold two CCIEs and CCDE, but at the same time i’m not stopping here. i see a lot of my friends that after passing CCIE decided there’s nothing interesting left and they stopped learning. such people will loose practical knowledge within 2-3 years, and after 5-6 years don’t have any value on the market, even within their primary specialisation. often they choose to become managers as a way to progress their career (and i am a manager!). i don’t know Python fluently yet (but i’m learning!), but i know Perl, C++, shell scripting and understand that to discuss with people responsible for managing infrastructure (DevOps guys) i need to understand application world. so, while i understand how TCP/IP stack works, and know what’s PMTUD, i need to be able to understand what kind of network guarantees application requires (like voice) and if it’s not simply terribly written. i need to understand how mobile app will behave in comparision to desktop app, what’s heavy and light version of the same app - everything connected with architecting the solution vs configuring one device.

so, in other words, DevOps guys, that connect network and application worlds, will take a lot of work from both pure application and pure networking guys. CCIE working in DevOps role will have natural advantage over someone who’s simply CCIE, as he’s more experienced and sees world more broadly. this ‘simple’ CCIE will still have a lot of value if correctly tasked. would that mean CCIE will be married to software development? i wouldn’t say in 100% of the cases, but still - in most of the cases this will be simply required. so, knowing how LDP and BFD works and how to integrate this knowledge with application to guarantee proper software engineered paths may not be required, but positively impacting effectivness and quality of work. so, naturally - employers will start asking about it.

thirdly, SDN refreshed our view of networks. it brought whitebox networking, that cut off some of the income from traditional vendors and democratized access to hardware platforms. it brought open platforms to integrate applications and network. it didn’t turn everything upside down, but it moved us two steps ahead and one step backwards. some of the people involved in SDN networks will spent next couple of years reinventing the wheel in overlay networking (like VLANs, MPLS, TRILL/FabricPath and so on). some of them will gain financially by advising and consulting on the ‘moving to cloud’ business. and there’s already ‘SDN architect’ role, so you can spend next 10 years living off proper positioning at the start. so.. can you ignore it? no, because as I wrote above in point two - knowledge that you have and that you can gain developing yourself, in 3-4 years will be prerequisite to networking world. you can simulate big networks on your laptop now, then simulate different sets of requirements how the apps will react to changes. things reserved yesterday to big computing centers, are now happening literally on your PC. there are already people that did pass their CCIE using only virtualized equipment (like legendary dynamipsa) or some other virtualization platforms.

i’m optimist here. SDN is step ahead to shorten the feedback loop between developers, applications and network engineers. we’ll make a lot of mistakes on the way (just take a look at OpenFlow fiasco), but on the other side it’s already visible it was worth it. i’m doing my recertification :)


Share