While NetOps can be a simple abbreviation for network operations, it is also a discipline network teams can use to treat infrastructure as code, or IaC. IaC creates a path for network and security teams to enable DevOps and take on network automation using continuous integration and continuous development.
Continuous integration and continuous development define the new frontier in orchestration and automation. Imagine if the Agile methodology extended beyond the software development lifecycle (SDLC) to promote an application from testing to quality assurance or from QA to production. Automation can make the necessary network, storage and security appliance changes that permit an application to provide services to users.
A look into DevOps and Agile
DevOps is a concept built around the Agile software development model. It takes the traditional Waterfall development methodology and turns it on its head. Waterfall is a straightforward methodology that moves sequentially from requirements to design, implementation, testing and deployment -- followed by equally important maintenance cycles. The main problem with Waterfall, however, is it is slow to market, and the end product is unusable until deployed. Many such systems can take months and even years to develop.
Agile, on the other hand, develops capabilities over time, and basic functionality can appear in just a few weeks. Its iterative sprints enable rapid prototyping, and Agile delivers capabilities much faster than earlier models.
While DevOps creates an environment for continuous development, its flaw is that software needs real-world deployment via infrastructure, which has remained significantly manual and Waterfall in nature. The infrastructure may be virtual, deployed in a cloud or physically, but it still needs to exist to support an application and access the data required.
NetOps and service chaining
Waterfall systems typically use static infrastructure, and the application delivery chain involves all aspects of a static infrastructure modification. This work can be automated, but it is often disjointed -- i.e., automating the deployment in the data center, firing off requests to add firewall or load-balancer rules. Each team does its own thing and automates its own processes, but the service becomes available only when the last item in a relatively long service chain is finished.
NetOps, on the other hand, defines the use of a more Agile methodology and looks at all components involved. This process is called service chaining, which adds software-defined networking capabilities in a specific sequence to automate traffic flow between services in a virtual network. Service chaining can deliver an application all at once, along with the appropriate network, network services and security needed to promote workloads from test/dev to QA to production.
This type of automation can provide templated approaches. These templates lay the foundation of code the service chain will use for the full IT delivery chain, across the set of DevOps SDLC processes.
The process of a system delivering end-to-end services is often called service orchestration. Some organizations are hesitant to engage in this principle, arguing that automation could be a security nightmare, such as someone using automation against an enterprise. This perspective is shortsighted, as any proper implementation would not permit manual firing of this type of service outside of an approved change control -- with an existing requirement for backing out the change, also through automation.
Traditional Waterfall-based IT processes involve coordination with multiple teams. Typically, enterprise server, network and security teams must work together to deliver a new service, but they often don't play well together. Application and server teams usually propose a new service and throw it to the network team to design any needed subnets, load balancing, encryption and firewalls. When the networking group is done, it's the security team's turn.
In my experience, one of our clients was implementing DevOps for web applications. The server team created an automation system that could spin up resources for a full SDLC environment, which included workloads for a sandbox, test/dev, QA and production environment. The development community was ecstatic. Because network and security were out of scope, however, the system generated emails to the teams that manage the load balancing, network address translation and firewall.
It has been said that automating a component of a service chain achieves nothing other than moving a bottleneck. In reality, it's much worse than that. Because the client had created an Agile work environment for developers and the server team didn't track the external work done by other teams, significant problems emerged. Their automation tore down unneeded workloads, but it didn't track the network and security components used by those workloads. Over a couple of years, the No. 1 problem for the client became orphaned firewall rules.
How to secure applications in Agile
These infrastructure and DevOps concepts are ideal for insertion into an Agile system. With the level of automation possible, security testing can become part of the process and provide interim feedback. This can occur from sprint to sprint rather than waiting until the end of a project when delivery commitments have already been made. In Waterfall systems, the security and testing community are often the ones holding up deployment.
The bottom line is operations needs to take a holistic approach. In a DevOps world, security and networking need to be part of the solution. A new term being considered includes some version of DevNetSecOps abbreviations, which drives a more comprehensive way for developers, networking teams and security personnel to work together.