Why should Solutions and Applications Architects care about SDN?

SDN Solutions

Editor’s Note:  Vijoy Pandey is CTO, Network OS for IBM.

There is a lot of buzz in the Data Center Infrastructure community around Software Defined Networking, or SDN, a lot of press and social media feeds. Suddenly, networking and SDN is the hot new thing!

Solutions architects and Applications architects, who are trying to build out the next generation of their applications with attributes such as agility, elasticity, efficiency and fine-grained control, would be quick to dismiss SDN as nuts-and-bolts of the infrastructure, something that only the network or IT administrators need to worry about. Should they spend the time and dig into SDN and its value proposition?

What do you want your SDN to be today?

Before we begin, what is this thing called SDN? The more experts you talk to, the more varied the definition – each expert’s definition tailored to suit the agenda of the organization that the expert is affiliated with, like the initial days of Cloud. The definitions and agendas have become so varied, that it prompted my colleague to coin the phrase – “What do you want your SDN to be today?

A network is hard to setup, manage, and operate – it’s the most complex leg of the 3-legged infrastructure stool (compute and storage being the other 2 legs). There is inherent complexity due to the fact that a network, by definition, is a dynamic collection of a large number of things that are supposed to behave as one. Nonetheless, even after 30+ years, networks have been closed proprietary systems that have enabled connectivity in a very black magic kind of way. Sure, there are standards bodies to define commonly understood protocols, and a network guru can probably rattle off the 100+ three or four letter acronyms that go into each black box that system and network vendors build.

But lets talk to Joe, our Applications Architect. Joe designs his applications around the concept of application patterns. A typical 3-tiered end-to-end application for Joe forms the following application pattern in his mind -

3-tier Application Pattern

Figure 1

There are 3 distinct tiers in this application pattern – a cluster of web servers (VMs or bare metals); a cluster of middleware servers; and two clusters of database servers. Traffic between these tiers is logically connected as shown and passes through some high-level network services. I have omitted some other network and business services for clarity (a real-world example would have compliance checking software, load balancers/app delivery controllers, acceleration engines, etc. thrown in the mix).

How does Joe translate this application pattern into something deployable in the Physical Infrastructure?

Connectivity Services for Application Patterns

Primarily, the value proposition that SDN brings to the table is programmability.

A key tenet of SDN is to enable open APIs to the underlying network infrastructure that business applications can use to query its capabilities, to define the needs/SLAs of the business application, and to monitor and react to how the network is delivering on those needs. But it needs to be done right. Remember those 100+ three letter acronyms that only networking gurus could understand? These APIs need to be more business application level.

Lets revisit the application pattern in Figure 1 and see how it can be constructed with the help of a high-level API such as an Application Pattern Connectivity Service. This level of programmability gives Joe a powerful new tool to program and influence his network in a very business-app-friendly way. So how does it work in Joe’s example?

3 Tier Components

Figure 2

Joe would start by defining his application clusters, and assigning profiles to each cluster [Figure 2(a)]. For example, his middleware clusters might require the lowest possible latencies between the individual workloads in the cluster because of Low Latency Messaging requirements, whereas the Web tier might be okay with best effort service within the cluster. With the clusters and profiles defined, Joe would connect them logically [Figure 2(b)] depending on the application logic as defined by his application pattern [Figure 1]. Finally, he would attach network (or other services, such as compliance checking) within the logical connectivity he has just established.

Once he has realized the application pattern through the Connectivity Service APIs, which will in practice be exposed via a higher level orchestration tool such as OpenStack, the SDN controller and the data plane virtual and physical switches will take care of honoring the pattern definitions and SLAs at conception, and throughout the dynamic and elastic life-cycle of the business application.

What about the tools?

Now that we have made the network programmable at an application pattern level of abstraction, the question is, how does this get translated down to the physical and virtual nodes that make up the complex data center network of today? How does this translation work across the large web of discrete entities of disparate capabilities, capacities and personalities that define the data center network of today? And how do we make sure that the application SLAs are honored by the physical network, which eventually is the layer that provides resources to make this all a reality.

An SDN controller that delivers on this promise needs to have both pieces – (1) an abstraction of the network that is provided by an Overlay-based network virtualization product, as well as (2) a fine-grained control on the physical network resources that can optimized to guarantee the desired SLAs.

Joe definitely needs to understand this key point.

As to how these pieces actually work, those are just tools under Joe’s belt.

Check out more from Contributors on SDNCentral:

CONTRIBUTED ARTICLE DISCLAIMER:

Statements and opinions expressed in articles, reviews and other materials herein are those of the authors; the editors and publishers. 

While every care has been taken in the selection of this information and reasonable attempts are made to present up-to-date and accurate information, SDNCentral cannot guarantee that inaccuracies will not occur. SDNCentral will not be held responsible for any claim, loss, damage or inconvenience caused as a result of any information within this site, or any information accessed through this site.

The content of any third party web site which you link to from the SDNCentral site are entirely out of the control of SDNCentral, and you proceed at your own risk. These links are provided purely for your convenience. They do not imply SDNCentral’s endorsement or association. The copyright and any other intellectual property right any third party content belongs to the author and/or other applicable third party.

Comments

Leave a Reply