5 Steps to Automated NetOps by James Kelly


Podcast on YouTube

In Juniper Networks anthology of 5-step frameworks, we take a different turn. Instead of focusing on a network domain vertical like the 5-steps for data center, campus, WAN and branch, we are focused horizontally across all domains on network automation. This 5-step can apply to any place in network, and be overlaid like a transparency, for example, over the data center 5-step.

5-step automated netops.png

Not 5 Steps to Network Automation

Sometimes you climb the ladder only to find it's standing against the wrong wall. 

In the pursuit of network automation, a multi-decade long affair, the narrative and advancements mostly revolved around programmability which gave way to NFV and SDN. Despite those developments, network automation seems to have ricocheted back to center. We’ve realized that the average NetOps job has practically been sealed in a time capsule compared to the evolution of software engineering and related DevOps and SRE movements.

That’s not to say network automation hasn’t gone anywhere, but progress has largely been technological in the inner-workings of products: we have slightly more autonomous systems; we have abstracted and elevated systems across more network surface area; and we’ve created more APIs, making systems more automatable. Alas, all this one-sided network automation does not an automated network make.

What has failed to change? The forlorn customer and NetOps opportunity for automation.

The handoff from vendor to customer is still, on average, very siloed and impetuous. NetOps catch what comes over the proverbial Dev-Ops wall and then has to run it. Then starts the same old crucible of some inaugural architecting, some less-agreeable administration and then hapless eons of daily toil and troubleshooting, trying to uphold availability. And we cannot forget our “friend,” IT gravity: pulling down issue triaging and blame fastest to the lowest common denominator, the network.

In brooding over that experience, surely NetOps itself is where the emphasis on automation is needed most, to evolve from automatable to automated. And the metamorphosis process cannot consider automation in the vacuum of technology alone, but rather must pay particular attention to ameliorating people and processes.

Where to Begin? 

Transforming people and process, it turns out, is hard, but luckily there are bright spots to replicate. The DevOps movement copied the lessons of the manufacturing industry to change the way software engineering was done, and now the most successful NetOps teams are essentially copying DevOps.

It also turns out that network engineers don’t fancy being called developers because developers and associated app teams are often the ones dropping the headaches, falling with that IT gravity, down upon network engineers’ heads. While most don’t mind the term DevOps or DevNetOps, implying “developer” may induce ire and make network engineers want to duck for cover. Moreover, DevOps is a fairly amorphous set of principles, so the leading NetOps teams have drawn inspiration from site reliability engineering (SRE), a prescriptive implementation of DevOps and dubbed their transformational job: network reliability engineering (NRE).

This 5-step framework to automating NetOps is a journey to a more self-driving network, but most of all, a journey of engineering reliability and simplicity. The journey stars upskilled network reliability engineers capable of some coding and wielding the tools of automation to manage the service-level goals and indicators of reliability.

Think of the framework as a map. As you orient yourself and direct your path, you’ll see progress is seldom a straight line, and it won’t begin in the same place for everyone. In all likelihood, most networkers are at Step 1, manual ops, riding the pine in the automation game and gingerly operating their networks by the ITIL book. But we’re convinced that engineers are dedicated lifelong learners and their stagnation at Step 1 is not so much from hesitation, but rather because they’re busy firefighting and the network automation narrative has not addressed them directly until the rise of NRE.

The importance of taking the first step cannot be overstated, yet it has also historically been daunting and difficult for engineers without a software engineering background. This is why Juniper has just launched EngNet, NRE Labs, ATOM, free trials, hosted trials, labs, training and services to ease the first small steps to automating. 

Reaching for Step 2, once you scientifically dissects some NetOps workflows then re-engineer what were manual tasks with some coding and tools, it’s a virtual gateway and virtuous cycle to more automating. Finding, sharing and using these tools, you also buy yourself more time to automate, partaking in less toil.


Step 1 - Manual Ops

Manual ops are actually very useful for teaching how things work and fit together, but for tasks that are arduous, lengthy and especially repetitive, network engineers need to begin to document their tribal knowledge and workflows and assess the ROI of automating them.

To move to Step 2:

  • Adopt an automator’s mindset. Be a builder and a technologist, not a technician

  • Take documented workflows and automate them. At this stage it can be any ad hoc workflow to cut one’s teeth coding and using new tools for speed, scale and consistency

  • In addition to using the CLI documentation, explore the API documentation for systems

  • Find tools that already exist and dissect them. And build those that are customized and contextual to NetOps workflows.

  • Realize the value of abstractions and SDN so that the re-creation of automation at the box-to-box or lower levels does not have to occur unnecessarily where proven systems exist. Automate on top of them.

Step 2 - Automate Workflows

In Step 2, you take documented workflows or their pseudocode and start automating small wins. The biggest pay off is in repetitive troubleshooting workflows, which are in fact an early form of testing and verification that will be useful in Step 3. Troubleshooting read-only workflows are a safer bet than re-configuration, re-deploy or read-write workflows. Automating changes during maintenance windows mitigates risk. But ultimately maintenance windows are an IT anti-pattern to avoid and changes are best handled with the reliability of a pipeline introduced in later steps.

To move to Step 3:

  • Progress beyond ad hoc automating. Begin to practice as-code and “GitOps” developer-like behaviors. Code means codifying, not necessarily programming. Use SCM workflows and a versioned source of truth for all artifacts, configurations and creations.

  • Configuration is not distributed and perpetually drifting, but declarative and codified and its changes are reviewed, as are programmed automated workflows.

  • Begin to think proactively of how to eliminate mistakes and manual triggers with both testing and sensors.

  • Connect the “then that” Step-2 automated and aggregate tasks that were manually triggered to now start getting automatically triggered. Thus, begin automating the “if this” to trigger the “then that.”

  • Use APIs and data from systems like Juniper AppFormix or other telemetry collectors and analytics systems in: 1. observability and decision making, moving to NRE service-level indicator tooling; 2. proactive testing instead of relying solely on reactive troubleshooting; and 3. automating “if this” sensors.

Step 3 - Automated Triggers and Networks as Code

Beyond provisioning, scripting and programming languages, at Step 3 you’re learning GitOps, version control and code reviewing. You’re embracing infrastructure as code and thinking about automating troubleshooting as testing and proactive verification. Test-driven network automation is inspired from test-driven development (TDD). It’s not sufficient to simply run scripts and fix problems later; but instead must build holistic tests that protect from failures.

Beyond proactive tests, we can be proactive about triggering some automated actions where event-driven frameworks will help. And proactive triggering requires building or using sensors. Sensors are sometimes based on telemetry and analytics systems that are also useful for providing or building service-levels indicators.

To move to Step 4:

  • Adopt a QA and testing mindset in making all changes, automating not only consistency, but accuracy as well.

  • Testing processes are inserted in between “as-code” and deployment on a pipeline. Congruent to software engineers using a DevOps pipeline, we could optionally call this a DevNetOps pipeline or networking CICD pipeline, like Juniper’s NITA framework.

  • Move toward expediting more frequent deployments without maintenance-window woes because of higher confidence in automated change testing.

Step 4 - Continuous Processes and Pipeline

Here, the technology and automation runtime takes on a new axis of pre-production instead of only in-production. Step 4 adds a CICD pipeline for running automated testing.

Continuous integration (CI) allows being able to integrate code changes at any time. For example, these could include programming changes or a configuration change. Reliable changes are made possible thanks to automated testing. The automated merging of sometimes concurrent changes into a safely tested main line and building the artifacts necessary for deployment is continuous delivery (CD).

Automating the deployment itself is also wise (here’s a customer example) and reaches toward continuous deployment (also CD). And even actual continuous deployment still involves manual judgements. Truly deploying any time, especially following the immutable infrastructure pattern, can cause controlled, isolated outages that require architecting and automating around the outage to preserve availability and not drop traffic. In microservice-crafted software, deployment patterns like blue-green, canary or rolling upgrades are more readily possible, but networks are not traditionally designed and architected for such things, although today some SDN systems are, and redundant or sliced hardware systems are closer to enabling it. 

Beyond CICD, continuous response (CR) extends the event-driven if-this then-that from Step 3. Also CR acts mostly in production instead of in the phases of pre-production and deployment. CR with machine learning, deep learning and big-data analytics can be used for observability and automated regulation of networking systems to achieve optimization and efficiency far closer to the edge of the envelope than what a human would manage. See the Juniper blogs on self-driving networks for more on this concept.

To move to Step 5:

  • Evolve tooling and thinking to NRE / SRE concepts

  • Operations culture, observability and planning is data driven

  • Seek to understand system efficiency, effectiveness and satisfaction to customers (e.g. the up-stack IT organization or an SP’s actual customers)

  • Use chaos engineering and experimentation to understand system boundaries, limits and dependencies to optimize and plan for capacity and what-if scenarios.

Step 5 - Engineering Outcomes

While Step 5 is the last step, it’s still one of continual learning and growth. This allows quick and safe iteration on the network and fine tuning of processes to focus on higher-order reliability metrics and other goals. Don’t stop at network uptime—dive deeper and continuously improve the ability to respond to issues and change.

The network ceases to be the center of the universe in this step and an NRE specialized in networking will manage reliability with error budgets, toil budgets and service-level indicators (SLIs) like any other SRE. They do this for themselves with service-level objectives (SLOs) and for their dependents with service-level agreements (SLAs). They consider their reliability dependencies; for example, they may have reliability dependencies on software running on infrastructure outside of their control.  

An NRE in this step has a world view in layers of separate concerns and understands their place in the stack.

With agreements, automation and tradeoffs, reliability is a goal to be managed, not necessarily maximized. Speed, agility, efficiency and other successes are incidental for the NRE meter that holds reliability and availability prerequisites to other useful economies.

Flip through our 5-step framework slides to learn more. Technologists seem mostly gripped by the 5-step tool landscape slide, but progress is less about what you use and more about how you use it.

Please leave a comment below about your journey and lessons, and finally, thanks for sharing these ideas—long been missing in the automation discourse.

Podcast on YouTube

image credit 9114 Images/pixabay

this blog was also published at

The Wisdom of the Giants in SD-WAN by James Kelly


Podcast on YouTube

When it comes to your branch how can SD-WAN upgrade without also uprooting? Tall trees may tell.

A Branch’s Reach Should Not Exceed Its Grasp

They are the showy exterior of your organization: your branches, your stores, your schools, your sites. But insofar as networking domains, these are the humblest of locations with little or no networking expertise and sophistication. In the past, your networking grasp was feeble in the far reaches of the branch.

Now the story goes that SD-WAN is changing that. It’s putting the prowess of your brightest networking pros and the autopilot  automation of SDN steadily into these network extremities. But this is only the beginning of the story. So allow me to disabuse you from the enrapture of the shining fruits and perfumed flowers of the branch that is SD-WAN today.

You have been tricked. This was not the story, merely the first act.

Focusing on SD-WAN, my friends, we see the fruits. Take a step back and look wider. Now we see the tree. Now we see the roots.

One Tree: Everything Is Connected

The levity with which some people and vendors approach branch networking with SD-WAN quickly fades when they realize the simple truth that, beyond the branch, everything is connected. It is one tree.

Ungrounded SD-WAN solutions ignore what’s below the branches and clouds at tree tops. But approaching enterprise networking grounded in reality, you see the whole picture: your wide-area is not only your remote and branch connectivity. Everything is connected between branch sites, campuses, headquarters, data centers, and certainly today, multicloud—SaaS and your own cloud-based applications.

You would never be so credulous as to protect a tree’s exterior, believing it’s safe from harm. And no one would mistake strung-up ornaments for the tree itself. How about vines overlaying the tree? Yes, they could reach the branches. But they still aren’t your tree, nor its species, and they cannot be grafted on. This is SD-WAN for dummies and by decoration, but it parallels some SD-WAN propaganda.

SD-WAN savvy would never use proprietary control and data plane protocols that won’t graft and interoperate with your wider network. Security would not be secondary and sheath, but foremost in the immune system of the network first. Add-on network functions like VNFs would be symbiotic and seamless with network design and management. And other virtualized branch services would felicitously fold into the SD-Branch canopy or NFV-centers in nearby limbs.

This is multicloud and multi-site thinking, end to end and top to bottom. While its natural given Juniper’s portfolio, it’s quite different than the thinking of some other SD-WAN vendors whose niche interests, I leave to be addressed with the words of a fine woodsman. “When we try to pick out anything by itself, we find it hitched to everything else in the universe.” -John Muir

Layer Upon Layer

Just under the bark are the newest layers of a tree. Pushing out and up, a tree’s trunk core and deep roots nourish new growth and give it strength to endure the tests of time.

Drawing a parallel to networking growth and longevity, you may have observed this strategy at Juniper, where investment is steadfast in Junos and our platforms. Customers enjoy the benefit of this continuity, as investment protection and the ability to simply extend and build on base systems with SDN, like SD-WAN, employing our NFX, SRX, and MX Series systems and interoperating with the routing of all Junos-powered platforms.

You may observe another approach in the industry too. Vendors that continually force rip and replacement of systems. There are sales motivations for this, but another cause runs deeper...

When you engineer something anew, you usually architect for a minimum viable product and getting to market quickly. Take a tech startup for example: it’s faster to build software as a monolith or a mesh of purely cloud services, than to construct a devops pipeline, platform architecture, and microservices that scale. Taking that MVP route, eventually they will throw away their early work, to redo it at scale, with extensibility, with reliability and economically. This is invisible to customers of SaaS companies, but when translated to packaged-and-sold hardware and software systems, this architecture fetters customers with technical debt and forces rip and replacement inefficiency.

In networking, it’s wiser to sow scale and flexibility into the seeds of your base networking technologies and topologies. Architecting for growth in layers, allows you to scale your rootstock and your core so to speak, evolving today’s investments tomorrow.

Evolvable architecture is how the cloud giants design their software, and happens to be how Juniper designs our portfolio. This is why we did not acquire an SD-WAN solution. And this is why we built SD-WAN backward: we tackled the hard problems first (multi-tenancy, scale, reliability, NFV, etc.), so we could design once and for all, and offer the simplicity of one solution.

Reach for the Clouds

With so many SD-WAN solutions in the market, and mostly built with haste, as you might imagine, the winds of technology change will cause many to snap and topple. They weren’t designed beyond SD-WAN connections for the branch and cloud endpoints.

The wisdom of giant trees would suggest that as you reach for the multicloud, strength lies in swaying and adapting with the winds of change, and evolving and using the strength of the whole.

About Juniper Contrail SD-WAN

Juniper’s newly dubbed Contrail SD-WAN solution and its component parts were designed to inherently secure from within and to scale to support thousands of tenants each with thousands of sites. It was designed where SD-WAN is merely the first act of your transformation story. So it will grow with you to SD-Branch for site virtualization and consolidation, and even incorporate NFV-cloud services into your network service. Of course it’s multicloud-ready, connecting up to the likes of AWS, but just as importantly, it ties right into your core WAN routing today from your campuses and data centers.

Podcast on Soundcloud
Podcast on YouTube

image credit MichaelGaida/pixabay

Seven Deadly Deceptions of Network Automation by James Kelly


Podcast on YouTube

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 piece on 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.”

1. It’s 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.

2. It’s all about automation and technology

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.

3. It’s only about open source

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.

4. It’s incompatible with ITIL, InfoSec, I&O or hardware

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.

5. It’s not obvious where to start

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.

6. It’s all about speed

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 ( 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.

7. It’s all about DevNetOps & NRE

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

Waving the NRE Flag, Live at Open Networking Summit


Next Wednesday at 11:15, Matt Oswalt and I will be speaking on NRE and DevNetOps at the Open Networking Summit. We’ll be joined by Doug Lardo from Riot Games who will share lessons from the front lines. If you happen to be there, please join us. If not, take to Twitter (jk, mo) or comment below on how you see the evolution of the #NRE.

Podcast on Soundcloud
Podcast on YouTube

image credit steampunk/pixabay