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 ๐
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.
I think your definition of SDN might be a bit too focused on the management. Sure, an important part of SDN is the fact that everything can be centrally managed (it being software). Another equally important aspect is that with SDN the Control Layer is separated from the physical layer. In Non-SDN environments these two are overlapping: VLANS(Control) are defined on the switches(Physical) for instance. Using SDN these layers are separated (using technologies such as NV-GRE for instance), so that the physical layer’s only job is to move bits thru the right cable(to put it simply). This enables building of sophisticated networks using very simple physical layouts, which provides a tremendous amount of value in cloud and multi-tenant solutions, but could also be very interesting to mid- to large enterprises as a way of reducing technical dept and enable (more) rapid change.
We are totally synced about what SDN is.
The hardware layer is the key to have a good SDN solution, and sadly Cisco, Fortinet and co who at first said an unique protocol would be the key in the futur have started their own SDN solutions and eveyrone of them are not open sourced.