Saturday, July 15, 2017

Network Engineer Evolution

About two years ago I made a learning roadmap for network engineers who want to transform their skills towards Software Defined Networking. I presented it at various events including Cisco Live. It was good, but it looks like I didn't provide the full story. So let's discuss it again, and we will start from the very beginning.

Any network engineer who just starts his or her career today will begin in Phase 1: as the User of networking products where the engineer only knows how to configure the product, hopefully by reading the documentation from the vendor's website first. This type of engineer is what I call "Config Monkey" (sorry, monkey!). If you think you are still in this phase, please don't get offended: I started my career here too. There is no innovation at all, only follow the manual to make the products run.

Then we will move to Phase 2: as Advanced User of networking products. This is the phase where the engineer understands how networking protocols work in detail. He is a domain expert now and can start fine tuning the protocols to optimize the infrastructure. IGP timers, fast re-route, BGP attributes etc. and the engineer should go back and forth between the protocols standard and how they get implemented in vendor's products. So all the fine tunes are based on the 'knobs' provided by the vendor. And by nature, phase 2 network engineer possesses the skill to do troubleshooting as well.

Phase 3 is when the engineer starting to become System Integrator. Even it's similar like Advanced User, but now the engineer must deal with different network functions from wireless access and top of rack switches to security devices, firewalls, domain names, caching, network-based storage, content delivery, application load balancer and so on to provide end-to-end services to end users. He is aware about design trade-offs of various choices. There is still no innovation yet, however by now the engineer has possessed the skill to design, integrate and fine tune complex system all the way to application layer.

SDN and network virtualization comes to the picture in Phase 4: Advanced System Integrator. The system now consists both physical and virtual components. Overlay network runs above the underlying physical infrastructure. Virtual infrastructure has multiple controllers and managers that need to be integrated between each other. Network services have life cycle from initiation until depletion so it must be monitored. Phase 4 engineers talk about APIs when integrating different components. Both physical and virtual networks must run in harmony to provide end-to-end connectivity for the users to access the applications and services.

Once the engineer passes Phase 4, this is the point where he can decide to take either one of different technical paths: first, is to move towards the business and start becoming Solutions Architect. Architect must translate business requirements into technical specifications, and provide integrated solutions to answer the requirements. We can live happily ever after here. I know it because I used to be in this phase for many years when I work for Cisco.

The second path is like what Morpheus described as the red pill: stay in Wonderland and learn how deep the rabbit hole goes. We can choose to stay as engineer to go even deeper in the next two phases.

Phase 5: Contributor. Phase 4 engineer assumes all components will just work when they are integrated, just like playing Lego. Yes, she still needs to understand how one component consumes the API of the other component. But in reality the integration is not, or never, that straight forward. Engineer moves to phase 5 once she starts developing few components to make the system works smoothly. It could be as simple as making automation script using SDK provided by the product's vendor. Or create new driver for an open source platform to connect to specific network device. Or customize the current module of one software to make the system runs. Engineer writes code, understands software development workflow, and fills up the missing ingredient to build one solid system.

Phase 6 is the phase served for Creator. This is the God-mode in Network Engineering. Engineer can look at the current network protocol and decide to invent the new and (hopefully) the better one. When building a complex system with multiple products from different vendors, engineer can assess if it is required to build new software component to have a successful integration. Phase 6 engineer thinks about scalability all the time, centralized vs. distributed model, and about the workflow from beginning of user's request until the service is provided. She generates ideas require to solve complex and open-ended problems. She thinks agile and runs iteration to optimize the system. Engineer in this phase is the one who translates business intent into automated workflow execution to deliver the service.

So let's look at my T-shape SDN Skill Transformation path and try to relate it to the 6-phase of Network Engineer Evolution above.

Obviously you need to be at least a Phase 3 engineer before looking at this path. To start the journey in Phase 4, you need to learn virtualized infrastructure for network, compute and storage as well as the managers and controllers to manage them. Learn abstraction and modeling. Then learn software architecture and engineering. Get involved in software development. Start writing code or optimize existing code to move to become Contributor in Phase 5 and beyond. Or if you decide to take Solution Architect path instead, switch the mindset and learn business skills.

I won't mention any vendor's product, or any vendor's certification, anymore in the evolution. Understand the expectation of what engineer in each phase has to deliver, skills that must be possessed, then make your own judgement to decide which vendor or which certification program (if needed) you want to use in your learning process.

And please don't be mistaken to think I self-proclaimed myself as a Phase 6 engineer. I made decision a while ago to become Product Manager instead, that provides me opportunities to work with many creators to build the next cool things in networking.

Final thought: it's okay to start as monkey once. But knowing where we are, and where we want to be, can surely help to plan how to get evolved.


Prasanth said...

Great post, and nice breakdown. Can you point me out, where can I start with the network virtualization. I'm presently at phase 3, and also leveraging the APIs provided by the vendors.

Moazzam said...

Thank you for your post, this is very interesting. I would also love to hear about you Product management experience. In networks it was always R&D kind of process. But I am sure the PM role is becoming more and more relevant especially considering deeper inception of Automation and even NetworkML.