The greatest deception men suffer is from their own opinions. - Leonardo da Vinci
“Network automation does not an automated network make.” Those same words started my formative pieceon DevNetOps. It reasoned that we must elevate DevOps culture, processes and principles above technology, end random acts of network automation, and instead pursue holistically automated network engineering and operations. The professional that implements this—from code to production—is the network reliability engineer (NRE). The NRE implements DevNetOps for network infrastructure just as the SRE implements DevOps for apps and platforms.
It’s been a journey discovering DevNetOps and network reliability engineering. With help from peers and NRE friends, I’ve faced debate and dogma forged in the fiery cynicism of the networking I&O silo. To share these lessons, let’s overturn some anti-patterns and deceptions, starting with the opposite of the NRE: those who say automation is “not for me.”
You used to hear people say, “We’re not Google. We don’t have those problems or need those solutions.” Today everyone is mad for #GIFEE and racing for the same outcomes as the unicorns. If you think you’re a thoroughbred horse in a different race, you’re utterly deceiving yourself, and your business is heading to the glue factory.
Before we can change our minds, we must open our minds. Life is an inside job.
If you're a network admin, the rationale to retitle yourself as an NRE is right in front of you. Look forward. You’ll see a future less doldrum, more creative, and one where you have more control over your own destiny and that of your organization. And more pay and job opportunities too. Yes, NRE is already an actual job title.
With retitling comes reform. You used to rely on vendors for all network engineering, but this relegated operations people to technicians instead of technologists. As an NRE, you don’t need to hop over the proverbial dev-ops wall, to engineer boxes and SDN systems. You just need to lower the wall and pick up where vendors leave off. Their day of product delivery to market and to you, is your day zero where you automate, not only integration workflows, but outcomes like accuracy, reliability, scale, efficiency and ops speed.
Rod Michael said, “If you automate a mess, you get an automated mess.” Automation must follow architecture and accuracy.
It’s common for builders to want to build, but you cannot be so swift as to forget the blueprints. There’s a balance to strike between build and design. To be sure, a DevOps mindset promotes build iteration, as did Mark Twain when he said, “Progressive improvement beats delayed perfection.”
Of course it’s not all planning processes or forging culture, but technocrats tend to obsess over technology too much. Network reliability engineering and DevNetOps is not only about technology, just as racing is not only about cars.
I’m a proponent of open source and believe it aligns with human nature. From GitHub to the growth of the CNCF and so many other projects, the open-source watershed has hit.
However, especially in networking, there is plenty of closed source. Fortunately, open APIs make integration and automation possible even for closed systems. Today, open APIs are increasingly commonplace because they’re not a nicety—they’re a necessity.
Moreover, the as-code, gitOps, and CI/CD movements shine the automation spotlight onto pre-production pipelines and processes. These trends are supported by and apply equally to open- and closed-source software, so don’t let closed source deter your DevNetOps desires.
You might believe there’s no need for infrastructure rapid iteration, agility and experimentation. But just because you don’t need all the benefits of a DevOps culture, doesn’t mean you don’t need any.
You may also deceive yourself, thinking networking is different. But just because network hardware is more foundational than application software and less flexible today, doesn’t make DevNetOps ideas impossible. It’s precisely because networking is foundational that having it automated is crucial and will add simplicity and flexibility.
First of all, there is a large software side to networking—SDN, NFV and network management—where we can more easily apply DevNetOps behaviors. Translating some behaviors like CI/CD and chaos engineering to network devices, however, isn't straightforward. In a past article on TheNewStack, I examined the difficulties aligning Agile to today’s architectures in network operating systems, boxes and topologies. In re-architecting networking for DevNetOps, we ought to draw inspiration from microservices—a catalyst for the traditional DevOps transformation—because smaller architectural units allow for smaller, safer, and speedier steps of change.
Finally, many DevOps practitioners have overcome organizational policy “barriers” like ITIL and InfoSec. As well established in the DevOps handbook, success lies not in rallying anarchy; rather the DevOps principles automate in security, compliance and consistency.
The territory is now increasingly marked with maps: training and didactic case studies. But don't mistake studying for starting. Complement your wonder with some wander. Try playing with git. Sharpen up your programming fingers. Give that tool a whirl.
There are many paths to success. Even if your journey is serpentine, even if you lose true north, you may pick up useful tools and lessons in unexpected places.
Like building any new habit, it’s useful to have a buddy, or better yet a two-pizza team. You'll progress quickest in green fields. Choose a team project with no technical debt when you’re just starting out and take small wins and small risks. When you allow for failure and iteration, you record lessons into processes and automated systems, and you grow people.
The easiest place to start is at the beginning of the project stream, where it is small, not down in the ocean. Start at day-0 and flow from pre-production to production. Build as simple an automated pipeline as possible to integrate artifacts, secrets and configuration as code. As you mature, expand the middle: pipeline orchestration, building, testing, integration, more testing, immutable deliveries, and finally orchestrated deployments into staging and then production. Eventually beyond network and SDN automated deployments, you will have other in-production automation extensions for systems integration and event handling that can follow the same pipeline.
I wanna go fast! - Ricky Bobby
Keeping up with the pace of technology is ever harder. And so goes the saying, “the future belongs to the fast.” But when it comes to automation, the NRE title tells us something very important: we must focus on reliability.
Speed alone will never win a race, and speed without reliability is a glorious way to crash and burn, just ask rocket scientists. If you were a racecar driver—one smarter than Ricky Bobby—you would say that to finish first, you must first finish.
A twin burden today, equally as confronting as the need for speed, is complexity. You know if Dijkstra, a networking hero for his SPF algorithm, were alive today, he would be a champion of network reliability engineering simplicity (a coincidental portmanteau-ing of NRE and the Juniper anthem) because of his famous quote, “Simplicity is prerequisite to reliability.”
In summary, we need speed, and we need smart. We must be consistent with simplicity, effectiveness, efficiency and reliability (...smart) while employing the economies of velocity, agility, scale and reach (...speed). We all love going fast, but it's not how fast you drive, it's how you drive fast.
The hype of DevOps and SRE is probably warranted if you seriously put it to work. I believe the same is true for DevNetOps and NRE.
However, these are just signposts. Like the Buddhist lesson that the finger pointing to the moon is not the moon itself. If you miss the moon for the finger, you’ve missed the glory.
The real truth in technology is that transformation is the only timeless topic. Digital transformation has been around for three decades, and the digital intelligence transformation is on its way next.
To manage transformation: in technology, equip for an evolvable architecture; in process, incorporate continuous improvement; and in people, embrace continuous learning.
I’ll leave you with a final quote, I often use when speaking on these topics.
It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.
- Charles Darwin
Published with permission from forums.juniper.net/t5/Blogs/ct-p/blogs
