posted on Wednesday, March 24, 2010 3:53 AM
What we’ve got here is a failure to communicate. Some apps you just can’t reach … in the cloud.
Доброе утро!
What? You don’t speak Russian? Not even “baby” Russian? French? Spanish? Indonesian? Korean? Chinese?
If you’ve traveled you’ve probably picked up a few words here and there but it’s unlikely you are, at this point, fluent in any of the world’s languages excepting English. Luckily most other people in the world speak English better than you speak their language so you should get along just fine.
Unfortunately for folks stuck in the data center, most of their network and application network devices don’t have even that much in common. If you immediately thought “Hey, they have IP and TCP and HTTP in common” then think again. IP and TCP and even HTTP today are used as transport protocols, not data exchange formats. Your voice and the written word are IP and TCP and HTTP, but the actual data being exchanged? That’s where the difference between English and Russian comes in and rears its ugly head. (Well, there and at bedtime when you’re trying to explain to two non-English speaking girls it’s time to sleep.)
APPLICATION FLUENCY – LOST in the CLOUD
One of the primary drivers for deploying an application fluent, i.e. layer 7 aware and capable,
application delivery controller (ADC) is the ability to
understand the various “languages” used by applications. This allows the ADC to apply policies that provide for application-specific security, acceleration techniques, and other optimizations that wouldn’t be possible without understanding the data being exchanged.
This goes deeper than intercepting, inspecting, and applying policies on live requests and responses. It goes right to the heart of availability and impacts the ability to understand what it means for an application to be “available” and what it means to be “down.” In a volatile environment such as cloud computing and highly-virtualized architectures this understanding is paramount to ensuring availability and fault-tolerance of applications. This means the load balancing solution had best be able to understand the application and its data and from that make a determination whether it’s the application or the server or the virtual machine that’s available, and react accordingly.
In cloud computing environments, however, most load balancing “services” offered are lacking in their ability to “converse” with the application.
This “failure to communicate” at the application layer leads to misfires, to the incorrect assumption that a “server” being available means the application is available. To not recognizing that the “application” being available does not necessarily mean that the application is executing correctly. Errors in applications sometimes throw tantrums under heavy load that are not found in routine testing. These errors may or may not be introduced by behavior resulting from additional stress on the infrastructure. Regardless, it can cause error messages of the HTTP 5xx kind to be thrown back to users who have “traveled” the web enough to understand that there’s a problem aren’t necessarily going to be happy about it. Worse, the application can respond with a “successful” HTTP response while the data exchanged is completely wrong – or missing.
It’s these types of scenarios that application fluency is designed to prevent. But without the ability to communicate at that layer “in the cloud” it’s likely that such scenarios will become more common rather than a rarity.
INTERCEPT, INTERPRET, INSTRUCT
This is the realm of the dynamic control plane, the intelligence and glue that enables a dynamic infrastructure to adapt on-demand to conditions inside and outside the data center. By intercepting responses, an infrastructure 2.0 enabled application delivery controller can 
subsequently interpret the response and then instruct itself, the application, or other components within the data center ecosystem on the proper way to handle errors or misfires.
These capabilities are enabled by application-fluency and can be leveraged via Infrastructure 2.0 capabilities.
Without the ability to inspect requests and responses, especially from the application layer when determining not only availability but ability to fulfill a request correctly, the result is potential errors being exposed to users. Some of those errors may be, unfortunately, laden with information that can be exploited by miscreants to take action that will result in a breach of application security. It is not uncommon for a heavily loaded application to “crash” and pass back stack-traces or other juicy tidbits about its environment to the end-user.
When the Load balancer or ADC has the ability to to intercept and interpret both “live” responses and health-checks it can prevent potential information leaks as well as ensure availability be instructing itself to choose a different application instance or, if it is well-integrated into the architecture via its Infrastructure 2.0 capabilities, notify the management system of the problem so that it can take the action necessary to address the problem. But if the load balancing solution does not have these capabilities, then it’s acting blindly and it’s not able to really assure availability, which end-users would define as “accessible and working correctly.” In many cases what we have in cloud computing environments is a “failure to communicate” that ultimately leads to a failure to deliver applications.
And that’s really what “the cloud” and every other data center model is about: delivering applications. If the infrastructure isn’t helping to achieve that goal it may be hindering it instead, and that just makes your job all that much harder.
До свидания!
Technorati Tags:
MacVittie,
F5,
cloud computing,
infrastructure 2.0,
availability,
context-aware,
inspect,
intercept,
instruct,
application delivery,
load balancing,
application delivery controller
