If you are a “pure” network engineer and still have a mortgage to pay, this post is probably for you!. Those who are preparing for CCIE voice or application firewall or F5 load balancer are on the right track.
In short, SDN (Software defined network, aka SDN cat) products are already out of the bag now. SDN will require no more so called CLI monkey (The Network Engineer) to configure and monitor the traditional switches/routers. SDN products are coming soon in your local cinema. Here is a typical example of upcoming SDN:
Dynamic changing nature of an IT industry, keeps all of us (in IT) awake till 2am in the morning – this sounds about true! I remember way back in 2010 when I was studying for CCIE Security, I bought an IPS appliance of the eBay and as soon as it arrived on Tuesday afternoon, I was on it until 3AM in the morning. I remember that day it was 2:30 AM in the morning, my neighbor “Mrs Kathy” knocked on my door and asked why I have been vacuuming my flat for the last 3 hours, she couldn’t sleep because of the noise. I said, no I am not vacuuming my carpet at all, in fact, I don’t even have a carpet to start with! She grumbled and said to me, she can still hear a “strange” noise coming out of your flat. I said, oh.. I bought this small machine that might have some strange noise coming out of it. She looked at me and said politely ‘go to bed and have some life”. You know now it is true, we’ve to wake up or study during the weekend to keep up with the never changing world of the IT. This is fun or fuss! It’s your call to get along with it or select another career that is not so dynamic. That is my little real story. Let’s come to the point now!
In this post, I will try to keep everything much simpler than they are hovering over onto us. I think this is about the time to make a decision whether to stay in a pure so called ‘network engineering’ role or move into application, system and virtualization (Cloud is the right buzz word) space.
All Network Engineers should diversify their skill set, those days are not long ahead from now when Employer will stop advertising network engineer’s role. Nobody needs old pascal or clipper programmer anymore these days, do they?
I put that intentionally in “BIG” quotes, there is a reason for that. If you look any role that google or other big web3 company are advertising for network engineer, they are asking for ‘Perl/python’ scripting. Why is that? Now you probably think, it is a network engineer role, but they are asking for scripting knowledge. This doesn’t sound right. Since when a Cisco or Juniper router need to be scripted. Those who are preparing for CCIE Routing and Switching lab exam would probably have used a skirt of TCL based script to check ping connectivity across the topology in the lab exam, but most network engineers (especially those coming from the small shop) won’t have a clue about using script on a router.
But wait .….. there is a catch why google/amazon need a perl/python junkie for a networking role. Well, simply because the power of Open Source philosophy.
Google and Amazon are the biggest consumer of networking equipment on this planet that vendors like Cisco/Juniper build for them as well as for other companies. Most cash flow comes off these big companies because they buy switches from these companies – simple. Now, what happens if these big consumers (google/amazon) decide and start building their own switches? You must be thinking what I am talking about. Why would anyone build switches if there are off the shelf switches that they can buy.
The fact is, these vendors have had so good for such a long time. Have had enough milking out of writing software codes. A 48 port switch from Cisco or from Juniper will have approximately the same amount of chips/silicons so the original (OEM) hardware costs almost the same. The silicon chip cost the same no matter which vendor is using it. The switch price is decided by the cost of the software and feature set. Sounds familiar now with the Cisco IOS and feature sets (voice, security, advance enterprise et. al)?
Talking about these top companies/consumer (google/amazon), the cost is not probably issued with them. They’ve got the money and they can buy any vendor switches. The issue comes with when they want something to do with the switch but they can’t do. This is because of switch vendor do not release source code with the switch. As we all know, google recruits best of the best mind and have an in-house programming team, so called ‘python/Perl’ programmer.
Cisco never has a merchant switch in their portfolio until the Nexus family of product release late last year. So much customer base (banking/share market/financial institutions) and no merchant switch? You see someone else started building merchant switches and ate up the market share. Time is the money! Google philosophy works in the same way, they want the feature set with a switch and they want it now. Most vendors won’t even look into introducing new features, the reason being their team is so busy in fixing the bug from previous release, have no resources to work on a new feature. Well, the close source world works like this way and it has been since I have been working in IT. It is as it is and as its name implies (close source, black magic).
In this modern day and age, thanks god, things has started changing. Take a step back, had Cisco/Juniper made their networking equipment codes available through GPL license, it would have been easier for anyone to add and remove features that they wanted on the fly. It would have been just like any other open source project that we see on SourceForge.net. Now the game of depending on the vendor to get a feature set is changing rapidly. Genius brain child at google/amazon have finally decided not to depend on these vendors anymore to get a new feature that they want today and now. This is fair enough and fair game, just like a kid want to play with a toy today when he’s a kid and need a toy when he’s a kid. It would be meaningless having a bunch of toys stacked in the backyard when you’re 50! Is it? Anyway… The matter of the fact is, google’s traffic is so huge none of the vendor on this planet were able to provide them the right equipment to handle their massive data the way they wanted. This is the only option for them.
As we all know, Google already has a team of engineers working on building their own network switches. They order cheap silicon (from Taiwan) and build their own switches. Are these switches running Chrome OS or Android and what about IOS Feature set? The IOS for these no-name brand switches are based on the standard Linux kernel (version 2.6 oh yeah) and an open stack software protocol that comes in a tar file OpenFLOW. The answer is no, they run the standard Linux kernel and *nix variant. The engineer can get root shell access and write their own codes to develop the switch feature set that they wanted today. Is this new, probably, know, this is what open source is all about. The magic stick is called “openflow” that is running wild in the open source community to power these no-name brand switches. Now you’d be thinking that if these big giants have started building their switches what the heck another vendor are going to do with their products. Well, believe it or not vendor had already started the race with Google and other web giants. Cisco, Juniper, IBM, HP all has started introducing OpenFLOW feature in their switches:
Cisco openflow – http://blogs.cisco.com/tag/openflow/
Google’s secret 10 GIG switch: http://www.nyquistcapital.com/2007/11/16/googles-secret-10gbe-switch/
IBM has already released openFLOW based switches – IBM OpenFLOW switches
There are so many advantages of openstack codes running on Taiwanese silicon switches. The main advantages are:
1. Develop your own feature that you want “TODAY” (don’t wait for years for a small feature set)
2. Software based controlled – NO CLI or expensive engineer required to configure a switch.
3. Easy to take switching codes to the next label – End of the vendor war
BTW, if you already not aware of, google G-Scale production network was already on their own homegrown OpenFLOW based switching platform. They’ve figured out how to hook slow (their internal) on openFlow. Full SDN are based on sFLOW and runs on top of OpenFlow. There are only 2 vendors at the moment who have solved this L2 and L3 issue with sFLOW and OpenFlow. Nircia is the one that comes in my mind who have the full SDN product. Well, they’ve solved the issue at the right time. Cisco and other vendor are still figuring it out. See on the above Cisco link – Cisco has a dedicated coding team to develop openFlow in their switches.
You now have an idea what I am whining about in this post. Back to our original topic- why next generation’s network engineer should have coding skills and why google and other vendor want a network engineer equipped with the Perl/python toolsets. Now, this obviously makes sense that it’s a fair drinking for Google /Amazon to ask a network engineer “hey do you know Perl/Python”. These web giants just do not want a network engineer with “show IP route” or “IP route” type Network Engineers (oh the CLI monkey). They need more bang for their bucks. The above #1 and #2 are the reason why a traditional network engineer will no more be in demand in coming years. The fact is that the Openflow and sFLOW based network hardware are going to be software GUI provisioned. There will be no vendor limitation. You can have Cisco, Juniper, raw no-name brand switches , all managed and provisioned by a single GUI (the sFlow controller). Since it’s software driven and everyone knows how to click and who clicks knows how to read work instructions too. If everything is gonna be software driven, with a few mouse clicks now an HR lady could easily provide SDN powered switches/routers. SDN powered switches/routers can be shipped on site with no configuration. A sparkee plugs it in at the site when he goes to do the cabling and SDN powered (sFLOW) controller finds and automatically pushes pre-template configuration. These templates are created by the Perl/python type network engineers. The HR lady now can easily select a template and push the configuration with a few mouse clicks to the newly plugged in switch. Sometime she might get too busy and can easily schedule provisioning task for midnight. During the day she could focus on her regular HR tasks.
And what about those template nerds? Once these templates are created, slow/OpenFlow powered switches start configuring themselves within the SDN frame work. What would these nerds (Perl/python type network engineers) do after they have created the required template? Who is going to monitor and troubleshoot those newly shipped switches? The well HR lady can’t do that, she only checks and does according to the GUI work instructions (WI)? The answer is SDN taken care of all these tasks. There is no room for mistake because all kinks are already tested and taken care well in advance by Perl/python powered network Engineer. When HR lady and the nerd wake up and get to the work the next morning, they saw already 90% traffic load creeping on these switches in their production network.
Is it just the fantasy or I have lost my mind now thinking about such a crazy thing? What would this type of network engineer will do all day long at google office if everything is gone templates and automatic. HR lady is doing provision work and she can easily cron/schedule it for the night time. Well, the answer is these nerd in google office you’ll see doing the other innovative work rather than supporting customer (as a traditional network engineer does) for simple things like switch port is not configured, oh port suppose to be a trunk, config errors. Now you’d probably think that I might have been on high when I wrote this posting, pun indeed. Some of you might have got an idea and may be thinking like – well, I am a network engineer switching part is eaten by the openFLOW revolution, but I will still be able to get a job on Routers. Someone needs routing to do if not switching. Well, don’t kid yourself here mate, open vSwitch/sFLOW powered SDN products are already on the horizon. These new technologies are baking at a very fast rate – probably on 300 degree Celsius in a microwave oven. They (the stable SDN) will be out in the wild before we could even think. As usual, you probably noticed, early production of mangos do not taste as good as the later or natural version. The same concept applies here, the current version of sFLOW based SDN products are quite buggy. The open vSwitch is a combination of NetFlow, sFlow, SPAN, RSPAN, CLI, LACP, 802.1ag.
Nicira already have vSwitch product out and available today. The software controlled switches (SCN) are the current market trend. SDN will be the next generation network for bigger enterprise. We’re very close to experiencing SDN in real life. (update April 2013, btw, VMware bought this company and added to their portfolio)
I remember, 5 years ago when VMware started doing virtualization, nobody will put their SQL or Exchange server on VM. DB/APP guys will go ballistic if you even whisper SQL VM to IT manager. Hasn’t that changed now? Oh yeah!, the matter of the fact is these days you have no choice but virtualization. This is exactly what we would see – Software powered network, the SDN in action, taking networking world to the next level. No offense here, but this is one of the reasons network engineers should multi-skill themselves!. You could argue anything for political shake, but you can’t argue against what is going to be the future trend and you’ll feel and experience these new and upcoming SDn stuffs. They’re going to hit everyone, so did the cloud and dotcom bubble in the past, nothing new here.
In next, blog entry I will cover up OpenFLOW architect and some scripting features.
Update 17 April 2014 – VMWare in 2013 bought Nircia and SDN has started kicking in!