Software Defined Network: The last key to a full DevOps world ?

 

Following a talk of my brilliant colleague Sylvain Rรฉverault about SDN in an intern SII event, i decided to go deeper in the SDN world and apply it to PowerShell ๐Ÿ™‚

But before talking about PowerShell controllinig a Openflow controller, let’s get an eye on what is Software Defined Network!

I think the 3 words are talking by themselves. Software Defined Network, is a solution to avoid you to have to go behind your switches and plug serially in order to configure them. It’s a way to configure all your network hardware (routing, filtering, isolating, etc..)

How it works ?

Until few times, each vendor has their own solutions to manage their equipements (In fact, they still have) but now, they are other solutions to manage them. Thanks to the Openflow protocol you’ll be able to manage Openflow validated hardware using multiple stuff !

Consider your infrastructure composed by 3 layers:

  • Application Layer. This layer is composed by multiples applications able to contact your SDN controller
  • The Control layer is your SDN controller(s) that you can use in a cluster if needed.
  • The Infrastructure Layer, yours network devices piloted by the SDN controller

 

Here is a little schema, that’ll explain better for your eyes ๐Ÿ™‚

SDN Global

If you heard about SouthBound interface this is the name given to the interface between controller and devices. The Northbound interface is the one between applications and controllers.

Why is it awesome ?

Today, you need to have different Network devices vendor, in order to guarantee the security of your infrastructure. But, it occurs a real problem, you need to have as many administration consoles as they are vendor (and sometimes maybe more) and when you have adopted a devops method of work, you’re still sucked in the procedures of the network administrators who don’t have enough time for all your company’s projects !

This is the solution, now you’ll have Devs, Ops & Sec in your workflow, all of them working peacefully, drinking beers instead of doing manual stuff, etc… life would be much so better for everyone on earth ๐Ÿ˜€

Ok nice, but where is the trick ?

Indeed, there are problems, vendors, beside the fact that they have created the OpenFlow protocol, are still keeping their business in their hand. We talk about much more money that we’ll ever have in our hands here.

If you decide to go to the SDN side, which is great, you’ll may have to reconside your network device vendor, to choose one who’ll think about you instead them. You can give a try to the facebook Open switch for example.

What next ?

I’ve started to work on a module based on OpenDaylight REST API, it’ll take time as this is so much awesome the number of actions you can have on your network hardware. Once this module will be done, of course i’ll try to bring Desired State Configuration resources ๐Ÿ™‚

If you are willing to join this project feel free to contact me on Twitter, Facebook or here, i’ll give you access to the private github repo and the actual infrastructure running on Azure.