Re: questions asked during network engineer interview

[Mel Beckman <mel () beckman org>]

Mark,

But SDN is NOT just ""SDN = some kind of automation””. Its centralized management with good automation built-in. Good 
automation means automation that orchestrates cohesive, correct network changes — and can roll them back — not just 
scripts that can spew configs into individual devices. And you say SDN consists of "bits of code and ideas coming out 
of these operators” as if that’s a bad thing. That’s how all innovation happens in IT.

Today's SDN has delivered on orchestration and good automation.You only have to shop and compare, the products are 
there and very powerful.

But more germane to this discussion, I would expect any network engineer candidate to know all about SDN, know how 
various vendors implement it, and have experience using it.

You wouldn’t expect a bridge engineer to not be proficient in advanced computational modeling, would you? Or an 
electrical engineer to not understand field-programmable gate arrays? Or a chemical engineer ignorant of SCADA 
programmable logic controllers?

That’s the equivalent of an SDN-ignorant engineer in today’s market.

 -mel

On Jul 20, 2020, at 10:34 PM, Mark Tinka <mark.tinka () seacom com<mailto:mark.tinka () seacom com>> wrote:



On 21/Jul/20 07:12, Mel Beckman wrote:
Mark,

There are a slew of fine SDN products out there, from VMware NSX-T in big enterprise to Ubiquiti UniFiOS in SMBs, and 
lots of other products aimed at various market niches. What failed about the original SDN academic vision, more or 
less, was standardized, vendor-agnostic SDN based on protocols such as OpenFlow. Sure, a standardized platform would be 
nice, but you can’t blame vendors for wanting to differentiate their products to gain marketshare. OpenFlow never 
really delivered in a way that any vendors could build a competitive product around. HP tried, but, well, here we are.

The goal SDN was created for was centralized management with good automation built in. Nobody ever promised single-pane 
management of multiple vendors’ network elements. Nobody promised that because there is no way to make a living selling 
that.

And despite taking the long route to get to that conclusion, that is
essentially what we've had to learn the hard way.

If "SDN = some kind of automation", this isn't new. Operators abound
have been "automating" for years... decades, even. It's just that their
solutions have been internal, either entirely homegrown, or cobbled
together with hand-written + external vendor-provided systems. These
systems have grown and become significantly large to the extent that it
makes it difficult for these "established" operators to want to
participate in "standardizing" what they already have, or openly
contribute to a standardization process because, well, they don't really
have a problem to solve.

Moreover, a lot of the drive on these "SDN thingies" is bits of code and
ideas coming out of these operators (notably, the cloud bags [boys &
girls]), when they are feeling generous to share what they've been
working on with the community. Regardless of what they share, they are
probably 10 years ahead of what we get to see. How do you expect to
standardize a gap like that?

Ultimately, I don't think the industry will reasonably agree on
standardization of this process. 40 years of the Internet and you still
can't "buy" an NMS that "just works". That should tell you something :-).

We should be spending more time encouraging folk on how to simplify
repetitive tasks. The actual solutions they decide to implement to get
there should be left to them. I don't want to waste another decade on this.

Last week's Cloudflare incident should remind us how uncomplicated this
is. The problems we need to solve are as simple now as they were 25
years ago. So let's not complicate it anymore than we need to.

Mark.