A Cisco CCIE Discusses His Journey with Network Automation
This post is not my own, but rather the words of my dear friend Kevin Corbin,
who has mentored and helped me to infinity and beyond!
They say there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors.
I have worked at Cisco for the previous 12 years, connecting people to things and things to other stuff. Sometimes it’s easy, sometimes it’s hard… sometimes you have to be first, sometimes you are unfortunately not.
Cisco Live at 30
It is equally hard to believe that there have been 30 years of Cisco Live, and how much things have changed in these 30 years. I’ve had the pleasure of participating in many of these in various capacities: as a customer, as a partner, as an employee, as a speaker, and as an exhibitor.
In the midst of a busy week, I couldn’t resist the temptation on several occasions to take a few moments of silence, take in this beautiful view and reflect on my time at Cisco Live over the years.
I spent many years attending Cisco Live as a customer of Cisco. I gained a deep technical understanding of how routing decisions made in software could be programmed into hardware for more performant forwarding (and that cache invalidation is indeed a hard problem). During the IP Telephony transition, I learned how Cisco technologies could both improve collaboration while decreasing costs. I was a network engineer, so for me this seemed a discussion about new protocols running on top of the network, and a consolidation of circuits. We were already running IP, IPX, AppleTalk and others, across Ethernet, ATM, Frame-Relay, and even dial-up lines. This intuitively made sense to me and was an interesting technology discussion. I was quite a bit younger and just naive enough to think that this was just a technology discussion, it wouldn’t be until much later that I could appreciate that the real value (and complexity) of this transition wasn’t the technology… it was the implications on the organization, and the operational processes and procedures. Traditional telecom and network teams were required to work together in ways that they had never done before.
As a partner attending Cisco Live, I learned about the special relationship that Cisco had with partners and customers. It was amazing to make the connections with the engineers developing the products that we were trying to help our customers operationalize, not to mention the staggering scale that can be achieved by leveraging partners as an extension to the Cisco field teams. The partner experience at Cisco Live and working with the teams made it very clear to me that my next step was to do whatever it takes to be part of that magic! Additionally, Cisco knows how to throw one hell of a party! Just ask Weezer and the Foo Fighters who put on an amazing show at the customer appreciation event this year!
Cisco knows how to throw one hell of a party!
As an employee attending Cisco Live, I was learning how the sausage is made! In my time at Cisco I have had the unique to opportunity to experience how new products are built and taken to market with Nexus, Unified Computing System (UCS), Application Centric Infrastructure (ACI), and Network Services Orchestrator (NSO).
Cisco Live always proved to be an invaluable forum for the teams developing these platforms. From the earliest days of the product life-cycle, and being able to brief customers in whisper suites, to formal product launches, and continuing education about how customers can maximize the value from their investments in these platforms. I’ve met with the smartest engineers in the world, who aren’t doing it for the money, but rather in a firm belief they could change the world. And I knew they were credible, because they had done it before. I’ve watched them change industries by solving the problems our customers had, with the platforms they would soon deliver!
A few highlights
In the Nexus iterations, the story was repeating itself, we were driving cost optimizations by running new protocols over the top of the network, and reducing the number of circuits required to a server. But now the storage team and the network team needed to work together in new ways to achieve a common purpose enabled (and sometimes forced) by the technology. They say that history never repeats itself, but it definitely rhymes! I also learned that naming things is in fact a hard problem. We were building products relevant to multiple infrastructure domains and needed product names that fully encapsulated the convergence of domains that was well underway. While naming things is in fact a hard problem, sometimes it turns out that renaming things is even harder. After all, why can’t you just delete the thing and re-create it?
During the launch of Cisco UCS, and the accompanying mega trend of server virtualization, I saw history repeating itself once again. Technology was enabling teams to work together in ways they had not before. This time it was the server team and the networking team (which was now inclusive of the storage team and the telecom team!). In a lot of ways, the story was the same: we were using technology to allow our customers to take lower cost DIMM modules, and mix them together, effectively making them appear as though they were one larger DIMM. This allowed higher densities of virtual machines to be placed on the server. But at the same time creating a too many eggs in a basket problem that could luckily be solved by simplifying thinking of the servers themselves as a flow of data over the network enabled by various live migration technologies.
Application Centric Infrastructure (ACI) was an inflection point in my career. On the one hand, it was simply taking the Network, Storage, and Compute technologies we had been working on, and combining them together into a single system to improve operational efficiency. And for good measure, let’s invite the application folks to the party too!
From a personal standpoint, I had reached my own Nexus. Thus far, I had been fairly successful looking at the network as the platform that we simply kept adding new protocols and packets to it. Packets, nothing more aside from the typical Quality of Service conversation where everyone’s application is the most important application (according to them). In hindsight it seems so obvious, but until this point I hadn’t really spent much time thinking about what those packets were and what they represented. This time the technology was disrupting myself. It was scary. A lot of folks like myself, had gotten into networking (and other infrastructure domains) because we were fascinated by technology, computers, and the Internet. But were not, and in many cases intentionally avoided becoming, a programmer. This time around the technology was threatening my experience and knowledge, and would force me to learn new things about software development and APIs. Peers around me started asking questions like “Do I need to become a programmer?” My time at Cisco had armed me with the tools to face transitions and uncertainly fearlessly, and so I dove in head first, embarked on a new journey to arm myself with the skills I needed to survive this latest transition of Software Development and Infrastructure Operations.
I was introduced to the concept of Infrastructure as Code at Interop in 2012, and first started hearing about DevOps around the same time. My first introduction to DevOps was from John Willis, his “CAMS” definition of DevOps is still one of my favorites. I’ve come to learn that culture is indeed the most important criteria for success in most of the organizations that I work with these days.
I remember the excitement about Cisco’s acquisition of a company called Tail-f, which had developed a suite of products that both modernized interfaces to infrastructure devices, and managed devices without modern interfaces. Their approach had already been proven at the largest Service Providers in the world, and I was confident that they could leverage that approach to solve those issues for my enterprise customers while at the same time providing a path to evolve and modernize the skill set of the network engineers in the same way they were modernizing the device interfaces.
DevNet is all the rage these days, but there was a time when it wasn’t so well known. I’ve enjoyed watching the amazing growth that team has had over the last few years. At Cisco Live this year, I cannot even count all of the people I met with that said things like:
“I didn’t even go to any of my scheduled sessions because
I just spent the entire time in the DevNet Zone”
“It seems like in a few years 90% of the sessions will be DevNet”
The DevNet Zone at Cisco Live is the area where two worlds meet – the world of App/Dev, and the world of programmable network platforms. Talk about Aha to the Ka-Ching … did you come back or are you still reading John’s blog?
Helping customers manage their transition towards a DevOps operational model
Since those days I’ve spent the last few years at Cisco working with customers, partners, and internal Cisco organizations trying to apply these principles in everything we do at Cisco, while working with customers to do the same thing in their organizations. In doing so, I’ve had the opportunity to work with more exciting technology from Cisco, focused on helping customers manage their transition towards a DevOps operational model, and providing content to get customers started.
The highlight of Cisco Live for me this year was the Automate Infrastructure booths in the DevNet zone. There we were able to take customers through a journey towards network automation, and showcase some amazing demos the team worked very hard on. The technologies on display here were:
- A preview of a forthcoming version of the Cisco Virtual Internet Routing Labs (VIRL) allowing customers to model their existing, and proposed network changes
- Cisco Network Services Orchestrator (NSO) giving customers a view into the technology that many service providers have used to rapidly deliver network services to their customers, and his quickly becoming attractive to many enterprises as their automation initiatives drive them beyond the low hanging fruit, and into more ambitious automation projects
- pyATS and Genie, an open-source end-to-end DevOps automation ecosystem enabling engineers to perform stateful validation of network operational status using data-driven, reusable test cases
The booth demonstrations also showed how customers can use streaming telemetry to complete a feedback loop providing real time metrics of how the network is performing, and indicators as to when network optimization may be required.
Kevin Corbin (top row, center) with other Cisco engineers
and BEs involved on NetDevOps-related activities
Enabling Development and Operations teams to work together
Most importantly, the Automation Journey on display at these booths, showed customers not just these emerging technologies which will be delivering tangible benefits to customers. In typical Cisco fashion, the team displayed how these technologies work together to move operational models towards Infrastructure as Code, and Continuous Integration / Continuous Deliver pipelines for managing network configurations. I couldn’t be happier with the way this cross-functional team, from all over the world came together to provide meaningful insights that customers found extremely valuable and timely, as they continue their own automation journeys. As is the case with the previous market transitions that I’ve experienced, DevOps is exactly what it seems: helping Development and Operations teams to work together in ways they haven’t previously. And, as always, Cisco is at the forefront of enabling this through its technology.
Cisco Live has always been about putting customers front and center, providing a mechanism for engineering teams to get direct feedback from the customers, and maximizing the value provided by their product offerings. In this regard, our development is tightly coupled with the Operations of our customers. The 30th year was no different: the team was actively tweaking their own roadmaps in between what seemed like a non-stop flow of visitors to the booths.
Be fearless in the face of transitions
In 12 years at Cisco, I’ve had the opportunity to work with and receive mentoring from some of the smartest engineers on the planet and have gained some of my most treasured friendships. I am more certain than ever that the impact Cisco has had on the industry will not only continue, but be amplified by the next wave of engineers that I’ve had the pleasure of working with and mentoring on their own journey. For those that are just starting their journey, the best advice that I can give is to be fearless in the phase of transitions, and leverage the wealth of resources provided by DevNet and the broader Cisco community, including events like Cisco Live. You’ll find that you are not alone!
The most important lesson I’ve learned at Cisco is that no product is ever perfect. But by partnering with our customers and keeping them as our true north (and standing by them in the face of things as uncontrollable forces such as solar flares creating those off-by-one SRAM parity problems) we can have enormous impact. Cisco culture will shine as its people will stand shoulder to shoulder with their customers and do absolutely whatever it takes to weather the storm, and come out the other side. After all, we are stronger together than we can ever be alone, and together we are The Human Network!
Some of it you learn the hard way
Some of it you read on a page
Some of it comes from heartbreak
Most of it comes with age
And none of it ever comes easy
A bunch of it you maybe can’t use
I know I don’t prob’ly know what I think I do
But there’s somethin’ to Some of it
– Eric Church
The 30th Cisco Live was also a very emotional week for me, as it marked my last week at Cisco. I have decided it is time for the next chapter of my automation journey, which I am very much looking forward to.
I am sharing my journey here as a tribute to a fantastic company
which has truly changed the way we work, live, learn, and play!