How Itential’s Integrated Approach to CI/CD Enables NetDevOps

In the quest to accelerate application deployment, development teams are investigating ways to incorporate more sophisticated networking into their CI/CD pipelines. This enables them to move from a siloed model, where DevOps and NetOps activities were performed by different teams or tools, toward an integrated NetDevOps approach.

CI/CD, or continuous integration and continuous delivery, is one of the hallmarks of DevOps – mature application development teams leverage pipelines to make development both faster and less risky. When it comes to networking and NetDevOps, though, the “friendliness” or accessibility and ease of use of CI/CD tooling varies between different network domains. For example, cloud is more mature in this area than other networking domains, and cloud teams are often able to leverage tooling that is functional and easy to use. When you look at physical networking domains, though, such as traditional data center infrastructure, the tooling is usually less mature and more difficult to use effectively.

Furthermore, networks and network services present some unique challenges when compared to traditional CI/CD deployment concepts. An application is deployed to a version in a relatively static way, while network services (VPNs, SD-WAN branches, etc.) are a lot more dynamic. This changes the way you roll these services out when looking to integrate with a pipeline.

Today’s Model: NetDevOps-Lite

Today, most IT organizations looking to incorporate networking into their pipelines have a process that looks something like this:

The application developers themselves leverage a mature pipeline, but it hasn’t been fully integrated with network services. The first few steps will look much like traditional CI/CD deployment: a developer will develop their branch, make a merge request, get it approved, and then it will be deployed to production. However, unlike most applications, those that require network services will have additional steps outside the pipeline before the application is accessible to an end user.

In these environments, once a build has reached the deploy stage, there is a set of network services that need to be provisioned – the pipeline will generate tickets for activities such as creating firewall rules, creating VPNs, adding DNS records, or anything else that’s required for the application to function. The tickets will then follow the same process as any other IT ticket in the organization: creating a task that enters someone’s queue and must be completed manually. In this model, the organization’s ability to truly leverage their pipeline for networking is limited – even with a mature, automated pipeline, waiting for manual tickets will cause delays or even introduce potential for human error.

It’s only after the network services steps are complete (i.e., tickets are closed) that development can be considered complete. There is a huge opportunity here for those network-specific activities to be integrated into the pipeline itself. The challenge is figuring out how to do this in a way that makes sense.

Let’s start by examining CI/CD as it’s traditionally laid out. You have five categories of services that are well-defined and generally agreed upon:

• Source and Version Control: Used to manage and track software code changes.
• Continuous Integration and Deployment (CI/CD): Used to automate software build and unit test processes.
• Infrastructure Provisioning: Used to provision cloud and infrastructure.
• Containerization and Container Orchestration: Used to manage and coordinate containers and pods.
• Monitoring: Used to manage health, performance, and reliability of processes.

To incorporate networking with DevOps practices and pipelines, we need another category with its own defined tooling and requirements so that network services can be consumed by development teams via their pipelines in a consistent manner. The Itential model defines the Network Services category of CI/CD services and provides a way for all networking activities to fit into the same microservices model that pipeline developers are accustomed to.

The Itential Model: NetDevOps

Here at Itential, we focus a lot on the ecosystem model for network infrastructure and thinking about how we operate within the context of this world of consumers, domains, network technologies, and systems. Because of our layered, integrated approach to our platform architecture, any piece of functionality that’s provided through our platform can be exposed as a microservice. And this isn’t just limited to the workflows and Pre-Builts that our users leverage to build automations directly – any service that’s available through the Itential Automation Platform and any service that is exposed to Itential through a southbound integration can then be exposed northbound.

This means all of the following network services can be consumed via pipeline:

• Automation workflows
• Itential Pre-Builts: Automations, Transformations, and Integrations
• Configuration management and life cycle management capabilities
  • Reading or changing backups and config, defining compliance rules, running compliance checks, etc.
• Data transformations
• Automation Catalogue (the library of custom assets created by users within the organization for use within Itential)
• Functionality from systems integrated southbound with Itential, such as:
  • SD-WAN controllers
  • Network controllers
  • Cloud systems
• Automation assets such as Python scripts, Ansible Playbooks, and Terraform Plans

This enables teams and organizations to adopt a new model for approaching NetDevOps and CI/CD for networking – one with no stops, no delays, and no manual steps.

Networking concerns can be incorporated further left in the above development cycle. This allows Itential users to, for example, make a function to generate a configuration at the beginning of the cycle, or to use a function during the testing phase that also incorporates firewall needs, load balancer needs, or any other network-specific requirements.

This way, instead of stopping between a deploy stage and an actual go-live-to-user stage, the pipeline ensures all payloads that are required for the necessary network changes are generated. Then, the Itential Automation Platform server deploys changes in a secure way with the assurance of pre-checks, post-checks, and other validation steps available to be exposed as microservices. Every part of the development process, networking or otherwise, becomes part of the same pipeline, ensuring the speed, efficiency, and consistency that DevOps has pioneered is not affected by whether or not an application requires network services. This is extremely important – networks are continuously evolving, and modern applications almost always have network-specific requirements.

As networking teams become more accustomed to DevOps processes and CI/CD tooling, the field will see further merging of the best practices from both networking and application development teams. This will allow networking teams to participate in the same development cycle as the rest of IT without compromising their ability to manage the network at any level, keeping the practices and methods they need while adopting tried and true improvements from the DevOps side. By building toward NetDevOps in this way, teams and organizations will be set up for success in the evolving world of networking and IT infrastructure as a whole.

To see the Itential approach in action, check out my recent webinar to see how Itential can expose and provide network automation and orchestration functionality to CI/CD pipelines.