Overview
Maybe you’ve heard about the “shift left” in technology infrastructure and development. It’s an important concept, originating in the DevOps world, describing the need to create more dynamic, automated systems. In software development, the cycle is described as moving from left to right – from design to production. When we talk about the shift left, it means implementing more of the business goals, testing, and quality control of an application or a service further to the left in the development process to identify issues or optimizations as early as possible.
For example, you might want more people testing the code or the features earlier in the development process to identify defects or needs – by shifting left. What’s interesting is that the concept of shift left is spreading – it’s now a term being used in cybersecurity implementations. And it’s also starting to become a strategy in networking.
What exactly does it mean to shift left in networking?
One of the challenges for network operations (NetOps) teams is that they often feel they are the “last to know” about an application in development. It’s like: “Here’s this cool new application we have built – can you connect it to the network?” Well, as we know, it’s not that simple. Networks and applications have many dependencies and requirements. With the explosion of complicated applications running across many platforms and clouds, it’s more important than ever to involve networking earlier in the application development process.
The holy grail of the shift left in networking is to build networking functionality directly into an application, making networking part of the software development process itself. Imagine every application being built with defined networking characteristics that can automatically identify and configure network connections once it goes live.
Let’s dive a little deeper and find out how this might happen.
The Rise of NetDevOps: Unifying DevOps & NetOps
The arrival of the cloud ushered in the era of DevOps, which changed the development cycle and how applications were built. The modern DevOps movement is about releasing and testing software faster – typically with the development team seeing the application all the way to production/operations. This is key to the shift left movement as organizations look to speed up application delivery and, ultimately, whatever digital transformation they have in mind.
However, one of the byproducts of the DevOps and cloud revolution is increased demands on NetOps teams. Software needs to be deployed on infrastructure and connected by networks, so NetOps crews are under enormous pressure from CEOs and boards to help enable the transformation of how cloud apps are deployed. NetOps teams are often asked to adapt their infrastructure at the last possible moment to connect an application.
If the modern DevOps movement is about releasing and testing software faster, that means we need to deploy and enable networks faster, along with development. In many places, however, there is still the sense that networks and NetOps teams operate “differently,” because they may not be plugged in directly to the DevOps process.
In interviews with cloud practitioners, we often hear that “networking doesn’t talk to DevOps,” or “DevOps doesn’t understand the network.” Often, the network is something to solve after the fact – once the application is ready to go live.
The way to solve this problem is to shift the network to the left, making it part of the development process. This will also require more integration among NetOps and DevOps teams – a concept referred to as NetDevOps.
Implementing NetDevOps is possible today with existing innovations in network automation technology. But it will take more than just technology. One of the key challenges is convincing teams to work together at the organizational level.
Minding the Gaps: Overcoming Silos & Network Domains
One area where NetDevOps can have enormous benefits is by helping network operations integrate the heterogeneous nature of their environments.
In any given network or organization, teams are equipped with a certain mindset or skills gaps. For example, they might be well versed in traditional enterprise networking and cybersecurity but know nothing about cloud infrastructure. Or the organization might have technical teams with specific backgrounds – for example certified training with one vendor but not another. They might be accustomed to doing things a certain way or working with certain vendors.
According to many network surveys and interviews with users, these cultural and organizational dynamics may present larger barriers to NetDevOps than the technology itself.
SD-WAN & SASE as an Example of Successful Integration
One example of where these gaps and silos are being broken down with new forms of automation can be seen in the Software-Defined Wide-Area Networking (SD-WAN) and Secure Access Service Edge (SASE) market.
SD-WAN has been one of the most popular implementations of Software-Defined Networking (SDN) outside of cloud data centers, and it is now being extended to network security with SASE. SD-WAN is based on the concept of deploying networking software on Commercial Off the Shelf (COTS) hardware, using cloud-managed software for centralized management.
This approach changed the way that enterprises and telecommunications networks implement networking at branches because it enabled a larger number of networks to be set up and managed at scale. But it may have had another effect: It’s shown network operations teams that managing networks can be easier.
This type of software orchestration and automation is now being extended to other areas of the edge, such as Network-as-a-Service (NaaS) and Multi-Cloud Networking (MCN), whereby network managers can use software-defined networking and cloud infrastructure to connect any network or service.
This networking automation process has just started and is part of a long cycle of building more programmable networks. In the first stage of this evolution, the SD-WAN movement introduced elements of the shift left: It was focused on how services could be deployed more quickly over a network using software, rather than focusing on manual configuration of hardware devices. SD-WAN makes generous use of APIs, and it is a “service first” approach to networking. For example, an SD-WAN platform can be used to deploy new cybersecurity services, such as Distributed Denial of Service (DDoS) protection or malware filtering, directly into the network.
Pursuing the Cloud Automation Model
Another example of shifting networking left can be seen in cloud operations and services. The SDN and Infrastructure as Code (IaC) movement took root in cloud hyperscale and webscale data centers, where large amounts of infrastructure needed to be connected on demand, driven by software automation. After all, it’s not possible to manually configure hundreds of servers on demand – they need to be connected by automation.
Just as SD-WAN made it easier to deploy hundreds of branches without truck rolls or manual configuration of routers, moving networking functionality further into the development process by implementing techniques like infrastructure as code will enable automation for any network or application.
In a deeper shift left for networking, automation and orchestration will be used more pervasively to connect any data center, network, or cloud service. This will enable any software applications, devices, and infrastructure to talk to each other – whether they are based in a more modern cloud architecture or hosted on traditional infrastructure.
Leveraging CI/CD Tooling for Network Automation
If the goal of the shift left for networking is to build network automation into both the development process and operational models of an organization, it will require deeper integration with the CI/CD framework. If the code is going to understand the network, the network needs to understand the code.
Building IaC by shifting left looks a lot like cloud infrastructure automation, in which an application in the cloud can understand its infrastructure needs and be programmed to create more infrastructure resources on demand without the need for humans. An example might be a scale-out server in the cloud that responds to an application’s requests for more compute resources using YAML or other automation tools.
That’s great, but what is the technical process for doing this? What’s needed is for the industry to adopt the same tools, processes, and operations that application developers use every day to build, test, and deploy application updates. Certain approaches for network automation already exist – such as leveraging APIs and REST/RPC interfaces. Further automation requires building these network automation processes into the DevOps and CI/CD framework, including using tools and processes for testing, validating, and implementing changes.
Let’s dive into each of these requirements for the shift left in networking.
The key tools and processes for cloud networking automation will be similar to other models for DevOps automation. They will include:
Use of Git Repositories for Configuration Source of Truth
Pipelines for Ensuring a Consistent, Repeatable Testing & Deployment
Tools for Instrumentation & Automation & Orchestration
Git to the Source of Truth
One of the key tools of the DevOps continuous delivery model is Git – a repository of open-source software where files and their versions can be kept, managed, and controlled. This enables teams to work collaboratively on software projects with nearly instantaneous, high-performance access to the code. The origins of Git come from Linux, where it is used to store versions and software improvements to the Linux kernel.
The Git model has of course expanded to other commercial offerings such as GitHub and GitLab, but the notion is the same – build a collaborative file-sharing and software system that can serve as the “source of truth” of all code changes and contributions. The key is the Git approach builds a highly scalable means to track all changes to code, enabling large projects to be managed by distributed teams.
Building a Pipeline for Testing & Validation
One of the keys to any form of automation is testing. Software is not ready for production until it is tested. The new continuous DevOps software development lifecycle therefore demands that it be constantly tested.
Code automation lifecycles require a methodology and pipeline to test the software builds as they are introduced in order to validate current operation. Testing can include automated testing as well as manual testing. But the testing system should be thorough and built directly into the software development process, including tests of versions, software installations, and applications dependencies. This is another form of shift left, by implementing testing earlier in the software development cycle. Research from the Ponemon Institute has shown that shifting testing to earlier in the software development cycle can save enormous amounts of money and increase feature velocity.
This image shows how testing can be injected into every stage of the CI/CD pipeline.
Leveraging Tooling & Instrumentation for Automation & Orchestration
Automation is not possible without instrumentation. The simplest example is how an autopilot functions on a plane. The autopilot would not work without real-time feedback on the airspeed, location, altitude, wind direction, and flap positions of the plane. Monitoring tools and network telemetry are needed to deliver feedback on the state of the network automation, an approach known as closed-loop monitoring.
Key functions for any network automation system include monitoring, analytics, and configuration management. One example provided by this is the capability to define golden config standards that can be enforced automatically throughout an organization. Another example would be the notion of programming the network with intent to monitor performance and network analytics and alter network configurations based on changes in the network needs.
As networking shifts left, the system will require a strong combination of monitoring, analytics, and configuration tools to respond to changing demands and network needs.
The Right Tools for the Job: Blend of DevOps Processes & Low-Code Tooling
We have identified some high-level needs for strategic implementation of NetDevOps and the value of shifting network automation to the left. In order to deliver on this promise, practitioners from across the organization need the ability to use technical tools that align with their capabilities and strengths.
One driving force of integrating NetOps with DevOps will be the ability for team members to adopt easy-to-use tools that make their lives easier. Just as cloud automation and DevOps automation tools leverage Terraform which has made it easier to scale cloud operations by enabling Infrastructure as Code, NetDevOps tools will speed up the process of shifting networking to the left.
These automation tools will enable networks to shift left by leveraging existing technologies such as APIs and data federation, as well as no-code and low-code automation platforms to help operations teams speed up this process. Let’s take a quick look at how this works.
Driving Automation with APIs, Integration, & Data Federation
APIs and data federation – already a key part of networking automations in cloud infrastructure as well as the enterprise – will play a large role in the shift left for networking.
For example, APIs are the standard software hooks provided by individual networking vendors and Original Equipment Manufacturers (OEMs) that allow applications and networking devices to talk to one another. They have been a crucial element of data center and SD-WAN virtualization, and they will become increasingly important to automate hybrid cloud networking as we shift further left.
APIs can enable any platform – hardware or software – to expose software connectivity in the form of code, enabling automation. Data APIs such as GNMI can be used to provide a steady stream of network telemetry and state information.
Data translation and data federation are other key areas to enabling shift left and automation by providing the capability to transform data from one schema to another. This means that information about network configuration and capabilities can be exchanged easily using a standardized interface such as JSON – the de facto standard representation of APIs.
With the use of data federation and APIs, information about networking systems and capabilities can be made available in real time, enabling appications to connect and use networking infrastructure on demand, driven by software.
A Blend of DevOps with Low-Code Tooling Will be Key for Network Infrastructure as Code
As networking and DevOps teams look to build their NetDevOps environment, additional software techniques and platforms will be needed. Approaches that provide tools and capabilities that reflect the diversity of the team’s skill sets and can blend the use of DevOps processes and low code will be key, as they can speed up integrations using a standardized approach.
Successful teams will incorporate tools that enable subject matter experts to be as efficient as possible – for network engineers, that may come in the form of low-code tools that the engineers can use to quickly model complex network engineering logic.
Low-code tools can help connect networks to new application environments without the need for any specific programming knowledge. They will enable any operations or infrastructure professional to connect applications, infrastructure, and networks without development skills. Such automation platforms for networks will enable a larger number of network experts to incorporate their subject matter expertise in the infrastructure automation solution.
For DevOps engineers, the ideal tools will work natively with their existing CI/CD pipeline and systems, by exposing network capabilities and integrating with their toolchain to integrate networking with their existing development infrastructure.
In both cases, team members can use Network Infrastructure as Code techniques to accelerate the adoption of automation across the business.
The Benefits of Network Infrastructure as Code
For both audiences – the network subject matter experts and the DevOps engineers – the benefits of implementing a Network Infrastructure as Code are significant.
- IaC enables engineering, maintenance, and operations teams to use a consistent set of infrastructure tools (repos, pipelines) and processes for network creation and operations.
- These tools accommodate differences in technologies, systems, etc., but provide a common framework for network creation, operation, and maintenance.
- IaC framework addresses common process needs while providing hooks for technology and implementation-specific tools, processes, testing, etc.
- Process becomes software-centric instead of document/manual centric.
- Common IaC eliminates parallel redundant activities for engineering and operations.
- IaC becomes a resource for versioning, disaster recovery, testing, upgrades, etc.
- Primary Business Outcomes = increased velocity, reduced manual effort, improved quality.
How Itential Is Enabling Infrastructure as Code for Network Automation
Itential is on the forefront of enabling Network Infrastructure as Code. The Itential Automation Platform was designed to be used by developers and network engineers without specific engineering knowledge or code-writing capabilities. Its advanced integration capabilities allow for easy integration with any IT system, network technology, orchestration tools, and custom-built scripts for end-to-end network automation and easy integration with CI/CD pipelines and toolchains.
Some examples of how Itential can enable this transformation, which is built on the fundamental operational model that integrates networking, DevOps, and IT:
NetOps Infrastructure as Code via Automation Workflows
NetOps teams can design, build and publish automations using the Itential Automation Platform’s low-code and no-code capabilities workflow capabilities.
NetDevOps Infrastructure as Code via CI/CD Pipelines
Developers can incorporate pipeline calls to the Itential Automation Platform to execute automated/ orchestrated network changes during testing and deployment phases.
Additionally, Itential assets like workflows, templates, forms, and data transformation can be managed via CI/CD pipelines for code control, versioning, and testing of network automations and orchestrations.
Keys to the Successful Shift Left for Networking
Given the benefits and processes we have outlined for shifting network operations to the left, you might ask: Why is it so hard? And how can it be executed effectively? This might come down to several considerations:
Cultural
Motivating DevOps and NetOps teams to work together by demonstrating the potential of integrated automation tools.
Organizational
The importance of integrating network automation with the CI/CD process by developing single source of truth, automated testing and validation, and instrumentation.
Managerial
Getting business leaders behind the goal of shifting left with the potential to save time and costs.
As you can see, these goals have something for everybody: After all, who doesn’t like eliminating tedious, repetitive tasks and saving costs? NetOps and DevOps professionals alike are interested in ways to simplify and streamline networking operations to save on time and avoid mistakes.
Shifting left and building IaC can enable rapid transformation in an organization, and this should be the driving goal of any type of integration process. With NetOps and DevOps teams working together, the intent, policy, and needs of the networking infrastructure can become mostly invisible to most users, which is the ultimate goal of automation.
Adopting Network Automation as an Operational Model
Networking has taken steps toward enabling more automation in an organization’s operations, but much more work needs to be done. Organizations have moved toward tools such as scripts or custom integrations, but this is only a first step toward end-to-end full-process automation, which will remove manual activities and allow engineers to focus on larger problems.
This shift left for networks requires software capabilities that enable anyone – DevOps engineers, network subject matter experts, and operations engineers – to participate in creating automations using standardized tools. To enable a true shift left for networking, automation will have to be adopted as an operational model.
Adapting Traditional Infrastructure
Another key to the success of IaC and shift left will be testing an organization’s capability to use software platforms to bridge the gap between diverse devices, software, infrastructure, and resources. The cloud operational model is enticing, but the reality is that most enterprises use a blend of traditional and cloud resources. The typical enterprise needs to leverage its own networking and compute assets. Recent developments in edge compute advocate using existing equipment to deliver more compute power to organizations.
To enable the shift left, the industry will need tools and platforms that can help them automate and program any devices – including traditional servers and networking devices. With tools such as APIs, low-code or no-code automations, and programmable models like JSON, and APIs, it’s possible to print any environment into the world of IaC using software.
How Do We Move Humans from CLI to APIs?
Bringing IaC into the fold is part of automation of the operations of any organization. Organizations will first have to examine where repetitive tasks are occurring and how they can be replaced with automation, such as in the case of our banking example. Networking isn’t any different – the process will involve identifying where teams of humans are programming networks with post-it notes, Excel sheets, and CLI scripts. These manual, human-based processes need to be replaced with low-code or no-code automations – for example, using APIs to program network changes based on intent and development specifications.
Requirements to Enable the Shift Left
Examine Where Repetitive Tasks Are & How They Can Be Replaced with Automation
Tools & Platforms to Help Automate & Program Any Devices – Including Traditional Servers & Networking Devices
Enable Anyone to Participate in Creating Automations, Using Standardized Tools
The Ultimate Goal of NetDevOps
Take network programmability into the software development cycle. The key steps would be to automate configuration and orchestration with APIs; build in automated instrumentation and monitoring that can drive closed-loop automation; and program intent and policy into the network depending on the application’s needs.
Cultural Change is Required
As we have mentioned, one of the key barriers to these goals is cultural – changing the way some teams do things. This may require new training and convincing them that change is necessary. Those who come from the networking world may be familiar with some or all of the elements of NetOps, but not DevOps; and for those from DevOps, the reverse may be true. But both efforts do seek the same goal: building better automation for the sake of efficiency and performance.
The first hurdle, as always, is the humans. The management teams – including CIOs, software and DevOps teams, and NetOps mavens – need to start speaking the same language and having the same goals.
This may sound outlandish, but it is not. Management teams around the world are already aware of the challenges of bringing their silos together, especially NetOps and DevOps teams. The key to expanding networks to IaC is to get all the teams on the same page during the development cycle – shifting to the left as soon as possible.
Conclusion
Networking is entering an exciting new era of development in which it becomes part of the development fabric for software and applications. This innovative approach to networking will require a significant change in thinking about how networking infrastructure is connected to modern applications.
The shift left for networking has the potential to make life easier for networking managers and application developers alike, by plugging networking features, control, and management directly into the development process. The key to success will be the capability to integrate this new source of network innovation without ripping and replacing existing infrastructure. With the expanded availability of tools such as APIs, data federation, and NetDevOps platforms, it’s now possible to shift left using automation and integration that can leverage the installed base, as well as take advantage of emerging cloud-native networking platforms. With this approach, the shift left for networking can be used to build a bridge from traditional networking infrastructure to the future.
Remember to avoid:
- High learning curves and complex environments that make sophisticated automation prohibitively difficult.
- Limited or proprietary tools that limit your network infrastructure now and in the future.
- Red flags: paid integrations, generic IT or BPA focus, a hard-coded data model, and a lack of API support.
The right solution will enable scale and efficiency by integrating with your infrastructure and making automation easy, powering up your network team for the future.
