Micro Focus is now part of OpenText. Learn more >

You are here

You are here

How to succeed with network automation: Experimentation

public://pictures/matt_oswalt.jpeg
Matt Oswalt Lead Architect for Automation, Juniper Networks
 

In the race to deploy network automation tools, organizations too often view maintenance of these systems as an afterthought. And they view automation as a big, one-time project they can implement and be done with, rather than a series of learned experiences over time.

The problem is heightened by employee turnover and lack of internal structure, particularly in smaller companies. It is critical to instill a culture that encourages operators to continuously evaluate automation processes by regularly testing them. The onus is also on IT operations leaders to ensure that staff are being properly trained and constantly learning new skills.

Network automation—when done correctly—requires quite a bit of care and maintenance over the long term, and organizations should start by ensuring that they have the right culture in place to enable this. Here's the why and how. 

Focus on your use case

Every organization will implement automation in a different way. Asking, “How do I implement automation?” is like asking, “How do I write a Python program?” The answer depends on what your organization is trying to accomplish. The selection of network automation tools and the way you'll use them will be based on your situation and the constraints under which your automation initiative operates.

The benefit of most automation tools is that they offer an abstraction layer that keeps their users from having to worry about common, low-level details. This is true of simple command-line tools as well as complex software-defined network systems. Technology providers are constantly thinking about how to add value by creating abstractions where that makes sense, but these products and projects are informed primarily by your particular needs.

As a customer, you have an opportunity to push the automation landscape in a direction that works for you by being clear about your use case. This has always been true to a degree, since technology providers are interested in what’s most important to their customers. However, the rise of open-source infrastructure software is shortening that communication path, making it easier than ever for customers to influence the direction that technology providers take with their automation offerings.

That's why it’s crucial that you clearly communicate what your needs are. It’s not enough to simply want to automate. You must have a detailed understanding of current workflows and processes, as well as specific areas where network automation can provide value in both the short and long term.

Shorten feedback cycles

Many enterprise technology projects are planned over months or years. Whether it’s planning a new data center build or simply setting up a new application, feedback cycles in the enterprise aren’t known for brevity.

For automation to mature in the right way, organizations must learn to gather feedback and react to it faster. A big hurdle to this is a desire to boil the ocean when it comes to automation. When you do automation correctly, it can be boring in the short term, but stay focused on the easier tasks, such as provisioning or troubleshooting. The lessons learned while simpler automation is in place can't be taught, and they will form an important foundation on which you'll build more complicated network automation workflows.

This early stage is critical to your organization’s long-term view of automation. Inevitably, you'll face growing pains, but if you can avoid the boil-the-ocean syndrome, you'll help to ensure that you're developing high-quality automation workflows.

This is where the phrase “fail fast” has the most impact. Many organizations tend to shy away from such terms, writing them off as something only hyper-scalers can do. But hyper-scale companies aren’t looking for ways to fail. Rather, they establish short feedback cycles so that when they do experience a failure, it’s contained, and they can learn from it.

Once your organization has established some muscle memory by starting small, it can take the time to look back, analyze how well things are working, and optimize accordingly.

Create a culture of experimentation

Because automation is so hyper-contextual, there’s no way for customers to buy their way into it. No technology provider can offer a single SKU you can click on and magically get automation. But they do offer tools that target specific uses, and these are tremendously helpful for solving some of the lower-level grunt work. But no matter what, it takes people to hold it all together.

The most automation-healthy culture is one of experimentation. Infrastructure engineers need to build systems quickly. However, the culture tends to contradict what’s usually required to run a stable network. After all, if the network isn’t working, nothing is. This history tends to keep organizations from treating the network like a science project, and rightly so.

Developers solved this problem years ago. Rather than build software over the course of months or years and release updates in one big bundle, they use processes such as continuous integration (CI) and continuous delivery (CD) to give structure to this push to production. CI/CD pipelines let developers push code through a series of predefined tests to ensure that the code passes muster.

Infrastructure engineers must build a similar pipeline for making automated changes. Before and after each automated change, you should conduct automated tests to make sure that your infrastructure is delivering the services the business requires. Because the tests are automated, engineers can quickly make changes, confident that they won’t disrupt services running on top of the infrastructure they’re automating.

Finally, it’s useful to have people in place who will focus on slowly growing and maintaining the network automation tooling within your organization. This is not to say that you can outsource automation to a development team; on the contrary, network automation engineers should have established infrastructure operations experience. But by dedicating engineers to maintaining the network CI/CD pipeline, your organization can reap the benefits of stable infrastructure operations, as well as a quickly iterating automation stack.

Start small and expect a few setbacks

Network automation isn’t an overnight “implement and it’s done” undertaking; it’s a long, steady process that requires a culture of experimentation and consistent feedback. Setbacks are inevitable, but if you prioritize feedback and establish a culture that allows automation muscle memory to emerge, you'll be well on your way to enabling teams to tackle bigger projects and greater endeavors.

Keep learning

Read more articles about: Enterprise ITIT Ops