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
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.