Inversion of (Network) Control

#devops #SDN #SDDC Layer 7 data path elements in SDN decouple flow routing and invert control from the network to the messages

Many folks associate "Web 2.0" with AJAX and the decomposition of the previously ascendant web application into individual "services", each that could be updated on its own. While initially praised for its savings on bandwidth (and thus improvement in performance) it should now be recognized as the harbinger of event-driven applications and, hopefully now, event-driven networks. 

Many Web 2.0 applications are designed based on the Inversion of Control pattern, in which control over flow of execution in the application is delegated to user events, rather than the application itself. This is distinctly different from the typical (traditional) application where logical flow (control) is sequential. The application is in control of the flow; it designates to which routine (function, method, event handler - choose your own terminology) control is passed and when.

Commonly, today, data is routed through a network based on configuration; on predefined routes correlating to an IP-based path. The control is in the hands of the network; it determines based on its configuration how traffic flows.

This is fixed, it is static, and it is one of the last frontiers to remain so in the modern data center.

SDN, on the surface, proposes to change that by eliminating the fixed routes and paths commonly used in order to enable the flexibility required to modify those routes dynamically as a means of improving network service. Congestion, downed ports, failed services - all are able to be routed "around" dynamically using SDN.

But the control is still in the network. The network (the SDN controller in an OpenFlow-based model) makes the decision where to reroute traffic upon encountering a problem. It is still in control and the application itself has absolutely no input in current SDN models. Even in proposed service chaining models, applications are not in control of the flow. The network remains the final arbiter of where and how traffic flows through the network.

A good example of this is when trying to apply application services to traffic in a traditional SDN / Flow Steering-based model:

All traffic, regardless of whether it is serviceable or not, is routed through the same set of services - as defined by the network. This is the network controlling the flow and it is inefficient and provides very little value in many cases because the content being serviced is not the right type of content for the service. But as SDN controllers have no visibility above layer 4 (IP and port) it cannot recognize content types or that its decisions are inefficient and wasteful.

Applying the Inversion of Control pattern to the data center network (as a holistic system) tells us to give control to the application, as it were. We let the logical flow - the path application traffic takes through the network - be determined by the application, not the network.

Thus we apply more event-based control - when this type of content is received, route it here, when this other type, route it there. This more thoughtful orchestration of services is far more efficient and respectful of resource utilization than simply service chaining.

Now you might be thinking well, the network technically still has control.  It's still a network, albeit higher order network, element that is in control. But it's not. It's waiting for specific events - the arrival of a specific type of content - to determine the flow. It gives the application control over what services will be invoked because the application determines what kind of content it is requesting.

Eventually, we will see more control asserted by the application. Eventually, the application will contain the directives that network elements will receive and act upon, just as events are defined and handled by applications today. Eventually, the application - and its developers or even its users - will actually control the network.

For a great read on Inversion of Control as a software development pattern, check out this CodeProject article.