Thursday, September 15, 2016

Redefining SDN


For quite some time I have been sort of irritated (for lack of better word) by hearing and discussing about buzz word in the market called SDN. Let's first review some of interesting facts:

- Some people seems to be afraid of loosing there jobs thinking they will be irrelevant in near future, well lots of posts are there on web where people are throwing opinions about whats the value of CCIE now and if CCIE is relevant any longer. (Mostly these are people claiming themselves as SDN/NFV experts or evangelist)


- SDN means - STILL DON'T KNOW

- SDN is the only thing that the next generation networks would be build around or run

- SDN & NFV are future of networking

- Protocols like Open Flow will take over the world soon and re-define the networking completely 


Now let's not try to define SDN here and keep it for next post since I would wan't to clarify on some of misconceptions.

So coming back to idea of there is fundamentally something new. Well it depends upon what's your personal take on SDN to begin with in terms of :

- What it is
- How it works
- What problems does it solve
- What are the new models, frameworks and protocols that works in the background (Check under the hood)




Now if you take a closer look, most of these products are good mix of:

- Overlay Networks (Host Based, Network Based or Hybrid - e.g.:  VxLAN etc.)

- Good Orchestrator that really works well for most part (Numerous failed  
   attempts by vendors in past) 

- Network virtualization techniques (e.g. VRFs,Virtual instances etc.)

- Some better protocols/techniques to support workload mobility (e.g. LISP etc)

- Fixes applied to some traditional techniques (e.g. Poor programmability  
   support with CLI in past or missing shell access etc.)

- Some old fundamentals re-discovered (Cap theorem , Game theory, Clos  
   Fabric, BGP Labelled Unicast etc.)

- Enhancements into existing protocols considering their proven history 
   and robustness ( BGP LS, BGP EVPN, Segment Routing etc.) to meet 
   new requirements in terms of scales and get rid of some old challenges

- Better API support

- Better abstraction 

Now to me these are old ideas which are wrapped in nice package (Remember RFC 1925 Rule 11) but certainly needed to meet business demands and scale in current scenario and near future depending upon what all business problems you are trying to solve with technology.

On the other hand important question is " Should I be afraid ? "

Well there are couple of moving pieces which you need to consider:

- Most traditional network certifications, classes & courses don't cover 
   these things which really makes the situation tough

- There are very limited books and texts around these topics and some are   
   even misleading

- Lack of new networking models to define and shape these protocols and 
   other stuff well and standardize them across vendors

- Most of companies in these segments present their products like real  
   game changers

- Are you really bad at adopting change


- Well in the end of the day it's all about money...isn't it ? :)

So while it's really good to have SDN tools around to solve different problems with technology and get rid of some challenges and limitations from past, we are still far from having T-800 from Judgement Day in real life :) (While another interesting question would be if we really want to go to that stage)

 

Further Readings:

https://learningnetwork.cisco.com/blogs/vip-perspectives/2014/02/05/sdn-fight-or-flight--the-syndrome-of-new-technology-and-the-impact-on-networking-careers 

http://packetpushers.net/say-sdn/

HTH...
Deepak Arora
Evil CCIE


4 comments:

Unknown said...

Good one Deepak, keep posting frequently...

Unknown said...

Good one Deepak, keep posting frequently...

bavana princy said...

This blog explains the details about changing the ways of doing that business. That is understand well and doing some different process. Provides he best output of others. Thanks for this blog.
SEO Company in India

Nayan Joshi said...

Good one Deepak, thanks for sharing.