F5 Friday: The Gap That become a Chasm

#v11 #F5agility Differences in terminology, technology foundations and management have widened the “gap” between dev and ops to nearly a chasm.

There has always been a disconnect between “infrastructure” and “applications” and it is echoed through organizational hierarchies in every enterprise the world over. Operations and network teams speak one language, developers another. For a long time we’ve just focused on the language differences, without considering the deeper, underlying knowledge differences they expose.

Application Delivery Controllers, a.k.a Load balancers, are network-deployed solutions that, because of their role in delivering applications, are a part of the “critical traffic path”. That means if they are misconfigured or otherwise acting up, customers and employees can’t conduct business via web applications. Period. Because of their critical nature and impact on the network, the responsibility for managing them has for the most part been relegated to the network team. That, coupled with the increasingly broad network switching and routing capabilities required by application delivery systems, has led to most ADCs being managed with a very network-flavored language and model of configuration.

Along comes virtualization, cloud computing and the devops movement. IT isn’t responsive enough – not to its internal customers (developers, system administrators) nor to its external customers (the business folks). Cloud computing and self-service will solve the problems associated with the length of time it takes to deploy applications! And it does, there’s no arguing about that. Rapid provisioning of applications and automation of simple infrastructure services like load balancing have become common-place.

But it’s not the end of the journey, it’s just the beginning. IT is expected to follow through, completely, to provide IT as a Service. What that means, in Our view (and that is the Corporate Our), is a dynamic data center. For application delivery systems like BIG-IP, specifically, it means providing application delivery services such as authentication, data protection, traffic management, and acceleration that can be provisioned, managed and deployed in a more dynamic way: as services able to be rapidly provisioned. On-demand. Intuitively.

Getting from point A to point B takes some time and requires some fundamental changes in the way application delivery systems are configured and managed. And this includes better isolation such that application delivery services for one application can be provisioned and managed without negatively impacting others, a common concern that has long prevented network admins from turning over the keys to the configuration kingdom. These two capabilities are intrinsically tied together when viewed through the lens of IT as a Service. Isolating application configurations only addresses the underlying cross-contamination impact that prevents self-service, it does not fix the language gap between application and network admins. Conversely, fixing the language-gap doesn’t address the need to instill in network admins confidence in the ability to maintain the integrity of the system when the inevitable misconfiguration occurs.

We need to address both by bridging what has become a chasm between application and network admins by making it possible for application admins (and perhaps even one day the business folks) to manage the applications without impacting the network or other applications.

SERVICES versus CONFIGURATION

A very simple example might be the need to apply rate shaping services to an application. The application administrator understands the concept – the use of network capabilities to limit application bandwidth by user, device or other contextual data – but may not have the underlying network knowledge necessary to configure such a service. It’s one thing to say “give these users with this profile priority over those users with that profile” or “never use more than X bandwidth for this application” but quite another to translate that into all the objects and bits that must be flipped to put that into action. What an application administrator needs to be able to do is, on a per-application basis, attach policies to that application that define maximum bandwidth or per-user limitations based on their contextual profile. How does one achieve that in a system where the primary means of configuration is based on protocol names and behavior and not the intended result?

Exactly. They don’t. The network admin has to do that with his limited understanding of what the application admin really wants and needs, because they’re speaking different languages. The network admin has to codify the intent using protocol-based configuration and often this process takes weeks or more to successfully complete. Even what should be a simple optimization exercise – assigning TCP configuration profiles based on anticipated network connectivity to an application – requires the ability to translate the intention into network-specific language and configuration options. What we need is to be able to present the application admin with an interface that lets them easily specify anticipated client network conditions (broadband, WLAN, LAN, etc…) and then automatically generate all the appropriate underlying network and protocol-specific configurations for that application – not a virtual IP address that is, all too often, shared with other applications for which configurations can be easily confused.

What’s needed to successfully bridge the chasm is a services-oriented, application-centric management system. If combined with the proper multi-tenant capabilities, such a system would go far toward achieving a self-service style, on-demand provisioning and management system. It would take us closer to IT as a Service.

It may be that We (and that is the Corporate We) have a solution that bridges the chasm between network and application administration, between the static configuration of traditional application delivery systems and the application-focused, service-oriented dynamic data center architecture. It may be that We will be letting you know what that is very soon….

Published Jul 22, 2011

Version 1.0

dynamic infrastructure

f5 friday

hardware