We need more software engineers in this space (and not just at the edge). The way some of these core networks are maintained just makes me shake my head. There are way too many manual processes and way too much push back whenever software is introduced to standardize configs.
That's an interesting point. What companies are in this space? VMWare recruiters mentioned (to me) a big SDN investment ~6ish years ago but I haven't heard much after that.
The company I work for is in the SDN space but specifically around large scale uncompressed (SMPTE 2110, 1.5Gbps per HD stream) video broadcast IP infrastructure rather than related to docker containerization.
We've been deploying larger and larger systems based around our hardware IP switch fabrics (EXE/IPX) and using our SDN controller (https://evertz.com/solutions/magnum) to manage network topology for systems over 150,000 multicast flows with television broadcast critical timing/latency on stream switching.
> with television broadcast critical timing/latency on stream switching.
mean? Is this minimising the time it takes for the channel to change once the person sitting at home has clicked the remote? Or is this for live broadcasters trying to mux multiple raw video streams into a single watchable stream? Or something else?
If the former, what's special about that case over some normal network box?
The type of system I was referring to is the core within the broadcast facility, rather than extending to the home viewers (which is a separate downstream distribution encoding/mux process). Timing is important for when you switch between different video feeds to avoid on-air impacts so all the signals have to be video frame-aligned basically. In an IP system PTP timing is used to lock all the devices since greater precision is needed than NTP can provide.
Low-latency is also important for when the SDN system initiates a route to switch since it generally needs to happen according to a tight broadcast playlist schedule and we found that with SDN (central controller telling all the switches what to do) rather than IGMP type system (multicast subscribe with switches doing a lot more work parsing packets) is the best approach to handling very large volumes of routes and having them take effect in a low-latency predictable way.
Thanks for clarifying, I think I get it. It almost sounds a bit analogous to an RTOS where you dictate your deadlines to ensure they are met rather than letting everything run wild and hope for the best.
I'm not actually aware of many... It's kinda a niche pain point. The only companies who really need innovation in this space are mid-lrg size companies who run or require good sized networks.
The process of manually maintaining the network is easy enough that most people just kinda shrug the cost off and ignore all the crap that accumulates in their configs over time.
The companies who can't shrug the cost off, or who actually consider security do automate their network (think ATT or Google). The thing is they aren't just gonna open source their core business. Plus, their network is special and their software wouldn't help anyone else out (i don't really buy this).
The other problem is that network apis aren't standardized at all. There are a few initiatives out there, but they're unlikely to catch on. Network vendors really only differentiate themselves through their network os, so any configuration software needs to take into account multiple config apis.
In general I agree but lately I've been wondering if software defined everything and easy universal reconfiguration actually brings lower reliability (and security?).
For instance software engineers and automated processes apparently brought down Google Cloud's SDN across several regions for several hours a few days ago. They may not have been able to do that if configuration updates were more manual.
The question is whether whatever benefit they gain from SDN worth the additional risk.
This comment really highlights why the term SDN is pointless and needs to die. You are talking about something completely unrelated to topic of the article.
13 comments
[ 2.6 ms ] story [ 68.3 ms ] threadKubernetes changes all that. Now I have an interest in SDN.
We've been deploying larger and larger systems based around our hardware IP switch fabrics (EXE/IPX) and using our SDN controller (https://evertz.com/solutions/magnum) to manage network topology for systems over 150,000 multicast flows with television broadcast critical timing/latency on stream switching.
We're hiring! https://evertz.com/about/careers/
> with television broadcast critical timing/latency on stream switching.
mean? Is this minimising the time it takes for the channel to change once the person sitting at home has clicked the remote? Or is this for live broadcasters trying to mux multiple raw video streams into a single watchable stream? Or something else?
If the former, what's special about that case over some normal network box?
Low-latency is also important for when the SDN system initiates a route to switch since it generally needs to happen according to a tight broadcast playlist schedule and we found that with SDN (central controller telling all the switches what to do) rather than IGMP type system (multicast subscribe with switches doing a lot more work parsing packets) is the best approach to handling very large volumes of routes and having them take effect in a low-latency predictable way.
The process of manually maintaining the network is easy enough that most people just kinda shrug the cost off and ignore all the crap that accumulates in their configs over time.
The companies who can't shrug the cost off, or who actually consider security do automate their network (think ATT or Google). The thing is they aren't just gonna open source their core business. Plus, their network is special and their software wouldn't help anyone else out (i don't really buy this).
The other problem is that network apis aren't standardized at all. There are a few initiatives out there, but they're unlikely to catch on. Network vendors really only differentiate themselves through their network os, so any configuration software needs to take into account multiple config apis.
So yeah... We need more engineers.
For instance software engineers and automated processes apparently brought down Google Cloud's SDN across several regions for several hours a few days ago. They may not have been able to do that if configuration updates were more manual.
The question is whether whatever benefit they gain from SDN worth the additional risk.
Set a goal, optionally explain the need for it, pick one technology from the list, and show how to achieve that goal.
Would be also good to show how is this different from traditional networking.