One of the common themes that I hear in the data center networking industry is how automation efforts seem to have stalled in many companies. After some easy successes with reducing keystrokes on simple tasks the projects become aimless and eventually just flounder. There are a variety of reasons for this that have been explored but one that I want to focus on is the lack of standardization.
One of my first big IT projects happened when I was an intern at IBM. I had to write a simple script to change an MTU value in Windows 2000. I had to iterate through various interfaces looking for a value and change it. Simple, right? You’d think that but getting things going was a nightmare. One group that I worked with wanted me to learn Perl and use it. Another felt I needed to use IBM’s own ObjectREXX scripting language. My mentor told me I needed something easy to use that was also easy to decipher. I ended up “automating” this task with a series of nested IF statements in a batch file. Ugly and effective.
Fast forward almost 25 years and I find that the same challenges are being fought again and again in the enterprise. What standards should we use? Are we going to create a custom hodgepodge of code that accomplishes the goal while being completely unmaintainable? How can we build automation systems that can only be worked on by one or two people in the organization. If you are a fan of Gene Kim’s Phonenix Project, you can already see the Brent Block happening here. If one person or team is the only one that can decipher the collection of tools and code used to build your automation efforts, what happens when they leave?
Picking A Winner
I can tell you what’s going to happen when they leave. Their replacements are going to give up. They’re going to take one look at the motley code you’ve created and toss it in the bin. They’re going to start over with something they’re more familiar with. Honestly? They’re going to start with Kubernetes.
How do I know that? Because everything is based on Kubernetes today. What was once a small little Google project for container orchestration has become the leader in the field. People don’t even say “containers” any more. They say Kubernetes even when they mean someone else’s platform. It’s the kind of standard that is one of the first things people learn when they get into enterprise IT. If you want to have a future in computing you have to know it.
Why would a networking team want to use it? Honestly it’s because the concept of a dedicated networking team is quickly riding off into the sunset. With the advent of cloud computing forcing those concepts into the private enterprise very few engineers are ignorant to cloud concepts. They know what they can do on AWS or GKE with Kubernetes and they seek out those same capabilities in other systems. They have a standard toolkit they work from and they expect to see it no matter where they are.
Who are these engineers and operations teams? They are the professionals that are going to replace your aging networking teams. If you’re old enough to remember when Ethernet wasn’t the only protocol on the block you’re getting to the point where retirement is an achievable goal. You’ve spent your whole career trying to make stuff work. You didn’t follow the standards because they weren’t standards yet.
As a pathfinder in a jungle, your replacements are constructing roads along the path you created. They will utilize asphalt and concrete instead of a machete and torch. They do not intend to create from scratch; rather, they seek to enhance what already exists. Therefore, when determining how to sustain the automation push within your organization, how should you approach its development? Should you build it from the ground up or establish a platform that aligns with the standards your replacements will comprehend?
Nokia Knows
Nokia has built a platform that meets your needs. Nokia Event Driven Automation, or EDA, features Kubernetes principles as the core. Here’s a video from our recent Networking Field Day Exclusive event with them that goes into detail about it:
Wim Henderickx explains it way better than I ever could. Why reinvent the wheel when you don’t have to? Kubernetes gives you all the tools you need to do things right. Complex problems are easy to solve now. For example, what if you deploy a code update that breaks functionality? How can you roll that back efficiently? If you’re automating the change how many systems have been affected. Even in an organization where toolsets are easy to use finding this information isn’t always easy, especially in a crisis. However, with the change tracking built into Nokia EDA, it’s a simple as going to the changelog and rolling back the deployment. Once you’ve confirmed that the changes are rolled back you can even query the network using natural language to ensure that no devices are online that have the suspect code. An easy fix because you based it on principles that your up-and-coming engineers respect and expect.
Bringing It All Together
If you’re starting to wonder what life after IT is going to look like you also need to consider what your legacy will be. You’ve blazed a trail through buggy code and created concepts that were just pipe dreams. However, we live in a world where the exploration is done and the maintenance is key. Networks aren’t playgrounds any longer. They are the arteries to ensure your digitally transformed enterprise is solvent. That means whomever is going to step up to take your place needs to have a system they understand to maintain what you’ve built. Nokia EDA gives you one of those platforms. By utilizing Kubernetes as the bedrock for their automation platform they can ensure that your descendants can take what you’ve built and keep it running long after you’ve moved to the beach to enjoy retirement. Before you decide to hang up your CLI window for good, check out Nokia EDA and leave the next generation a legacy to be proud of.
You can watch videos from our Networking Field Day Exclusive Event with Nokia and more on the Tech Field Day website or on YouTube.
