Have you ever wondered what Network Automation is and what Model Driven Programmability means? How did we get to this point where the network is no longer an isolated world and where the number of connected devices are more than you think.
Like all areas of life, networking has also undergone an evolution. And the evolution has been faster than you think. And just like human evolution, the network and its main actors have also undergone drastic changes over time.
Let’s start from the “prehistory” where everything was born …
I present to you Carl, a network engineer with several years of experience, his skills range from Layer 2 Concepts such as Spanning-tree, VLAN, Trunks to the knowledge of one or more routing protocols (OSPF, RIPv2, IS-IS, EIGRP), Security , MPLS / VPN, Fiber Channel, QoS
Etc ..
And certainly Carl has had to write some scripts to automate some tasks or to have the information at hand when requested, so he also has skills on:
TCL (Tickle Scripts)
EEM (Embedded Event Manager)
Expect Scripts
All this when the network was something like this:
Where there were only routers, switches and servers and it was enough to access the datacenter to be able to touch each individual device with your hand.
But things evolve … until the introduction of virtual switches, virtual machines, etc ..
But Carl’s approach hasn’t changed much … since a virtual switch is “software” so it’s not part of the network … better leave it to system administrators. Nobody will ever put anything critical on a server with a virtual switch, network redundancy is physical so it’s not important.
The evolution continues and Carl collides with the Blade switches, which most of the time were provided by the server products and therefore were never on Carl’s “shopping list” … so better let us still play the server administrators.
But things did not stop and shortly thereafter Carl started having to interface with linux bridges and containers …And then Cloud, Cloud Exchanges … where the network is no longer physical but all virtual …Let’s not forget the services of Load Balancer, Firewall, IPS, DNS, gateways and much more …
Ok ok, there has been a change and we see it every day … but how can we keep up with the times … Let’s take another step back …
The ISO / OSI stack…. We have all seen it at least once in a lifetime and we have all memorized all 7 levels .. some of these, however, for Network engineers are completely black boxes … in fact Carl only cares about the 3 central levels, level 1 is physical so it doesn’t interest network engineers … the others are “software” so they don’t concern us. The important thing is that the package arrives at its destination, then what it contains is no longer our problem …!
Fortunately, however, today things are no longer like that and the sessions between applications that could be on a container which in turn are on virtual machines that can be moved from one part of the world to another in an instant, are important. The safety at the transport level is one of the elements that works with the other levels to ensure consistency and safety for the applications, therefore evolution has destroyed Carl’s convictions and has therefore faced 4 phases of networking:
Phase 1 – The Stone Age: We started with Spanning-tree and VLAN where the most complex thing was to decide whether or not to put printers in the same VLAN!
Phase 2 – The Bronze Age: with routing protocols, WAN Design with concepts such as MPLS (many times managed by the provider), IP management that led to the creation of IPv6 … and that today has led everyone to have a network dual-stack … right?
Phase 3 – Renaissance: where concepts such as SDN, OpenFlow, Overlays Networks, VXLAN have started to be on everyone’s lips, micro-segmentation, MP-BGP …
Phase 4 – Programmability era: Cloud, Python, REST API, NETCONF / YANG, “Fabrics”, DevOPS, Containers …
But why there has been such a sudden change? The reason is very simple: the digitalization of companies and the advent of the Internet of Things (IoT) where the agility of applications has become fundamental and where access to information is as easy as opening a tap in the house. These changes are challenging companies and therefore it has come to an era in which those who have a computer and a credit card can really put a large company in difficulty.
At this point, all companies thought of moving to the Cloud thinking that the cloud was the solution to all problems.
But let’s be clear … The end result that many companies have achieved has been only an increase in costs and not quite have received the flexibility that was expected!
Many of us may be a little angry and think that the era of networking is over … but that’s not the case. If you are angry at the end it is a good result since you are already in phase 2 of the 5 phases of pain !!
It is no longer possible to ignore the APIs, and to close in a hedgehog with your own Command Line Interface … there is a need for a change and to get to the acceptance phase !!
So what are the skills that a modern network engineer should have or acquire?!?
Let’s see how Carl approached the problem … Carl divided his path into 3 phases:
Phase 1: where he learned to work with Python, understand what the REST APIs are, become familiar with JSON and XML and start doing some github projects using git
Phase 2: Carl has expanded his knowledge on Linux, Ansible and Docker to get to configure his devices with NetCONF and YANG
In phase 3 Carl learned concepts such as Linux networking, container networking and Network Function Virtualization (NFV)
Also During his journey Carl met and learned
Network Controllers
IOT Networking
Cloud Networking
Contecci “DevOPS” –
Approaching everything in this way Carl therefore has new skills in both programming and expanded his knowledge on networking. In fact, Carl now has core programming skills and new networking skills.
And we are happy for Carl…. But what about me? What can I do?
Well if you are reading this article you are already on the right path … you just have to deepen the topics seen in this video to start your journey towards the era of programmability.
Contact me if you need more info or if you would like to attend one of my course on these arguments.