Networking SW: Go back to move forward
This is a collection of my thoughts on Networking Software Development.
Network software development has always been complex, challenging and very slow at times. NW Software fell little behind the mainstream software development in terms of agility. Let us examine the trends in application development to understand what is missing from NW Software development
Current Trends in Application development
Modern Web Technology companies move real fast. When you take closer look at all the new technologies/companies, there are certain traits common among them. One prominent common theme in the modern-day solutions is Micro services
Most of the web companies/technologies follow the new methodology called Micro services paradigm. I am not going to discuss, the very definition of, microservices based architecture. There are already plenty of articles on this paradigm. I recommend reading https://www.nginx.com/blog/introduction-to-microservices/. Instead of the definition I would like to focus on the economics of Microservices based architecture
Faster Development cycles
Microservices based architecture allows independent components to be developed and tested at a much faster pace. For instance, a routing device management plane, control plane software can be developed completely independent of data plane. This facilitates faster release cycles and paves way for the feature velocity that every organization strives to achieve.
Increased talent pool
Having completely modularized layers/blocks of software would allow teams to grow without requiring knowledge of the whole system. For instance, a project involving machine learning over huge data can benefit a lot if the data collection and data analysis are completely independent. It is easy to find and groom talent in two different areas. This significantly benefits the hiring process.
Easy to scale, maintain
Well executed micro services based solution is easy to scale out, maintain, upgrade/downgrade. All these attributes help in increasing customer satisfaction index
Networking software development practices
Traditionally network software development has been bogged down by the following approaches
Most routing, switching software is written in such a way that it is not possible to deploy, test various pieces independently. This means all the software validation and release readiness happens only after all the components (including hardware) is ready. This would obviously increase the release cycles and huge churn towards the end of the release cycle.
It’s very common for routing/switching vendors to have a lot of modules are written to work together for ever. These modules are written in such a way that it is not possible to exclude any components of the system. This results in bloated code, reduced feature velocity. Migrating such software from one platform to another becomes a huge project.
Specialized skill set
One of the biggest drawbacks of monolithic software solutions is the talent pool becomes smaller and specialized. Finding such talent is going to be difficult. Another problem with specialized skill sets is that innovation becomes rare as the same set of people would end up working for a very long time on the same solutions.
New way of network software development
Well not really!!!
Networking protocols were designed to be layered and independent from each other. Each protocol is intended to be vertically, horizontally independent of the other protocols. Each protocol or component was meant to be like a Lego piece. For instance, a layer3 control protocols like OSPF/BGP should never care for underlying Layer 2 protocols. Similarly, OSPF or BGP protocols should never dependent on each other presence.
An architecture that adheres to the old principles
I had the privilege of architecting new networking software suite for a startup in the valley (Disclaimer: I don’t work there anymore. Read https://email@example.com/four-most-important-questions-to-ask-before-joining-an-early-stage-startup-1291c310e728). I have seen the benefits of adhering to the old networking principles. The time it took for the first version of OS to come to life was significantly shorter compared to various other places I have seen. The significant things that helped drive this solution are the below
Model driven architecture
A model of the various objects that the end user sees is the genesis for the system. Everything is model driven. This would bring uniformity in developing various modules.
Standardized interfaces among modules
In this architecture, each module provides a standardized interface to the other components in the system. This paved way to generate and automate a lot of code. The benefits of code generation are quite easy to justify.
Completely modular, micro services
In this architecture, each module is designed to be completely independent of other modules. Each module was required to handle its own state. Every module was designed to be able to support restart at any time. Each individual component can be coded, tested and upgraded/downgraded independently.
Network software can be developed with micro service paradigm and it works. Infact that is how networking was intended to be. So going back to the roots is the right thing to move forward in an efficient way.
For the inquisitive minds that want to know more about the architecture I have been describing look at