Are we ready to let software run the data centre? Software defined networking (SDN) gets a mixed press. Proponents declare it has given them more flexibility than ever before and that the time from inception of an idea to system implementation is vastly reduced. When the opponents have their say, the story is that the way you make a network work properly is to have a network …
has millions of Admins who are probably nowhere near as talented as Mr Cartwright.
Some are just hardly worth the title of Admin but they may read this article and they try to implement the sorts of things hes describing.
What he makes seem easy is probably far from it.
IMHO, articles like this should come with BIG warnings. 'Do not try this on your live network'.
Buy hey, times are gonna get interesting with the potential for lots more critical systems and networks to go down when [redacted] try to implement SDN on their own networks.
Perhaps we'll get similar instances of the UK-ATC failure on a wider and more regular basis?
Who's got the popcorn in stock becuse it might get difficult to buy some if a few critical networks & systems go down.
The other thing that worries me and a few other IT Pro's (it was discussed in the pub on Friday night) is the potential damage that could be done by the black hats getting into the controllers of these SDN's and wreaking havoc. Imagine if this was done in a co-ordinated way, you could potentially cripple a whole nation. We are so heavily reliant upon computers that you have to ask yourself what would happen in you could'nt drive you car (traffic signals all showing red), Buy food (no orders placed), Cook that food(leccy & gas out due to computer failure) etc, etc, etc.
These whizzo things are all very well and good but... There has to be a downside to them.
This article starts out plain wrong and just gets worse. Just look at the mess that is OpenStack networking:
http://www.theregister.co.uk/2014/05/13/openstack_neutron_explainer/
Furthermore, just because a bunch of big names are involved in something, didn't mean it's currently a good idea. The market place is changing in this industry and no one wants to be left behind. So you find big names sticking their fingers in almost every 'open' pie for two reasons 1) to make themselves look like a collaborator so as not to scare off any potential customers and 2) to try and influence the technology to more closely align with their own strategies. You just have to look at Cisco's efforts to get OpFlex adopted by OpenDaylight project as an example of this. It's also worth noting that most vendors are also developing at least partially proprietary SDN solutions alongside their work in these 'open' projects. Does SDN really look mature when you see the industry hedging its bets on multiple strategies?
Biggest concern (was going to say problem, but that's unfair) I have with SDN and a lot of the areas in the article is that having worked in a variety of organisations over the years, at least a third of senior managers I've worked for will, if they read this, take the bits they can understand and think "Great! My current server team can now do my networking - a whole load of costs can be cut, I pay the server guys already so this is just another thing for them to do as part of their job - it's only configuring software anyway, so it won't take them any time really - and I can cut out the network guys and stop buying those expensive boxes!"
Great news for people who punt emergency response / "Get it working right now!" services I suppose?
Guys,
This is happening now, finance first and now retail market.
The early adopters are doing it and its working but not with any of the companies mentioned in this article. You guys come across as Turkeys not wishing to vote for Christmas.
Look at SDN central , look, learn and get on board.
The world is changing, the move to s/w and commoditisation of the h/w it's inevitable .
One example from a new customer and user of SDN. You can only do cloud with SDN !!
I really hadn't heard any clear definitions (before) of what SDN was exactly, it sounded like a lot of unfinished software + hype. But it doesn't sound to bad to me from this description. To me, it sounds like the combination of (in summary):
1) The existing mechanisms various virtual machine environments have to allow these virtual machines to have their own MAC addresses and (if you want) VLAN tags.
2) "Q-in-Q" allowing a second layer of VLAN tags (802.11q) within a VLAN tag. So, "development" and "production" for example could each be on it's own VLAN. But "development" could then define their own VLANs within this VLAN, if (for example) you wanted to test something (with either physical or virtual hardware) that really should be on it's own LAN, without risk of it accidentally setting the "wrong" VLAN ID and stepping on production's toes.
3) Some kind of standardization in terms of how to deal with setting up and removing VLANs and "sub-VLANs" on the switches.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
