You walked past me again today without stopping. I remember when you used to stop and admire my glowing red ball every day. But that was back when I was brand new and you thought I was the center of your data center.

I heard you talking to some friends about looking for a web acceleration solution yesterday. You were going to a meeting about it later that afternoon and you were so excited it was almost like old times, until you pointed me out on the way by and said, "Oh yeah, there's our load balancer."

It was then that I knew, knew in my backplane that you weren't paying attention to me. We just never talk anymore, do we? I am so much more than just a load-balancer, but you'd rather talk to vendors and go out to lunch with them instead of hanging out with me.

I can accelerate web applications like nobody's business, if you just give me the chance. Remember? I have a modular core that can add functionality like web application acceleration, advanced client authentication, IPv6, and layer 7 rate shaping with software modules. I have extra cycles, I can do it, but you wouldn't know that because you haven't touched my GUI in months.

It's my own fault, I suppose, for being so dependable that I don't need a lot of your attention.

I see you hanging around rack #3, checking out that router all the time. You know it's a chatty thing, don't you? You should hear what it says when you aren't tapped into a port. Always bossing us all around, telling us where to route things and reminding us that it's in charge. Whispering to you in foreign languages like OSPF and RIP. I can speak a lot of languages too, you know. I can speak SharePoint, and SAP, and Oracle, and Exchange. I can even speak Adobe. 

And now you're thinking about bringing in another piece of hardware? After all these years? I suppose you'll put it in rack #1, right at eye level where you can see it all the time. Haven't I always been here for you, working hard all these years to keep your applications available? I just want to hang out with you again, like we used to back when it was just you and me. When there weren't all these point solutions cluttering up the data center and using up all the power and taking up all your time with patches and upgrades and maintenance.

I can do more, you know. I can solve more of your problems than you realize. Application acceleration, security, rate shaping, authentication, caching, compression, message and protocol security. I can do it for you, I really can.

Just give me a chance to tell you about them and I know you'll never look at another point product for a problem I can solve again.

This blog on the inadvertent sharing of Google docs led to an intense micro-conversation in the comments regarding the inadvertent sharing of e-mail. sensitive financial data, and a wealth of other private data that remained, well, not so private through that [cue scary music] deadly combination that makes security folks race for their torches and pitchforks: Google Apps and Gmail.

[pause for laughter on my part. I can't say that without a straight face]  

Here's part of the "issue" "discovered" by the author:

Closer examination of the spreadsheets, along with some online digging, indicated that a CNHI employee had most likely intended to share the reports and spreadsheets with an employee named Deirdre Gallagher. Instead, he or she typed in my Gmail address and handed me the keys to a chunk of CNHI’s Web kingdom, including the detailed financial terms for scores of Web advertising deals. [emphasis added]

Many comments indicated deep displeasure with Google's e-mail functionality in terms of how it handles e-mail addresses. Other comments just seemed to gripe about Google Apps and its integration in general. "Dan" brought sanity to a conversation comprised primarily of technology finger-pointing, much of which blamed Google for people fat-fingering e-mail addresses, when he said: "The misuse of the technology can hardly be the fault of the providers."

Thank you Dan, whoever you are. How insightful. How true. And how sad that most people won't - and don't - see it that way.

Remember lawn darts? I do. If you're young enough you might not, because the company that manufactured and sold them stopped doing so in 1988 after they were sued when a child was tragically killed playing with them. But the truth is that a child was throwing the darts over the roof of a house at his playmate. He was misusing the lawn darts. The product was subsequently banned from sale in the US and Canada due to safety concerns.

Because they were used in a way they were not intended to be used. After all, consider the millions of other children (myself included) who managed to play the game properly without ever earning so much as a scratch. The mosquito bites were more dangerous than the lawn darts when used correctly and with the proper amount of attention paid to what we were doing.

This is not unlike the inadvertent sharing of Google docs. If I mistype an e-mail address, it's not the fault of my e-mail client when confidential launch plans find their way into an unintended recipients' inbox. That's my fault for not being more careful and paying attention to detail.  

In the aforementioned Google doc sharing escapade, Google's software did exactly what it was supposed to do: it e-mailed a copy of a Google doc to the e-mail address specified by the sender. Google has no way of knowing you meant to type "a" when you typed "o"; that's the responsibility of the individual and it's ridiculous to hold Google and its developers responsible for the intentional or unintentional mistakes of its users.

Look, there are plenty of reasons to be concerned about storing sensitive corporate data on a remote server and/or in the cloud, Google or others. There are a lot of reasons to be concerned about privacy and information leaks in SaaS (Software as a Service) and Web 2.0 applications. 

THIS IS NOT ONE OF THEM.

Those same documents could easily have been e-mailed to the wrong person, accidentally or purposefully, from someone's desktop. Mistyping e-mail addresses is not peculiar to GMail, or Hotmail, or Yahoo mail, or any other cloudware e-mail service. It's peculiar to people. Remember them? The ultimate security risk?

Rather than claim this is some huge security hole (it is not) or point the finger of blame at Google for sending that e-mail, remember what your mother said about pointing...

When you point one finger at Google for sending that e-mail, three fingers are pointing back at you.

Elasticity (adj) the ability of a cloud computing environment to expand or contract automatically on-demand according to real-time computing needs

One of the promises of an on-demand cloud computing environment (that's redundant, I think) is the ability to burst resources. Much in the same way that ISPs have long offered contracts that include the ability of the organization to exceed its allotted bandwidth for a fee, it is expected that cloud computing providers offer a mechanism for "bursting resources" that allows an organization to exceed its agreed upon resources for a fee, based on any number of factors such as bandwidth, requests per second, server resources consumed, etc...

Surprisingly, some of the providers being grouped under the "cloud computing provider" moniker do not offer the ability to burst resources. Seriously. I was reading through "Who provides what in the cloud" over at InfoWorld and came across this description of a cloud computing provider:

Terremark Worldwide: Resource pool for on-demand servers
The Terremark Enterprise Cloud is designed to give datacenters an Internet-optimized computing infrastructure. Enterprise Cloud clients buy a dedicated resource pool of processing, memory, storage, and networking, from which they can deploy servers on demand. A Web portal allows server to be dynamically provisioned from a pre-allocated pool of dedicated computer resources. Terremark promises that its cloud servers behave exactly like their physical counterparts, allowing applications to be run without modification.

That sounds more like managed hosted services than cloud computing. There's no indication whether you can "burst" resources if you consume all the dedicated resources you have purchased, but the requirement to "buy a dedicated resource pool" pretty much seems to say that you can burst within your resource pool, but you can't burst beyond that limit.

Certainly there's always going to be a physical limit on resources in a cloud computing environment. After all,the provider only has so many resources you can use and, just like in your data center, you can't expand beyond the physical limits of your servers. But artificially limiting resource availability based on what you buy seems to run counter to most often cited benefits of cloud computing: scalability and efficiency. If you aren't using all the dedicated resources, isn't that inefficient? If you can't scale beyond your dedicated resources, isn't that limiting your scalability?  

Yes, it does. But if the reason you're looking at "cloud" computing is to reduce management and maintenance and procurement costs, then a dedicated "cloud" model is probably a good one. It mitigates concerns over the provider having enough compute resources to ensure service level agreements and availability by dedicating resources to your applications, yet provides some flexibility associated with truly elastic cloud computing within that dedicated pool.

If, however, you're looking at cloud computing primarily to gain the benefits of scalability and efficient use of resources, then a dedicated cloud computing solution is probably not for you.

So make sure you know why you're considering cloud computing before you start shopping around and align those goals by choosing a provider with a model that suits your needs. Otherwise you may find yourself needing an umbrella.

As I was reading the Internet this morning I happened across an article with "Tips for Optimizing Your WAN (Wide Area Network)" and I thought, "Huh. That's pretty ... generic."  

While the article uses SAP applications as an example, it speaks in terms of generalities. Selective ACKs, quality of service, data reduction techniques, and HTTP compression.

That's when I said, "Whoop de doo."

Really, these techniques have nothing to do with SAP and applications and everything to do with packets. Every WAN and acceleration solution can do this stuff. I'm not really picking on the author of this article, per se. It's a common practice to "name drop" applications when you're describing WAN optimization and acceleration because, well, it exists to deliver applications. Without applications, a WAN is about as useful as HD cable service without a television. So why do we talk so much about packets and bandwidth instead of the important stuff, the applications?

Probably because most solutions don't really do anything specifically for any application, they're just messing with packets. They don't have any advice on how to optimize for X, or Y. They essentially treat all applications the same. In order to truly optimize an application you have to get into it. You have to deploy it and test it and tweak it and play with it. You can't just look at packets flying by, you have to understand how people use the application and figure out what's slowest and how you can fix it. You have to understand the application, not just understand how to spell it.

It's pretty easy to spot a solution that is focused on packets and not on applications. Here's three clues the solution you're considering is more interested in packets than in applications:

Clue #1: The phrase "packet inspection" is used

     Inspecting a single packet, no matter how deeply you look, doesn't really tell you much about the application aside from providing network-level information like its port and IP address. It might tell you that the application uses JSON, XML, or plain old text if you know what to look for. Most solutions don't.

Clue #2: Applications are mentioned as footnotes instead of subtext

     If applications are used only to illustrate a concept rather than being central to the discussion then the solution is probably focused on generic network-based optimizations and techniques. Applications are irrelevant to the solution; it does not (and probably is not capable of) provide any application-specific features.

Clue #3: The specific benefits to an application cannot be articulated

    If you ask, "What can you do for Microsoft SharePoint" and the answer comes back as vague generalities built on data reduction and caching you might want to keep looking. The answer should be specific, such as "SharePoint does X or Y and to reduce the impact of that on performance we do Z."

When you're trying to figure out how to squeeze more performance out of an application, especially when it's delivered via the WAN or the public Internet, you're probably going to start looking at WAN and application acceleration solutions. When you do, you need to consider whether you're getting an application focused solution or a network focused solution.

Cause one is going to speed up the network, and the other one is going to speed up your application. Which one do you really want?

Don and I were discussing security as a service and, as usual, he spouted off some wisdom in the form of an analogy that was too good to not to share.

When you're walking down the street with your entourage and an angry, I mean really angry, man steps out in front of you with a lead pipe where should your bodyguard be?

Basically, if I get hit by that lead pipe or I expend effort avoiding being hit or even momentarily look like something out of an Edvard Munch painting, my bodyguard is fired because he wasn't doing his job. He's doing it wrong.

That's the difference between security as a service when provided by a web application firewall and security as a service when implemented as an internal, software service solution. The WAF is inline, in front of the application, preventing that lead pipe from damaging the application. The application never has to expend unnecessary resources or sweat in public (wasted CPU/memory utilization/connections) when the security is deployed in front of the application.

If you're thinking, "Hey, what's that really gonna do? Waste a couple milliseconds? Pshaw! No one will notice!" then you need to go now and read this post on latency. Really - go now. I'll wait.

Threat defense is necessarily defensive. And the best defense is a good offense; one that is proactive rather than purely reactive. That means acting before the threat truly becomes a threat. Allowing a threat to reach the application before it's been identified and filtered out is certainly better than doing nothing, but stopping it before it gets near the application is even better.

No, it's not this one. It's not even mine. It's this one on High Scalability written by Todd Hoff. Not only does he explain latency and its sources, but its costs. Then he goes on to offer a plethora of ways to reduce latency.

A couple of suggestions he offers are:

Use a TCP Offload Engine (TOE). TOE tech offloads the TCP/IP stack from the main CPU and puts it on the network controller. This means network adapters can respond faster which means faster end-to-end communication. Network adapters respond faster because bus wait time is reduced as the number of transactions across the system I/O bus and memory bus are reduced.

Make TCP Faster. FastTCP, for example, tweaks TCP to provide smoother and faster data delivery.

I'd also suggest combining his suggestions of load-balancing and caching with TCP optimizations and connection management optimization by deploying an application delivery controller instead of a legacy load-balancer.

Todd also mentions "use Ajax to minimize perceived latency to the user. Clever UI design can make a site feel faster than it really is", but be careful with AJAX. It often needs to be tuned itself and there are some libraries that are better at this than others, and you can also employ more advanced features in an application delivery controller to help you out there.

I could go on about how much I love this post and how well it syncs up with the benefits of an integrated application delivery controller but I won't. Read Todd's post. It's a must read if you're building or thinking about building a scalable web application.

David Bressler of Progress Software, who acquired SOA vendor Actional in January 2006 wrote a very thought provoking post on marketing that really ended up being a post about SOA and where Progress fits into the "SOA continuum". He raises some questions, and problems, with SOA and product categories that ties in nicely with an excellent blog post on the subject Todd Biske wrote a while back containing some concepts that he presented at Burton's Catalyst 2006.

One of the confusing things about any market is the wide variety of names used to describe the products and solutions that fit into the wider technology landscape. There are a distinct set of SOA product categories, or SOA What as David calls them. The problem is that there is a lot of overlap in responsibilities between those categories. For example, SOA gateways and SOA management both provide a similar set of proxy-focused capabilities: content based routing, transformation, even service-enablement, but SOA gateways rarely include the robust monitoring and alerting side of management, choosing instead to integrate with existing network management systems (NMS) like HP OpenView or IBM's Tivoli instead.

That makes it difficult to know what you're getting out of a SOA Management product, because it could mean a completely different set of responsibilities when coming from vendor X as it does from vendor Y.

So after thinking about for a while, I think that by combining the David's SOA What categories with Todd's list of intermediary responsibilities we can come up with two distinct categories that makes the picture of the market a bit clearer and simpler. 

It comes down to products falling into two primary focus areas with regards to SOA services: managing them and delivering them. Delivery requires a different focus than management, and vice-versa. Delivery is concerned with protocols, security, and functionality traditionally associated with the network, while management is primarily service-focused, concerned with access, integration, and monitoring and, in the case of design-time governance, managing the service life-cycle.

So maybe one of the ways of clearing up the muddy landscape in SOA-land is for vendors to give a clearer picture of their SOA "focus". For example, F5 is, in this model, clearly focused on SOA delivery and not management, and I'd argue that Progress' portfolio is primarily focused on management, not delivery, with some design-time governance and testing thrown in for good measure (now where does that fit??)

I'm not sure if there's really a good solution to the issues raised by David but I think one way to start would be to delineate responsibility of intermediaries across the infrastructure. It certainly makes the picture a lot clearer and by associating responsibilities (and not features) with a particular category it's easier for someone to understand what a particular vendors' solution offers.

Part of the problem is certainly getting on the same page and using the same language. What's funny about that is that one of the premises of SOA was to get business and IT folks using the same language to better align IT with the business. We need to apply that to the vendor and product landscape, as well, so as vendors we can better align our products with customer needs. If you want high-availability and load-balancing of services, you should be able to easily find a vendor focusing on SOA delivery and not wonder whether those delivery features available in a product that focuses on management or governance is going to be "good enough" or not. And vice-versa.

Greg Ferro over at My Etherealmind has a, for lack of a better word, interesting entry in his Network Dictionary on the term "Application Delivery Controller."

I take issue with this definition primarily because an application delivery controller (ADC) is different from a load-balancer in many ways, and most of them aren't just "shiny chrome exhaust and new buttons". He's right that web application firewalls and web application acceleration/optimization features are also included, but application delivery controllers do more than just load-balancing these days. Application delivery controller is not just a "new marketing name", it's a new name because "load balancing" doesn't properly describe the functionality of the products that fall under the ADC moniker today. 

First, load-balancing is not the same as layer 7 switching. The former is focused on distribution of requests across a farm or pool of servers whilst the latter is about directing requests based on application layer data such as HTTP headers or application messages. An application delivery controller is capable of performing layer 7 switching, something a simple load-balancer is not.

When the two are combined you get layer 7 load-balancing which is a very different beast than the simple load-balancing offered in the past and often offered today by application server clustering technologies, ESB (enterprise service bus) products, and solutions designed primarily for load-balancing. Layer 7 load balancing is the purvey of application delivery controllers, not load-balancers, because it requires application fluency and run-time inspection of application messages - not packets, mind you, but messages. That's an important distinction, but one best left for another day.

The core functionality of an application delivery controller is load-balancing, as this is the primary mechanism through which high-availability and failover is provided. But a simple load-balancer does little more than take requests and distribute them based on simple algorithms; they do not augment the delivery of applications by offering additional features such as L7 rate shaping, application security, acceleration, message security, and dynamic inspection and manipulation of application data.

Second, a load balancer isn't a platform; an application delivery controller is. It's a platform to which tasks generally left to the application can be offloaded such as cookie encryption and decryption, input validation, transformation of application messages, and exception handling. A load balancer can't dynamically determine the client link speed and then determine whether compression would improve or degrade performance, and either apply it or not based on that decision.

A simple load balancer can't inspect application messages and determine whether it's a SOAP fault or not, and then once it's determined it is execute logic that handles that exception.

An application delivery controller is the evolution of load balancing to something more; to application delivery.

If you really believe that an application delivery controller is just a marketing name for a load-balancer then you haven't looked into the differences or how an ADC can be an integral part of a secure, fast, and available application infrastructure in a way that load-balancers never could. 

Let me 'splain. No, there is too much. Let me sum up.

A load balancer is a paper map. An ADC is a Garmin or a TomTom.

During the debate of WAF versus, well, just about everything, I heard an interesting thing.

See, I was taking the view that the duplication of security code across all services/applications lays the groundwork for the introduction of errors, accidental omission, and the degradation of performance. I argued that a WAF addressed all these problems and was therefore a better option.

The person with whom I was discussing the subject declared that security code did not necessarily need to be included in the application, it could be a service that, in the spirit of SOA, could be reused and that this addressed the problems just as well.

Huh. Really?

So basically it's okay to externalize security services and reuse them in order to secure applications, but it's not okay to externalize security services and reuse them in order to secure applications.

Huh. Really.  Apparently some services are more equal than others. Is this a web farm or animal farm?

I agree that software security services, for the most part, address the problems inherent in duplicating security code across applications and services, but so does a WAF. The question really then becomes, "Does it matter where that service is deployed?"

See, a web application firewall (WAF) is, essentially, a security service. It's a security service that performs its scans and evaluation of the cleanliness of requests before it reaches the application, rather than afterwards. But it's a security service, nonetheless. It validates input, scans for malicious data, checks for SQL and XSS injection, and looks for a number of other web-based application vulnerabilities. And it's a service.

So rather than chew up valuable application resources with illegitimate or malicious requests, you deploy the security service in front of the application and only forward on legitimate requests.

Maybe I'm missing something, but if you're okay with externalizing security into a service that's reusable and consistent in its application of vulnerability evaluations, I can't see where it matters whether that service is a hand-crafted one or living as a WAF.

My son was bemoaning the fact that while his WoW (World of Warcraft, a.k.a. Digital Crack) character has "epic" shoulders (that still cracks me up), he's still wearing green shoes.

Of course I asked what that meant because he made "green shoes" sound like some kind of digital disease.

Apparently in WoW (I am a gamer, but I stick to table-top games. MMORPGs hold little fascination for me) the power and effectiveness of items are represented by color. Green shoes are magical, but they're only one step away from "the shoes you left home to adventure in".

Worse, it seems that the shoes your character is wearing can drag down your effectiveness in general. So even though you have "epic" (very cool, very powerful) everything else, wearing green shoes drags you down.

It struck me that green shoes are like your network and delivery infrastructure; if that infrastructure is less than optimal and not up to the same level of "epic" as your application, it can drag down the overall effectiveness of that application. Even if you've got the killer application or site, if the network over which it is being delivered is congested, or drops packets, or unreliable, or just plain slow then that killer application isn't going to be as effective as it could be.

It's not enough to just build the application and make it available any more; you have to consider the underlying delivery infrastructure in order to ensure that it is doing its part in delivering effectively that application.

My son is hoping to get some more awesome shoes; one's with "gem slots" in them so he can add powers and abilities later on with gems. Yeah, he wants modularized shoes. That same concept works for your delivery infrastructure as well. If you ensure that your "shoes" (delivery infrastructure) can be upgraded/added to in a modularized fashion, that means you don't have to change your shoes (delivery infrastructure) when you want new functionality or powers.

Need acceleration (speed)? Add a module/gem. Need application security? Add a module/gem. Need optimization? Add a module/gem.

Just as it makes it really hard to be epic and effective when you have green shoes, it's really hard to deliver an epic application when it's wearing green shoes, a.k.a. a brittle, dumb delivery infrastructure.

So don't let your epic application get dragged down by wearing green shoes. Make sure you've got the shoes with gem slots in them so you can mod the heck out of your delivery structure as needed to ensure your application is as epic as it can be.