Category: SDN

What can you do if you have a small team of networking engineers responsible for four ever-growing data centers (with several hundred network devices in each of them)? There’s only one answer: you try to survive by automating as much as you can.

In the fourth episode of Software Gone Wild podcast David Barosso from Spotify explains how they use network automation to cope with the ever-growing installed base without increasing the size of the networking team.

Someone left the following comment on one of my blog posts:

There is a paradigm shift that I don’t think most application developers understand. In a traditional enterprise model, the network is built around the application requirements, now we are saying the application has to build around the network.

I would say there’s no paradigm shift – developers of well-performing applications were always aware of laws of physics.

The use of tools has accelerated human evolution and made us what we are today. Networking is no different, and yet there aren’t that many tool builders among the networking engineers… or maybe all you need is a nudge and some hints on how to get started.

For the second episode of Software Gone Wild I got a truly interesting guest: David Gee, a network engineer already working on numerous network programmability and orchestration deployment.

During our half-hour chat we couldn’t avoid the question of whether every networking engineer will become a programmer and David provided an interesting answer: you don’t have to program, but you’ll definitely have to start thinking more like a good programmer.

A reader sent me this question:

I am hearing a lot about API in reference to SDN. I do not have any software or programming background but would like to understand this API in practical way. Could you help me?

TL&DR: API is CLI for program-to-program communication

I was asked to do a presentation at the recent Slovenian NOG (SINOG) meeting. I did an SDN one at the previous meeting, making NFV the next obvious choice… but I decided to put an interesting spin on it and focused on virtual routers.

I know numerous engineers who decided to pursue a career in networking because they didn’t want to deep-dive into programming. Will that change when the Software Defined Everything takes over the world?

TL&DR summary: Of course not.

A while ago Paul Stewart wrote a fantastic blog post listing the potential business benefits of SDN (as promoted by SDN evangelists and SDN-washing vendors).

Here’s his list:

A friend of mine sent me a challenging question:

You've stated a couple of times that you don't favor the OpenFlow version of SDN due to a variety of problems like scaling and latency. What model/mechanism do you like? Hybrid? Something else?

Before answering the question, let’s step back and ask another one: “Does centralized control plane, as evangelized by ONF, make sense?”

There are tons of SDN workshops, academies, and webinars out there, many of them praising the almost-magic properties of the new technologies, or the shininess of vendors’ new gadgets and strategic alliances. Not surprisingly, the dirty details of real-life deployments aren’t their main focus.

As you might expect, my 2-day workshop isn’t one of them.