New Design Mindset
DevOps Configuring and Managing Networks More Quickly
Returning to the beginning of this short series on network transformation, the first point is network engineering needs to be driven by business needs. In fact, the point the second post in this series made is the network is only a commodity at the device level; where networks add value is in solving business problems. In the third post, I pointed out that to reach this goal, the design of the network must be focused on solving problems, rather than meeting requirements, and needs to consider technologies, rather than implementations.
This final point is worth considering in more detail, particularly in light of the overlapping and intertwined “hot buzzwords” in network engineering over the last several years: Development Operations (DevOps), Software Defined Networking (SDN), Network Function Virtualization (NFV), Disaggregation, and Intent Based Networking (IBN). The one thing all these ‘buzzwords’ has in common is that they all deal with technologies enabling faster service creation and management.
DevOps - The first of these, DevOps, is a method used to configure and manage networks more quickly. While the “management” part of this is often forgotten in the rush to make configuration faster. What is DevOps ultimately trying to achieve? To bring the network into line with business needs more quickly. Once a business problem has been identified, it can then be converted into technologies, and technologies must be deployed and managed on actual hardware and software. This last stage, deploying and managing technologies on hardware and software, excels.
SDN - often confused with DevOps, moves one step back up the chain. Rather than seeing SDN as a single technology, it is better to understand SDN as a change in mindset around network design; rather than seeing appliances, SDN focuses on the kinds of information a network needs to run, and where to place that information. Solutions in this space intentionally divide the forwarding hardware from the control plane software that programs the forwarding hardware, allowing policies, such as the fine tuning of the path traffic takes through the network, to be more dynamic, and hence responsive. DevOps can be used to deploy and manage an SDN solution, and an SDN solution will contain the control plane feedback loops and application facing interfaces a DevOps solution will not.
Disaggregation - is simply the separation of networking hardware from networking software. Here the goal is to separate the value of hardware from the value of software, enabling value to be driven into both sides based on different lifecycles, and connecting the software architecture more closely with solutions to business problems. Again, you can deploy a disaggregated solution with a distributed control plane using DevOps, or you can deploy a disaggregated solution with a control plane based on SDN principles using DevOps; these are all complimentary technologies, rather than competing.
NFV - begins with the observation that network services should be separated from network topology, or rather services should be separated from appliances. This is another form of disaggregation, in essence, with the added step of virtualizing the network-based service, and bringing traffic to the service, rather than the service to the traffic. As above, NFV can be enabled by SDN and disaggregation, and deployed using DevOps principles.
Putting these pieces together a picture emerges of a different kind of network design process driving a different kind of networking. While the typical design process starts with requirements, and ends with the deployment of appliances, a more business focused design process would be broader in scope:
- What business problem needs to be solved?
- What kinds of services are required to solve this business problem? Where and how should those services be located? This question is enabled by NFV by allowing the designer to think in terms of services, rather than appliances.
- How will traffic be directed to these services? What kinds of special traffic handling are required to support these services, and in the larger context, the applications using the network? This question is enabled by SDNs and service chaining, which allow the designer to think in terms of policy separately from the problem of reachability, and how best to manage where information should be managed.
- What software needs to be implemented and deployed to solve this set of problems? What hardware? Disaggregation enables these to be two different questions, rather than one.
- How should the software and hardware be deployed and managed? This is the question DevOps answers.
Throughout this process, technology should be selected first, and then how that technology is instantiated second. The move from appliance driven network design to business designed networks is not a change in process, but rather an entire shift in mindset around the purpose of communication networks in the business world.
In the final piece in this series, I will consider another buzzword floating around the networking world, and how it might fit into this entire puzzle—intent.