Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

9 module online course

Start now!
back to overview

Why Is Network Automation such a Hot Topic?

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

One of my readers asked a very valid question when reading the Why Is Network Automation So Hard blog post:

Why was network automation 'invented' now? I have been working in the system development engineering for 13+ years and we have always used automation because we wanted to save time & effort for repeatable tasks.

He’s absolutely right. We had fully-automated ISP service in early 1990’s, and numerous service providers used network automation for decades.

As always (as Russ White would say) it comes down to whether you run your network because it’s bringing you money – in which case you might do whatever it takes to make it bring in more money – or because you have to – in which case you’ll cut the costs as much as possible. That explains why most enterprises never considered automation. Service providers should have fared better, but many of them evolved from traditional voice operators running static services that barely needed automating.

There were further challenges explained in more details in Network Automation 101 webinar and in introductory part of the Network Automation workshop and online course:

  • Networks became mission-critical, and the management didn’t trust us to get automation right;
  • We built unique snowflakes that were impossible to automate without heavy customization;
  • Core network devices have humongous blast radius;
  • We lacked programming skills, proper software development processes and procedures, and affordable test environment;
  • Finally, it was hard to work with network device CLI (more about that at some later time).

What has changed in the last few years?

  • The SDN brouhaha forced vendors to give an appearance of becoming “software defined”, so most of them came up with something resembling a REST API (there were notable exceptions like Junos that had a good API from day one).
  • Engineers who figured out that SDN means Still Does Nothing started thinking about network automation as SDN Lite thingy that could actually make their lives better;
  • A lot of us started evangelizing the need for automation, which might have shifted the mindset a bit;
  • Cloud happened for real – and once an organization starts deploying their workload in the cloud, you can either get your **** together and deliver services in reasonable time, or become obsolete.

Agree? Disagree? Please write a comment.

Please read our Blog Commenting Policy before writing a comment.

2 comments:

  1. Mostly packet switching never believed in having standards for managing a device for mostly biz reasons. Management plane usually had the weakest engineers who never could undertand data modeling. Features in network devices are mostly customizations for a particular deployment instead of a holistic solution. This suited everyone since vendors ended up charging for these customizations and categorized as service revenues and recurring revenue. This enabled companies to package themselves as software companies. Network automation for packet switching shall remain a dream for some time since automation infrastructure for one device cannot be reused easily for another device whether we use restful apis or not. But that would remain an aspirational goal for some time to come. Large companies and ISPs shall invest in it to leverage monitoring data . But mostly they shall be customized solutions

    ReplyDelete

Constructive courteous comments are most welcome. Anonymous trolling will be removed with prejudice.

Sidebar