Emerging architectures are conflating responsibilities up and down the application stack. Who is responsible for integration when services reside in the network?

While preparing for an upcoming panel I’m moderating at Cloud Connect (in the “New Infrastructure” track), the panelists and I had a great discussion on the topics we wanted to discuss in the session. During that discussion it became increasingly clear that an interesting phenomenon has been occurring: the conflation of network and application responsibilities in the traditional “stack.”

Much of this inversion is absolutely necessary for emerging models of networking and computing to be successful. Traditional methods of handling QoS (Quality of Service) and identity management, for example, are no longer adequate in the inherently volatile world of cloud computing and dynamic networks. Interestingly, the driver behind the inversion appears to be based largely on the ability of specific layers access to context, which is necessarily replacing IP addresses as a method of client – and server – identification.

Back in the day, QoS was a class of problem unto itself, with an entire market of products and solutions developed specifically to address the challenge of prioritizing traffic. Initially it was thought that the ToS (Terms of Service) bits in the IP header would suffice, but it quickly became obvious that this required every organization and provider to honor those bits as traffic flowed through and across the Internet.

Didn’t happen.

A market emerged that moved QoS “up the stack” to Layer 4 (transport protocol). A class of devices were deployed that employed either TCP rate shaping or packet queuing technologies to control the amount of bandwidth a given “application” could consume. It quickly became apparent that this method was not robust enough as more and more “applications” began to use the same protocol: TCP. The devices again moved “up the stack” to Layer 7 (application) and began to apply QoS policies based on actually identifying applications based on layer 7 protocols and data characteristics.

In recent years even this has become inadequate because these techniques were all focused on limiting, in some way, total bandwidth for an application. While these solutions were also able to, albeit rudimentarily, accomplish rate shaping on a per-user basis, they still focused on bandwidth as their metric of choice to control. Hence a single user could be limited to X Kbps for all HTTP traffic, and further limited to Y percent for application A and Z percent for application B, but bandwidth as a meter of usage for applications today is not an appropriate measurement.

Hence, QoS has again moved up the stack and is more granular than ever. Rather than worrying about bandwidth, which has grown increasingly cheap and available for both organizations and users, QoS now concerns itself with limiting requests on a per-user basis and, in some cases, a per-client-type basis. Consider Twitter’s rate limiting implementation for its API. This is a modern implementation of QoS that attempts to equalize access to its services for all users, effectively ensuring a consistent quality of service for everyone. Bandwidth is not a factor, because the amount of bandwidth consumed by any given client is highly variable and based on what data is being requested.

Similarly we often see requests for ways in which application usage can be limited based on application layer variables, with nary a mention of bandwidth. It’s always about users and usage patterns of a specific application.

What was once a “network” function, QoS, has moved “up the stack” and is now primarily the responsibility of the “application.”

It wouldn’t be an inversion of responsibility if traditionally “application” layer responsibilities weren’t being similarly pushed “down the stack.” A good example of how this is occurring today is in the area of “identity”, which traditionally includes authentication and authorization.

In the early days of web applications, identification was based on a user name and password (sometimes IP address, sometimes a combination thereof) and was expected to be handled by the application. After all, the application knew what users should be allowed and thus is was the demesne of the application to provide those mechanisms. The use of .htaccess files was widespread as a means to achieve this functionality.

But as technology began to merge the world of the web with the internal world of IT, it became increasingly common to leverage external applications as an identity store and the means by which users were authenticated and authorized to access applications. LDAP, Active Directory, RADIUS, DIAMETER. These protocols resided somewhere between the application layer and the transport layer and provide the data necessary for applications to make access decisions.

But again, this method has run into obstacles in adapting to volatile and large environments. Scalability and the need to execute complementary access policies the network layer in authentication and authorization decisions has continued to drive identity and authentication and authorization “down the stack” and into the “network”. In a highly scaled environment, for example, it is often preferable that an intermediary Load balancer authenticate users to an application because it is increasingly painful for developers to tightly integrate application access and security policies into the application. Traditional methods are brittle, static designs that are increasingly tossed out in favor of more policy-based access that resides somewhere “in the network” rather than tightly-coupled with the application.

What was once an “application” function has moved “down the stack” and is now increasingly the responsibility of the “network.”

The conflation of responsibilities up and down the “stack” point to either an increasingly flattened application architecture comprised of services; services that may reside in the  application layer or the network layer, but are leveraged by both in approximately the same way.

This is actually much of the brouhaha behind Infrastructure 2.0; behind the evolution of the network to become “smarter” and more “integrated” with the rest of the infrastructure. As the network takes on more and more responsibility from the applications, especially as is the case in an increasingly cloudy environment, the components in the network must be able to consume services provided by other components and collaborate as a means to ensure the fast and secure delivery of applications to their ultimate consumers.

One of the side-effects is that it will cause some amount of confusion in the organization, at “layer 9”, as it were, regarding what role is responsible for developing and ultimately deploying those policies. Will developers become more network-aware? Will administrators and operators begin to take on a more development-oriented role in order to integrate and orchestrate the data center using the collaborative capabilities of Infrastructure 2.0 services?

Maybe the answer to that depends on where you are, who you are, and whether you’ve drank from the bottle or not.

Related blogs & articles:

• Accelerating Your (Secure) Ride to the Cloud: Get in the Fast Lane
• WILS: Automation versus Orchestration
• The Cloud Metastructure Hubub
• Infrastructure Integration: Metadata versus API
• API Request Throttling: A Better Option
• Elastic Environment requires Elastic Infrastructure 
• Impact of Load Balancing on SOAPy and RESTful Applications
• Infrastructure 2.0: Squishy Name for a Squishy Concept
• A Fluid Network is the Result of Collaboration Not Virtualization
• Clouds Are Like Onions