Demystifying software-defined products

When someone sells you a software-defined product, for example software-defined networking, software-defined storage, a software-defined data center, etc, what she sells you is a controller made with software. This controller “sits” between the hardware and you.

When I write “you”, I mean your administrative programs, procedures, management tools, requirements and specifications. You tell the controller what you want the hardware to do.

When I write “hardware”, what I mean depends on the context. For software-defined networking, the hardware comprises of networking devices like switches and routers. For software-defined-storage, the hardware comprises of storage devices like SANs. For a software-defined data center, the hardware comprises of servers, networking devices and storage devices. In all cases, the hardware devices can be from different vendors and can be physical, as well as virtual. The controller shields you from the complexity of managing the devices. It provides a unified view of them even though they might come from different vendors and it operates them in a way that achieves automation, availability, scalability, elasticity and multi-tenancy. Thus, the controller is the software that gives the characteristics of the cloud to your hardware.

The controller communicates with the hardware it controls by using the APIs and protocols the hardware supports and exposes. The APIs that the controller uses to communicate with and manage the hardware are called southbound APIs, in general. For example, in the case of software-defined networking, the networking devices may support OpenFlow (or another standard) and thus expose a corresponding API with which the controller can manage them. In this case, the southbound API corresponds to OpenFlow (or any other standard) that each device exposes and supports.

The controller itself exposes an API, in order for the management tools and you to be able to communicate with the controller. This API is called northbound API, in general.

So, the hardware devices expose southbound APIs in order for the controller to communicate and control them and the controller also exposes northbound APIs, in order for your management tools to communicate and control the controller. These concepts are depicted in the following diagram.

Northbound and southbound APIs

Diagram: Northbound and southbound APIs

Please note that in this diagram, each arrow points from the entity that manages to the entity that is being managed. In general, the flow of information is bi-directional for both northbound and southbound communication. Northbound communication occurs between the management tool and the controller. Southbound communication occurs between the controller and the device.

It is customary to depict the management tools at the top, the controllers in the middle and the devices at the bottom of diagrams. The characterizations “northbound” and “southbound” are made in relation to the controller itself and its position in the diagrams. And, of course, the diagram I provided respects these traditions.

The conceptual framework (management tool – northbound API – controller – southbound API – device) exists for components and protocols to inter-operate in order to create clouds. All that remains is for protocols and APIs to emerge and become standardized.


About Dimitrios Kalemis

I am a systems engineer specializing in Microsoft products and technologies. I am also an author. Please visit my blog to see the blog posts I have written, the books I have written and the applications I have created. I definitely recommend my blog posts under the category "Management", all my books and all my applications. I believe that you will find them interesting and useful. I am in the process of writing more blog posts and books, so please visit my blog from time to time to see what I come up with next. I am also active on other sites; links to those you can find in the "About me" page of my blog.
This entry was posted in Cloud. Bookmark the permalink.