Last week I was in Mountain View, in a room full of senior Network Engineers, and we were talking about the skills that need to be developed by more junior Network Engineers. Suddenly someone shouted from the back "CCIE!" and the whole room started laughing.
So CCIE is a laughing stock now?
No need to get offended. You have to understand the context here:
These group of people have been working for the best company in the world. They have been working on the most advanced network infrastructure. The company's undersea cables connect all contingents, to delivers 25% of worldwide Internet traffic.
These people didn't develop their skill through certification. They developed their skills by building the real stuff. When these group of Network Engineers realized the network capacity in the company's data centers has grown so fast that conventional routers and switches can't keep up to meet the requirements of its distributed systems, they decided to build its own instead. These Network Engineers build and operate software-defined networking, before the world invented that terminology. They've been automating network operation in Data Center, WAN, Internet Peering, all the way to Wifi and Enterprise networking, to support 7 company's products with more than billion users.
But think about my situation 18 years ago when I started. I was jobless. I graduated not from Computer Science. There was not any clear guideline available on how to become a Network Engineer. There was not any opportunity to develop my skills. Pursuing certification, from CCNA to CCIE, was the most logical and the best choice at that time.
Having said that, it's 2018. And if any of you think your current situation is similar with me 18 years ago, and that makes you try to repeat my experience with certification today, you should think again.
Remember the most important principle here: use certification as a mean to learn the knowledge. Certification program is good since it puts structure to your learning path. And certification exam, is usually a good way to measure your progress. So if you believe your certificate will get you a job, it's up to you. If you still like to read "top paying" or "hottest IT certification" article, be my guest. I can tell you straight away no certification will be able to put you in that room in Mountain View.
However, if you agree with my point to use certification as guideline to study, here are the Top 10 that I think every Network Engineer should pursue in 2018:
(Please note I'm putting only the certifications that I have personally taken and possessed, to walk the talk)
1. Treat Network as Cattle, not Pet
This comes from one important idea in Google Site Reliability Engineering: that in order to have a reliable system, you need to make it out of interchangeable and replaceable parts that can fail at any time. Bikash Koley, CTO at Juniper Networks, reviews the challenges of networking within large scale infrastructure, reviewing the change needed from treating networking less like pets, and more with fleet management in mind.
This first point is not about certification. It's about mindset.
2. Vendor-Agnostic Networking Skills
Just like shown in one example of Google Network Engineer job ads that I posted several months ago, network engineering is here to stay. We still need someone with in-depth networking knowledge. You still need to know IGP and BGP and traffic engineering in details. Those knowledge are owned by Network Engineer (NE), not Software Engineer (SWE), Site Reliability Engineer (SRE) nor Security Engineer.
And you may use certification to build networking expertise. My advise is to reach at minimum CCNP/JNCIP level. You are welcome to continue to Expert level, but there is a risk for your knowledge to become too vendor-dependent for the implementation of the concept. And this also means take only one: either CCNP or JNCIP (or any equivalent from another vendor). They all teach the same concept, the only different is in the way to implement it. And you can go to multiple tracks to learn Routing & Switching, Data Center, Service Provider, Security and so on depending on how much you want to cover from an end-to-end network.
3. Linux is the New English
Many tools for network engineer run on Linux, so it makes sense for any Network Engineer to know how to use it. I believe at minimum you should have a System Admin level knowledge. If you can go deeper and learn about hypervisor, kubernetes pods and Linux virtual networking, it is even better. Application workloads run on Virtual Machine or Containers are running on top of this OS as underlay. Today's network engineer must know how to connect them through virtual switch and virtual network, using several options of overlay protocols.
To develop Linux skill you can use something like RHCSA or equivalent.
(Note: I don't want to get into the debate of Linux vs. BSD here. Just look at the tools that you are using as Network Engineer, and check which OS they run and study it)
4. Speak API not CLI
Arista Networks CEO Jayshree Ullal once said “CLI is the way real men build real networks today.” In large-scale network this is definitely not the way to go. Instead of connecting to network device manually using CLI, our management tool or software must connect to the device using API. Understanding what is supported by the API can help to develop or even troubleshoot any issue between our software and the device.
I don't think there is any certification specifically covering API (and I haven't taken any that covers this). But I found this Network Programmability Basic learning program from Cisco DevNet is really good in explaining APIs.
5. Controller and Orchestrator
Network used to be treated as group of devices running autonomously, with distributed intelligent, and each device is making the decision where to forward the packet. If we treat network as one fleet, the decision should be done from central location. This central Controller or Orchestrator must know how the network looks like, the current state of the network, and in Intent Based Networking System it can even translate business intent into specific instruction to be sent to network device.
In an end-to-end environment, all physical and virtual resources are managed by Controller and Orchestrator, that consists of network control, compute and storage control and service control, with cross-domain orchestration to manage all of them. This Controller and Orchestrator provide northbound API for the application, and use various southbound API from all the control layer to the resources. Southbound protocol from controller to the device does not have to be OpenFlow. However, if somehow you want to learn this protocol in more detail you can use the certification from ONS.
6. Automate or Die
Running network infrastructure as code is not something cliché anymore; it's real and necessary. When you have more devices in the network, automation is the only way to avoid human error. However, automation can bring complexity. And one mistake in CLI may bring down only one device, while one mistake in automation platform can be propagated quickly to the entire network.
My advice is to build your automation skills slowly: starting with Level 1, task specific automation, where you can write simple code to communicate to network devices using various APIs to execute certain task. Then move up to Level 2 by using platform like Ansible and its playbook to execute series of task to complete one workflow. Continue doing this until you reach Level 5 automation when you just need to define the policy between users or components in the network, by providing declarative requirements, and the system will execute without any human interaction. Zero human touch networking. This is the level for Intent-Based Networking System.
7. Cloud, more Cloud, and Multi-Cloud
According to PwC research, virtually all mid-and large-sized enterprises expect to move some workloads to the cloud in the next 1-3 years. Google spent over $30 billion in an effort to significantly improve its Cloud infrastructure. Alibaba now offers even more features than before in an attempt to take on the might of Amazon. Oracle is making massive investments in its cloud infrastructure with the addition of 12 new data center locations around the world, to join the cloud wars against IBM and Microsoft.
If the paragraph above does not encourage you to learn about Cloud, then you should! Enterprise IT in the future will have to connect their premise to Cloud, to multiple Cloud providers in fact, and as Network Engineer you must design the interconnection. At minimum you need to learn at least one Cloud provider, and you can use certification like Google Cloud Architect or equivalent for AWS.
8. Model Driven and Data Structure
A model is a simplified representation of a system. When we send the command using certain protocol to the device over API directly, this is called Stove Pipe approach. We need an abstraction layer, or a model, in the middle of the communication between all those protocols with the network devices. Think its function as mechanism to “normalize” devices configuration into one standard data model then push that configuration into devices using one standard protocol.
Company like Google has been using abstraction with model-driven approach to provide network topology view, configuration data structure and content, and telemetry data structure and attributes. A data structure is a particular way of organizing and storing data in a computer so that it can be accessed and modified efficiently. It is a collection of data values, the relationships among them, and the functions or operations that can be applied to the data.
Again, I believe the videos from Devnet's Hank Preston is the best place to start learning about this.
9. Analyze Users' Behaviors
Many Network Engineers are busy everyday firefighting the problems in the network. They are the King of troubleshooting. Sometimes they troubleshoot problems that happen due to manual deployment and provisioning in the network. When we start using automation and controller to do deployment and operation of the network, Network Engineers are not going away. Now they need to do work that is closer to the users. They need to understand more who the users are, what they do in the network, what application they are accessing, how the users behave, and so on. In such a away Network Engineer needs to move to become network analyst, to collect those information and perform the analysis in order to predict any problem in the future and prevent it before it happens. Network Engineer will then provide better user experience to the users.
I don't know if there is any certification to teach you to do this, but recently I took Coursera's From Data to Insights with GCP (even the analysis is not related to networking) and I found it very interesting.
10. Software Engineering Principles
Remember, Network Engineer is not a Software Engineer. However, in order to treat a network as a fleet, using controller and workflow automation, that connects to network device using APIs, it will be really helpful if any Network Engineer understands Software Engineering principles.
Network Engineers produce architectures and designs. Those architecture and designs should incorporate software thinking. How can software implement the architecture at hand? Which primitives do we need, and in which order, to implement and operate the design? You don't need to write code it all yourself; But it helps if you can specify it as a set of requirements to a Software Engineer.
In my opinion, any Network Engineer should at least take CS50 class: Introduction to Computer Science from Harvard. And you should know at least Agile software development framework such as Scrum. You can take this certification if you want.
The top 10 above should prepare you to become the Network Engineer of the Future. Or, as I mentioned it before, you also have a choice to spend more time closer to the business and start becoming Solutions or Enterprise Architect. Architect must translate business requirements into technical specifications, and provide integrated solutions to answer the requirements. You may want to pursue business-related certification (Togaf?) or even an MBA.
And if somehow you have a better chance to develop your skill by building something real, just like those Network Engineers in Mountain View, forget the certifications all together.
Just start building.
