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 last generations of high-end servers are amazing: they can have terabyte (or more) of RAM, dozens of CPU cores, and four (or more) 10GE uplinks. It’s easy to pack 100+ well-behaved VMs on a single server, reducing the whole data center into a private cloud that fits into a single rack.

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.

A while ago I was listening to a CloudCast.net podcast describing Project Runway for geeks – the Virtual Design Master – and decided to do what I could to help them ;)

The second season is starting today – the list of participants is already online (and you might watch the videos of the first season while waiting for the first challenge).

If you’re an avid Kindle user, you can buy the Data Center Design Case Studies book on Amazon. Here’s the Amazon.com link, search should find it on most other Amazon marketplaces.

However, if you can survive reading the PDF version, please buy it straight off my web site. Here’s why:

Expect a significantly reduced blogging frequency ;)

Occasionally I get a question about some totally impossible implementation detail (example: can we use OpenStack OVS plugin on VMware to avoid buying NSX?). These questions are often coming from people who painted themselves into a corner and are now desperately looking for MacGyver’s shoelaces to pull themselves out.

It’s easy to blame the engineer who tries to do the obviously impossible, but it’s often not his fault – these days a lot of technical people get pulled into the game of Build a Cloud in Three Easy Steps.

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

The Mice and Elephants is a traditional QoS fable – latency-sensitive real time traffic (or request-response protocol like HTTP) stuck in the same queue behind megabytes of file transfer (or backup or iSCSI) traffic.

The solution is also well known – color the elephants pink (aka DSCP marking) and sort them into a different queue – until the reality intervenes.

True old-timers might appreciate the analogies I got while writing the Network Infrastructure as Code article. Let’s start with “do you remember this thingy?”

Source: Wikipedia

If you recognized the state-of-the-art (in those days) box in the picture, you might be able to relate to this screenshot:

This is pretty close to some SDN architectures I was privileged to see in the last three years.

Source: strategic humor @ HBR

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.

When I heard people talking about “networking infrastructure as code” I dismissed that as yet another Software-Defined-Everything one-controller-to-rule-it-all hype. Boy was I wrong.

Last September I received a peculiar tweet from Luke Gorrie pointing me to a software switch pushing 200 Gbps through an Intel server literally hours after I’d watched the Deutsche Telekom Terastream presentation, so I mentioned Luke’s Snabb Switch as a potential performance solution in an email to Ian Farrer… and before Ian managed to reply, Luke was already working for Deutsche Telekom.