NetDevOps, as the name suggests, brings DevOps to the networking realm. For audiences not familiar with the original “DevOps” term, it is an agile software development methodology that brings development (Dev) and operations (Ops) teams together. In practice, it is a set of tools and processes which, when used together, result in delivery of better quality software with a shortened systems development life cycle. In this article, we are going to cover some of those practices in the context of networking.
Why NetDevOps?
At first, DevOps principles were widely adopted by system administrators. The adoption heavily accelerated together with the cloud migration trend. Companies started to notice the massive value brought by DevOps and that the traditional approach to networking became a bottleneck that slowed the workflow in numerous organizations.
Among the most common problems, there are:
- Monolithic architecture - In cloud networking, when the components are tightly coupled with each other, a single change to the network can cause downtime for the entire network, together with all applications that reside inside it. Because of that, network changes are considered high risk and it usually takes a lot of time to have them investigated, approved and implemented. Even in spite of the scrupulous verification the changes go through, thanks to a monolith’s complexity, problems still occur.
- Lack of automation – Especially in the case of new projects, manual configuration of network infrastructure can significantly delay product delivery. Very often the majority of work is repetitive and performing the same tedious tasks over and over is not only a lengthy process but also prone to human errors.
- Ineffective testing – Every network requires a lot of testing once it gets deployed and configured. Each time a new project takes off, network engineers go through several checks like interfaces’ status, routing table entries’ presence, ICMP echo request tests, common network services availability, etc. It is easy to forget about one thing that may be critical when doing it manually and it takes a great amount of time.
- Organizational silos – Network operations teams are rarely integrated, e.g. with software development teams, and are usually the only people in the organization with permissions to deploy and configure any networking components. This results in ineffective collaboration and extended waiting times for even the simplest network changes. Everyone has experienced awaiting a single ACL entry for ages which was a showstopper for the entire project.
- Limited observability and feedback – In the traditional approach to networking, it was certainly possible to monitor networks, with better or worse results. However, it was common that some devices or services would not be monitored due to oversight. Often the coverage of configured polls and metrics was not enough and did not provide a holistic view of the entire environment.
To address many of the challenges faced by network management, NetDevOps has been introduced.
NetDevOps practices
Diving deeper into NetDevOps, let’s cover its key components.
Network segmentation
The problems of a monolithic architecture have been described earlier in the article. The answer to this is extensive network segmentation, i.e. breaking down the network into smaller segments loosely coupled with each other or not coupled with each other at all, just like in large ISP networks. The lesser the number of dependencies between different networks, the lesser the impact caused by changes to them. Similarly to the microservices trend in software engineering, the objective is to design modular network architectures that are easy to scale and do not get too complex. This approach is favored by cloud services providers, hence in the cloud this objective is straightforward to achieve. When deploying a virtual network in the cloud, do not put all your applications inside it. Instead, create a separate virtual network for each application and environment. You can still peer them if required, but network changes like IP addressing, DNS or Internet access inside a virtual network will not impact other applications.
Network as Code
Similarly to cloud infrastructure or server operating systems, automation has not spared networks. Popular Infrastructure as Code (IaC) and Configuration as Code (CaC) tools like Terraform or Ansible can be leveraged to automate networking components, which is often referred to as Network as Code. If one is interested in what the differences between IaC and CaC are, we encourage them to read Configuration as Code — moving in the right direction.
For those not familiar with these kinds of tools, they provision and manage IT infrastructure in general using machine-readable definition files. They most often employ a declarative rather than imperative approach, which means you build templates describing the infrastructure’s desired state. If you are building cloud networks utilizing cloud-native networking services, IaC is the obvious choice and you can pick cloud-specific tools like CloudFormation (AWS) and ARM Templates (Azure) or cross-platform third-party tools like Terraform. If you are building on-premises networks or utilize third-party VM-based network appliances in the cloud, you can still manage their configuration through code with CaC tools like Ansible, since most modern network operating systems have an open API.
All of this enables repeatable and consistent network environment implementations, with little effort to replace key parameters (like IP addressing) within the template. It saves substantial amounts of time and greatly reduces the potential for human error. When building a new architecture, very often you can reuse snippets of code from your other deployments, which again makes things easier and faster. Another big advantage of keeping your network as code is the possibility of utilizing a distributed version control system like Git. You can put your configuration templates on a centralized repository and version it anytime you need to implement any changes. This can serve as a single point of truth (see Source of Truth vs. Source of Intent in network automation for more details) for your entire network setup and allow your team to track changes and collaborate on the code.
CI/CD
CI/CD stands for Continuous Integration/ Continuous Delivery (or Deployment). This concept allows you to set up automated workflows that step by step will deploy your code to production. As mentioned earlier, network changes require extensive testing and very often some approvals. CI/CD helps to speed up the entire process thanks to so-called “pipelines”. The idea is simple - every time you commit any changes to your codebase in a centralized repository like GitHub, it enters the pipeline and user-defined workflows are triggered. This pairs very well with Network as Code templates.
CI/CD is made up of:
- Continuous Integration – In this step your template code gets scanned and validated. There are multiple open-source frameworks which can check the code for linting, security and other best practices. At this stage you can also define your own unit and integration tests.
- Continuous Delivery – In this step the network is deployed to a test or staging environment and some additional end-to-end tests can be run. Those can be simple ICMP echo request tests to check connectivity to some hosts. More refined tests can be used to validate desired connectivity and routing. At this stage it is also possible to run some load and performance tests. If all the tests are passed, manual approval is required to deploy the network to production.
- Continuous Deployment – This is almost the exact same thing as Continuous Delivery but in this case, manual approval is not required and the network is automatically deployed once all tests are passed.
Change of culture
Successful adoption of NetDevOps is not only about the technology. It is crucial to actually change the company’s organizational structure and bridge the gap between development and operations teams. Decentralized teams should be built in a way that ensures end-to-end ownership and responsibility over the entire application or product they are working on, instead of going through multiple handoffs in order to get the code to production. In the context of networking, building centralized network operations teams that handle all decision-making related to networks must be avoided. A NetDevOps-compliant team should be capable of provisioning a network environment for their application and, for instance, implementing a firewall security policy for that on their own (approval process can be incorporated into the automated workflow).
Conclusion
Following NetDevOps practices is just an element of a wider adoption of DevOps principles in the entire software life cycle. However, it is essential in order to experience the full benefit of this philosophy. NetDevOps on its own brings a lot of value to modern networking and compared to traditional ways of dealing with networks, it allows delivery of more reliable environments at a much higher pace. We expect to see NetDevOps grow in popularity in the upcoming years, and see more professionals focusing on this specific area.
