You may be reading this post thinking it is about some management philosophy – sorry to disappoint you! This post has a two-fold purpose 1 – as a response to an article I read last week (https://www.linkedin.com/pulse/why-network-industry-has-been-stuck-1980s-ciscos-embrace-joe-howard) and 2 – my new role that I picked up in the last month.
For those that don’t know, I devoted a lot of my pre-children days to certification (which I highly encourage anyone getting into IT to do). I posted previously that I got all the Microsoft and Novell Certifications that I could and I wanted a new challenge, so I undertook the R&S CCIE. This was back in the days of the 2 day lab and scenarios that at that time were highly applicable to what I was doing day in and day out. By the time I decided to take the Security IE, it had switched to a one day exam that was more of a “stump the chump” mentality in that what was tested was very rarely implemented in networks but was a lot of required learning nonetheless.
As I read the above post from Joe Howard (which is a very good post) – I was struck with what I get to experience many days in my current job. I get to go visit a lot of customers and no less than once a week I hear about some crazy design that makes no sense and in reality reminds me of a CCIE lab – overly complex to solve a relatively simple problem. What I believe happened is that customer networks have slowly become the CCIE’s practice lab – not from solving problems but from creating unnecessary complexity to ensure job security and/or prepare the individual to pass the lab. At a minimum the art of simplicity was thrown out as the first step in solving a problem. This in turn creates a patchwork of design modifications and point in time fixes that over the course of time becomes a big ball of mud.
I was at a large customer the other day that I have worked with over the years. They had the simple edict – no proprietary protocols EVER. This adherence to discipline in itself helped keep the network clean and sleek. As people have moved on, proprietary things have moved in and complexity ensued locking in yet another customer. I talked with another customer the who had a full MPLS network inside of their relatively small datacenter. I was shocked. When I asked why – there was no valid reason that VLANs couldn’t have solved his problem. Combine this with yet another example of a customer that implemented hundreds of static routes throughout the network and complained that he could never go on vacation in fear that something would go wrong and he wouldn’t be there to fix it. We have got to stop building complex networks in the name of job security and training for our IE lab. I believe that the IE has made networks a work of art versus solving the business demands. The industry is moving on and some of the most beautiful designs I see are those of the cloud providers who are incredibly large, but incredibly simple. This equals more stability and greater ability to orchestrate everything they do. Several that I spoke to don’t ever plug a laptop into the devices, everything is automated. If it can’t be automated it doesn’t go in. Complexity is very very hard to automate. To drive my point home about vendor introduced unnecessary complexity, I went to a few different vendor’s sites the other day and one had over 100 data center design guides in some flavor – how in the heck do you decide how to put that all together? No wonder it takes an IE level person to make this stuff work. The industry can do better here!
Now to my second quest. I recently took over the leadership for training and certification at Arista. Working with some great people like Gary Donahue who is a legend in the networking industry with his Network Warrior and Arista Warrior series of books. Gary and I were talking about launching the next line of Arista professional training and exams – one which will be an “Expert” level lab exam. What I don’t want the exam to be is a reason for someone to introduce unnecessary complexity into a production network to show how smart they are. We are thinking that half of the exam will be about deep knowledge of protocols and building data center networks, but the other half will be about automating and orchestrating capabilities thus forcing simplicity in design. We plan to include items like leveraging the unmodified Linux capabilities to solve real problems, extensibility in fixing and introducing new capabilities, and then of course troubleshooting, and last but not least, using DevOps to detect and fix the problems before they ever cause a problem. Yes we want to unleash the proverbial “Chaos Monkey” in the lab and see how well the network stands up.
We are early in deciding what the lab will become. We are getting together some of the foremost experts in the company to help us build scenarios and ultimately the lab. I won’t apologize for it being brutal. However my hope is that it is a useful brutal to drive simplicity versus a reason to implement unnecessary complexity in real networks with little return.
Yes the journey for both of my CCIE’s was worth it. I learned a ton and implemented much of my routing and switching IE in real life. It is time for the next generation of learning and development where we encourage creativity – but creativity starting with simplicity to solve the problem. In the end if you can’t orchestrated it and maintain it – you might want to think about a different approach to solving the problem.