In our last post, we discussed the essential nature of software and why it is different to any of the other “stuff” with which we build Open Network solutions. In this Part 3 of the Open Networking Software Interlude, we look at different perspectives of software and how this impacts the development of Open Networking solutions.
We saw that misunderstanding the core nature of software leads to potential issues in Open Networking projects. And in this post, we will outline how misunderstanding can also be generated by the way in which software is used as a component in a solution, which then informs different people with a different perspective on what software is (or isn’t).
How people use and interact with software components in a solution, anywhere in its lifecycle, can be described as the perceived “form factor” of the component.
A spectrum of software form factors
I think of four main “form factors” for Open Network components, which influence the perspective of all stakeholders (from designers through to operators).
These form factors are:
- Hardware + “Hard (Firmware) Config”
- Hardware + “Soft” Config
- Software as Hardware
- Software as Software
Hardware + “Hard (Firmware) Config”
All the functionality is embodied as firmware in hardware components and is fixed except for the user-accessible hardware settings that can be modified. Changes are limited to upgrades in firmware via specialised chipsets (e.g. flash memory), if at all.
Hardware + “Soft” Config
The functionality is embedded as firmware in hardware but can be controlled via configuration definitions that are editable as text by local engineers. Device functionality varies significantly based on the settings of configuration options. The range of config variation is much larger and may extend to a command set allowing logic-based decisions on input parameters from other components.
Software as Hardware
All the functionality is in software but is a software proxy for the “Hardware + Soft Config”. Component functionality is treated as a “black box”. Software enables much greater flexibility such as easy distribution of software images to required network locations and configuring the device by editing and / or loading its config.
Software as Software
All of the functionality is embodied in a software application that can be compiled and re-installed at all stages of the solution lifecycle.
Modifications can be made at both the software source code level and the configuration level. Delivery / implementation is via the build process from source code through to deployment. Source code and configuration are managed in the same manner: via a code repository. This model fully captures the benefits of CI/CD.
The implications of these “form factors”
All of these form factors are driven by software, with defined functionality that can be modified by local configuration, but they offer very different experiences for solution integrators and operators. They broadly break down into two categories: Black Box and Open Box.
Black Box
This category covers the first 3 form factors, excluding “Software as Software”.
For these form factors, development process is isolated at the vendor, and update cycles tend to be slow; functionality is effectively frozen. Vendors can and do update firmware, but whether new versions of this type of code can be retrofitted onto existing installed equipment is variable.
A solution designer can only vary component functionality via configuration options: in “Hard Config” this variation is limited to specific flags or values updated via an editing interface.
The “software” experience of stakeholders who use these components is limited to their knowledge of the (frozen) functionality and their level of skill in the configuration syntax.
Although “Software as Hardware” introduces 100% software components to the mix, the interaction between stakeholders and the components is identical to hardware.
This gives the stakeholders who use these components very limited view of software and what can be achieved.
Open Box
Only “Software as Software” delivers a true open experience. Changing the functionality of a component may be achieved by configuration or by changing the source code and regenerating the component.
Open Networking and Software
What does all this mean for Open Networking?
Firstly, Open Networking solutions are likely to include components of all four “form factors” in their design, but the three “black box” form factors are most likely, but “Software as Software” components are growing rapidly in availability.
Secondly, there is a growing mismatch between skills requirements and availability: the experience base of teams in an Open Networking solution is most likely to be in the “black box” form factors. Software development skills are often quite rare in the organisations that run Open Network projects.
How does this inform and affect Open Networking projects?
We’ll cover that in future posts.
Stay tuned.
