Evolving the Operational Mindset to Enable Self-Service Networking

We all have mindsets. These are the common patterns wired into our brain for processing things. Often, if you want to make big changes, you need to change a mindset.

Change to an organization’s mindset is needed to drive automation. If you have a flower shop that’s driven by tele-sales, that means a process of humans taking orders over the phone. If you have an online flower shop, it’s driven by customers putting their own orders into a website. It’s more automated. Which is more efficient?

How the Platform Can Drive Automation

In networking, more automation will mean thinking about how to build platforms that can be used to enable self-service (the online flower shop). We’ve been exploring how platform engineering principles can be applied to networking and infrastructure to implement automation.

To introduce more automation, you need to evolve the operations mindset. The organization must think about which processes and configurations can be addressed to introduce more automation.

For example, in a manual mindset, workers fill out tickets, which are sent to network operations, which then probably have to manually address these tickets for changes. I need a load balancer! Fill out a ticket! Stat!

A great example of how changing the operational mindset can drive automation is what happened in the software-defined wide-area networking (SD-WAN) market. The initial use case of SD-WAN was branch office routers. For branch office routers, the old process was:

1. Order a router.
2. Bring a human in to configure one single router.
3. Connect it to the network.

The introduction of SD-WAN devices meant that these routers could be configured with automation from the cloud using a web interface. The new process was:

1. Drop-ship the devices to multiple locations.
2. Press a button to configure many routers and connect them, all at once, using a template.

That’s a new process as well as a new automation introduced with software abstraction — driven by changes to the operational mindset.

In the SD-WAN example, you can’t really address the automation unless the organization is thinking about changing its mindset — overhauling the entire process.

Changes to the mindset involve questions like, what is the ideal process we’d like to have? And how do we automate that? For example — what if there was a way for the worker to choose a load balancer themselves, from a preset arrangement of load balancers? This is the approach advocated in the cloud world, using a platform engineering approach. Platform engineering is used to reduce the variables and complexity by limiting the choices that people have.

In another example, the webscale world moved development to a centralized platform using continuous integration and continuous delivery (CI/CD). This was created by an operational mindset built around the speed of development and deployment. All the code and changes were plugged into a platform, which could be automated — replacing the code flying around the organization on people’s laptops. The appeal of cloud-native and CI/CD isn’t just economy of scale — it’s about getting software and services to market faster.

Networking is often perceived as being behind the “legacy” infrastructure in a cloud-native world, but that is primarily due to more complexity and manual processes. We are still manually configuring networks because we are afraid of the complexity of enabling the machines to do it. To automate networks and infrastructure, we need to reduce complexity and present the simple options to the users in an abstracted software interface — a platform.

Let’s go back to the ticket example. A worker is putting in a ticket request because they don’t know how to create a load balancer (or any other networking feature) in the infrastructure. That’s probably because the networking professional must undergo a series of complex steps to qualify and configure the load balancer. But what if you picked only two types of load balancers, and standardized on that? Then it’s more likely to be automated.

Imagine if all networking features were standardized and presented as a “service” that could be selected on a platform. This is the concept of platform engineering for networking.

To deliver platform engineering for infrastructure, organizations will need to think about how to adjust their mindset to find areas where they can consolidate several operations at once. They need a place in which to standardize the deployment of infrastructure and services for their constituents, the people building the applications and services for end users.

Keys to success include the following:

• Deploying standardized infrastructure, abstracted management, and driving continuous operations with software-based automation.
• Moving to an “API-first” mindset, rather than depending on CLIs and proprietary management models.
• Delivering services and infrastructure using a self-service model.

You can read more about it in the white paper we developed with Itential, Applying Platform Engineering Principles to Networking and Infrastructure.