Network disaggregation is a lot of work for engineers, and it's fraught with potential hurdles posed by sourcing hardware, a control plane, network operating system and how you manage necessary APIs.
If there is one thing that dissuades many network engineering shops from network disaggregation, it's that it seems like there is so much to take on when splitting up your hardware from your software. Among other requirements, you need to do the following:
Source hardware that meets your requirements -- think speeds and feeds.
Source a network operating system that meets your requirements -- think network management and integration into your existing operations.
Source a control plane that meets your requirements -- think network management and existing protocols, among others.
Source and create the tools required to build, deploy and manage disaggregated
This might feel like a lot of work because it is a lot of work. For a smaller shop, or a shop without the operating system and tooling skills, it might seem to be close to impossible to do all of this. Here is a key point to remember, however: You do not need to do all of this on your own. There are two different ways to solve the skills and time gap and, thus, deploy a disaggregated approach.
The first method is to find a value-added reseller that can help you move from a vendor-based -- aggregated or appliance-based -- approach to one that isn't. This can be challenging; there are few of these types of resellers in the current market, and their business structures generally don't lend themselves to this type of consulting.
The second way is to decide not to own all of these pieces. One of the advantages of network disaggregation is, in fact, that once the system is broken apart into multiple pieces, you can decide which you want to own and which you do not.
You should decide to own a particular piece if the following happens:
When deciding what to outsource and what to insource, you need to think about which API you will choose to write to.
You have internal people with the skill set and time necessary to do the work, or you think it is important, from a business perspective, to develop or find and hire people with this skill set.
You believe the return on investment -- the bang for the buck -- of owning any particular piece of hardware or software is going to add enough business value to justify developing or hiring the talent required to support those components.
Note these are business decisions, rather than technical ones. One of the advantages of the disaggregated model is it places these kinds of decisions into the hands of the operator, rather than the vendor. This means businesses can make more finely grained decisions, taking advantage of cross-utilized resources where possible and building just the pieces they need to improve their operational stance.
It may be that using an open source network operating system allows you to tweak the code to fit a particular data collection system, but you can consume Free Range Routing (FRR) directly off the public repository. Or, it might be that you can consume a commercial network operating system from a vendor, and then tweak some things in a private fork of FRR to fit your business better. Either way, the flexibility is there.
Determining how many APIs are necessary
There is one thing to consider, however, when deciding what to outsource and what to insource: the APIs between the two. Consider the following illustration:
The more functions you handle internally, the more staff you'll need.
In this illustration showing the components of a disaggregated device, there are four APIs marked. Each of these represents a potential point where you could outsource or insource the component.
For instance, you could outsource everything other than the control plane, which means you would primarily have in-house development staff writing to API 1. Or, you could just buy the hardware, developing the rest yourself, which means you would have in-house development teams writing to API 4. The more you choose to take on, the larger the development staff you will need.
There is a key point that is not so obvious, however -- not from most discussions around disaggregation, nor in the diagram above. When deciding what to outsource and what to insource, you need to think about which API you will choose to write to.
For instance, you might decide to own everything above API 4, so you fork a set of open source projects and start hacking away at the code to modify it for your business needs. If you choose to write to the Broadcom API, however, you will lose some flexibility in the ability to choose some other hardware vendor in the future.
In the same way, if you choose to write your own control plane and use either open source or commercial software for the rest, you need to carefully consider to which API you will write. Writing to Snaproute's routing information base is a completely different thing than writing to the Zebra interface; choosing one or the other can have a major impact on your ability to make a different choice in the future.
Network disaggregation gives you a lot of flexibility to make your network work better with your business. But you need to think carefully about the APIs you choose, where flexibility is critical in the overall system design and where you can live with a single source in the future.
