My App anywhere: On devices, on controller, on both!

Current differences in app development on devices and controllers disappear. Devices and controllers will share a common programming environment – offering a unified development and deployment experience.

While SDN is moving from concept to reality, we notice that many deployments which focus on creating new network features interpret the role of the “controller” very pragmatically. In these deployments, the controller is not used as an independent layer of software which abstracts the entire underlying infrastructure as in the traditional view of SDN (see for example ONF’s SDN Definition). The pragmatic approach to network programming simply extends the distributed development environment of the network devices using a set of qualities offered by the controller.  Developers move those components of their distributed apps to the controller that benefit from the logical centralization or the enhanced resources (CPU, memory) that a controller typically offers while keeping other components on the network devices. Example use cases fall into the categories of distributed network analytics, DDoS thread mitigation, or routing optimization based on performance measurements. What does this mean for our development environment?

The programming environments of device and controller are coming together, providing a common development and deployment experience. What was once a fully distributed development environment (in case you were used to develop networking features for routers and switches) or a fully centralized development environment (in case you were focused on a controller-only centralized approach) is now a hybrid development environment – combining device and controller functions. In there, the controller offers you packaged and pre-build logically centralized functions, extensions which provide hooks into the functionality of the individual network device, as well as a runtime environment offering capabilities such as high-availability, automatic scaling, and operations support features. Devices offer an equivalent environment local to the device. Now you can make the tradeoff of where you run certain components of your app purely based on the individual needs of the app (e.g. scale, performance), rather than being constrained by the development and deployment environment offered to you.

A common development and deployment experience not only benefits the developer of distributed apps like the ones mentioned above. It also provides additional degrees of freedom to the developer of apps which apply only to a single network element. Those could for example be configuration plugins for Puppet or Chef. An app which would be hosted in a container on the network device itself for one deployment might be hosted on the controller for another deployment. When we develop new networking functions outside the core operating system, we choose to run them at the most appropriate place. The controller becomes a natural extension of the distributed development environment of the network devices.  Can we have a common container for network functions spanning the devices and the controller?

Moving forward, the industry will make sure that we don’t constrain the controller to functionality around network wide abstractions and multi-protocol device access. We will complement our SDN ecosystem with an ability to offer a common development and deployment experience across devices and controller. A path worthwhile exploring is to adapt the container concept that we have for operating systems to the needs of network apps.

Share