Performance

A client is still a client even when it's on the space station

Lori MacVittie — Fri, 14 Nov 2008 11:08:28 GMT

While I was at SD Best Practices in Boston last month I got to talk to a lot of engineers, developers, and architects about their environments and about what F5 does for application delivery.

One of the developers glibly told me he wasn't sure we could help him out because his environment was the international space station.

Yeah, how cool is that? Now that's cloud computing.

Another architect, who turned out to be a friend of a friend who I've conversed with but never met in person said the same thing, but his environment was nuclear submarines.

The Internet, she is everywhere.

There are certainly challenges with developing and delivering applications for such unique environments, but in the end a client is a client and a network is a network, even if it's over satellite links - which is most certainly the case for locations that cannot be wired or take advantage of wireless technology. What's awesome about application delivery solutions is that they are primarily asymmetric, they are a proxy to the core network that is almost always physically located in a data center somewhere on, well, earth. And on dry land.

An application delivery platform mediates, and it is physically located at the edge of the physical network. If there's a client on the space station or a nuclear submarine or a cruise ship or airplane that can communicate via a network, then an application delivery solution can indeed help the performance, security, and availability of the applications being delivered to those very remote locations.

Asymmetric solutions, of which a reverse proxy is almost always one, do not require deployment of client-side software. They are one sided, hence the use of the term asymmetric. All you need is the application delivery solution to be deployed at the edge of the physical network and voila! You can begin taking advantage of acceleration features like caching, compression, and protocol optimizations. The application delivery platform is aware of the network across which applications must traverse to reach the client, but it doesn't require that it be a certain speed, or a certain type, or anything, really. As long as it's operating on standards-based network protocols like IP, you can take advantage of the features of an application delivery solution for your environment.

In fact, an application delivery solution is perfect for address many of the problems inherent in low speed, high latency links like those used to communicate with uber remote locations like the space station or a nuclear sub because it has the intelligence to understand the network conditions unique to each link and adapt in real-time to provide the best performance possible for users accessing data and applications over that link.

And because the application delivery platform mediates between clients and applications, it can provide availability services to clients regardless of their location. In fact, because most application delivery platforms are full-proxy solutions, they are particularly adept at managing each side of the equation individually, simultaneously improving data center efficiency, reliability, and performance while adjusting proactively to the conditions currently being experienced by the client.

Being contextually aware of the unique environment from which clients access applications over a network is part of the secret sauce of application delivery solutions. By being able to understand and adapt to conditions on a per-request basis it can optimize delivery of applications for everyone - whether they are at home, at the office, on the international space station, or 20,000 leagues under the sea.

Technorati Tags: MacVittie,F5,SD best practices,development,architecture,infrastructure,application delivery,context-aware,network,client,proxy,acceleration,security,internet,satellite,space station,submarine,adapt,performance,blog

Amazing Application Acceleration: Simultaneously improve productivity, efficiency, and performance

Lori MacVittie — Thu, 13 Nov 2008 11:36:17 GMT

As a general rule, we spend far more time worrying about external appearances than we do internal. We are more concerned with our external web applications and how they look - and perform - than we are likely to regarding our intranet or internal only applications.

This blog post was interesting in that rather than encouraging folks to optimize web sites and improve end-user response time for web applications for the sake of the user experience, it focused on the relationship between page load time and impact on Google AdWords quality scores. Which is a bit different than the typical "you'll lose customers if you don't have a fast site" lecture.

By incorporating landing page load time into Quality Score Index calculation, Google is trying to improve user experience and as a by product increase the ppc advertisers conversion rate. They are hopping that because visitors do not abandon the pages because of poor web page load speed advertisers will get a higher return on their investments.

But what about internal web applications? You know, the ones customer service and call center representatives access when some poor hapless customers actually picks up the

phone and calls them? Yeah, those web applications; the ones that invariably seem to be cause of "my computer is slow today" apologies from the other end of the line, leaving the customer to wait ... and wait... and wait.

While it's easy enough to justify improving internal web applications which are indirectly customer facing based on customer satisfaction, it's just as easy to justify improving the performance of those same applications based on more quantifiable metrics: employee productivity.

The performance of employees within a wide variety of organizations who are tasked with customer service roles is almost always based on number of customers served in any given time interval. X per hour, Y per day, Z per week, etc... The efficiency of your call center or customer service departments is directly impacted by the ability of the employees to access customer information via applications, and increasingly that application is web-based. And slow.

If the average page load time of a customer service application is 10 seconds, then you necessarily need to add 10*(number of pages required on a call) to the total call time per customer. If the employee needs to access 5 pages, then you've just added nearly a minute of "wait" time to the time it takes to serve one customer. Given that most call centers like to keep their calls to a few minutes each, there's barely enough time for the customer service representative to greet the customer and ask for their identification before they've already gone over their allotted time.

Employing asymmetric application acceleration technology to improve application response time is a common prescription for performance impaired web sites. That same technology can easily be applied to internal applications, web or otherwise, as well to improve their performance and thus, load time. By leveraging technologies such as intelligent caching and compression, and optimization of the protocols (TCP, HTTP) used to deliver those applications you can simultaneously improve performance of the application, efficiency of the servers serving the application, and the productivity of your employees. Now that's multitasking!

If you can decrease the time it takes to interact with an internal web application you can decrease the amount of time spent with each customer, which leaves more time for employees to interact with more customers, improving their performance on a "customers served per hour/day/week" basis. That's an improvement in productivity as well as your bottom line as it decreases the costs associated with maintaining a customer over time, which is a key performance indicator for most organizations in which customer interaction is required.

So when you're considering improving the performance of your external web site and applications, think twice about how that same application acceleration technology just might benefit your internal web applications as well.

Technorati Tags: MacVittie,F5,application acceleration,asymmetric acceleration,customer satisifaction,efficiency,performance,response time,Google,productivity,server,http,web,internet,blog

3 steps to a fast, secure, and reliable application infrastructure

Lori MacVittie — Thu, 23 Oct 2008 11:40:38 GMT

You have just been promoted to CTO of Widgets, Inc. (Congratulations, by the way!) In your new role, on which of the following will you focus the most attention (and budget):

(a) the network

(b) the applications

Trick question. The answer is (d) all of the above. I know I didn't list that choice (I did in the poll, however) but you've taken multiple choice quizzes before; there's always a choice (d) all of the above. Always. And 25% of the time it's the right answer. In the case of technology today, it's always the right answer.

As an industry we spend a lot of time (and money) worrying about how to protect our applications and the data that drives them. We spend a lot of time (and money) agonizing over how to scale and keep available those applications which are crucial not only to our business users but our customers and partners. We spend a lot of time (and money) trying to make those applications faster and better and easier to use.

The network, however, is often left out of the discussion (and the budget). Like the local road, most people don't think much about it until there's a pothole that slows you down or causes a flat tire. Then it gets a lot of attention - and most of it negative.

This lack of attention to the network and its importance to scale and reliability and security is problematic and pervasive. So pervasive that research firm Gartner recently penned a research note on the subject of the network and cloud computing entitled, "You Can't Do Cloud Computing Without the Right Cloud (Network)." [reprint courtesy of F5]

There are four different types of networks supporting "cloud computing" and each react differently to different application characteristics. These differences are critical to the selection of a cloud network vendor.

Four different types of networks supporting cloud computing. I'm guessing that holds true for non-cloud computing architectures as well. There are many different types of networks and architectures and this is, in part, why the network is always, always depicted as nothing more than an amorphous cloud in application architecture diagrams.

Many of Gartner's key findings mirror what we've been asserting are four key attributes of infrastructure supporting cloud computing, whether that cloud is a big one "in the sky" (Internet) or a smaller one "in the backyard" (in your data center). In general, it mirrors what we've been saying for years with regard to improving application performance and scalability: the network is more important than most people tend to believe. It's not just a "pipe", it's an integral part of your architecture and is inherently important to the successful deployment and delivery of applications.

Data is the lifeblood of an organization, and applications are the heart of the data center. On that there is no argument. But the network is the complex system of veins and arteries that carries that lifeblood to and from the heart (applications) and without them, well, your business is likely faltering if not dead.

Just as doctors try to impart upon us the importance of preventive medicine and a healthy diet, it's just as important to apply that practice to IT in general. We need to be proactive and take preventive action whenever possible in order to deliver applications that are fast, secure, and available. And that means keeping the network on the same level of importance as the data and applications it is serving. That means investing in technologies that make the network better, faster, and more able to continue transporting data between the applications and the users that need them.

The network can inhibit the delivery of applications or it can enhance the delivery of applications. Which is ultimately up to you, and based upon what role you assign it within your application infrastructure.

The first step is recognizing that the network is as important as the applications and data it is delivering.

The second step is discovering how the network might help in deploying and delivering those applications and providing value above and beyond its traditional role of "just a pipe."

The third step is to do something about it.

Technorati Tags: MacVittie,F5,Gartner,cloud computing infrastructure,cloud computing,architecture,infrastructure 2.0,data,applications,network,application delivery,fast,secure,availability,scalability,web,internet

3 Really good reasons you should use TCP multiplexing

Lori MacVittie — Tue, 14 Oct 2008 12:10:12 GMT

AJAX. SOA. Social network API integration.

What is TCP Multiplexing?

All of aforementioned technologies have one thing in common. Okay, they have more than that in common, but for the purposes of this discussion there's one very

TCP multiplexing is a technique used primarily by load balancers and application delivery controllers (but also by some stand-alone web application acceleration solutions) that enables the device to "reuse" existing TCP connections. This is similar to the way in which persistent HTTP 1.1 connections work in that a single HTTP connection can be used to retrieve multiple objects, thus reducing the impact of TCP overhead on application performance.

TCP multiplexing allows the same thing to happen for TCP-based applications (usually HTTP / web) except that instead of the reuse being limited to only 1 client, the connections can be reused over many clients, resulting in much greater efficiency of web servers and faster performing applications.

relevant property they all share: they tend to be very TCP connection heavy implementations.

AJAX lends itself to keeping open multiple TCP connections between the browser and the server; using up connections that reduce the overall capacity of your server. SOA decomposes applications and business logic into services, and then encourages the reuse of those services across multiple applications, resulting in a trade-off between duplicated code and multiple TCP connections. And the use of APIs to integrate social networks, especially those driven by real-time updates like micro-blogging site Twitter, increase the number of TCP connections on a server dramatically.

The increase in TCP connections can overwhelm a server in a kind of unintentional DDoS (Distributed Denial of Service) attack. It certainly wasn't the expected or intended behavior, but a site or service can easily twitter under high loads, causing outages and outrage simultaneously.

Thus, there are three really good reasons to employ TCP multiplexing in your architecture.

1. IMPROVES PERFORMANCE
All applications can benefit from the improvement in performance seen when a server does not need to open and close hundreds or thousands or more of TCP connections a second. By removing the need to manage the TCP connections constantly, and instead reuse them across large numbers of requests, applications focus solely on generating and serving content, which improves application performance overall.

2. IMPROVES CAPACITY OF SERVERS
Generally speaking, servers are capable of handling only X number of concurrent

users and that number, in the past, has almost always been closely tied to the number of simultaneously open TCP connections the OS and application or web server can manage. By reducing the number of TCP connections required to serve the same number of users and requests, it leaves the server with the ability to open more connections and thus serve more users and requests.

3. MAKES CONSOLIDATION EASIER

Because the use of TCP multiplexing can improve the capacity of servers, it makes it possible to reduce the total number of servers you need to serve the same user base. The fewer servers you need means you can redistribute them for other uses or just shut them down, which lowers operating and management expenses. Or you can delay the need to acquire additional servers if you're still growing, putting off the investment for a future date.

TCP multiplexing was one of the coolest (in my opinion) technologies to enter the application delivery space. It's a fairly old feature at this point, but it's still one of the most beneficial, useful technologies available in load balancing and application delivery controllers today.

If you aren't using it, you should be.

Technorati Tags: MacVittie,F5,TCP,TCP multiplexing,application delivery,acceleration,application acceleration,reuse,green it,consolidation,twitter,capacity,internet,http,web,efficiency

The ironic truth about the ugly truth about web application acceleration

Lori MacVittie — Fri, 10 Oct 2008 10:17:02 GMT

Lately I've been seeing quite a few links to a white paper popping up in my alerts and feed-reader. Regardless of who's linking to it, it generally reads as promising to reveal some grand secret about how web application acceleration is an epic failure. I finally gave in and clicked on a link and ended up directed to download a white-paper, the description for which essentially distilled "web application acceleration" down to "caching". And then promised to tell me why caching wasn't a good way to accelerate web applications.

I didn't download the white paper primarily because equating "web application acceleration" to "caching" is exceedingly shortsighted and intimated that the actual content of the paper was most likely equally astigmatic.

While caching is certainly one mechanism used by web application acceleration solutions, it's not the only one. (I also found it ironic (hence the title) to see a paper denigrating the use of caches being promoted by a vendor for whose technology caching, albeit at the byte and object level, is an underlying foundation. Oh, none of us with these kinds of solutions call it that because it needs a snazzy marketing name, but that's the core of what it really is. Anyone who claims otherwise is just (desperately) trying to sell you something. Go ahead, ask me about how we implement that particular technology. Part of the answer is "caching at the byte and network level". I could continue this parenthetical aside further and say that what these guys are accelerating in the end is applications, so technically they're a (web) application acceleration solution, too, (So aren't they really pointing out their own faults then?) but that's probably better left as another post for another day. (Man, that was almost as bad as programming in LISP, but now I really digress.))

In any case, the truth is that caching is only one of the technologies used by web application acceleration to improve performance of web applications. Otherwise we'd call just them caches, wouldn't we?

Other technologies used by web application acceleration include:

Protocol optimization
You would be amazed (or maybe you wouldn't) at the number of enhancements to protocols like TCP are available that improve the performance of web (and other applications riding on the protocol) applications. Web application acceleration solutions often implement these enhancements.
Compression
Fewer packets means faster transmission and one of the ways in which you turn big fat web application messages into fewer packets is to compress them. This is especially true for HTML and XML and other web application formats like JSON which are text-based and are therefore highly compressable. Sometimes the answer to improving performance is not to compress, and web application acceleration solutions need to be intelligent enough to determine when to use this technology.
Linearization of PDF documents
Waiting for a PDF to load is one of the most painful experiences on the web. Technology that linearizes PDF documents and allows you to start reading page one while pages two through, well, whatever reduces the pain of that transfer. It still takes as long, but at least you aren't wasting your time waiting for it load.
Leveraging the browser cache
Caching often implies a server-side technology but let's not forget that there's a cache in every browser. Unfortunately, it's often not leveraged to its fullest potential. Web application acceleration technology improves the use of the browser cache to improve performance, because the fastest way to load content is to get it locally if it's fresh and available.
Content spooling
How fast a server can dish out content to a client is highly dependent upon the size of the network pipe (usually not a problem), number of concurrent users, number of open connections, distribution of resources being requested, and the total load and memory utilization on the server. Web application acceleration solutions, at least good ones, suck the content from the server as fast as possible and then serve it up to the browser. This reduces the number of open connections and concurrent users which reduces the load and resource consumption on the server and thus improves the speed at which the server can dish out content. Which makes the application faster.
SSL acceleration
It's forever been true that encryption and decryption is slow, and can be dramatically improved through the use of hardware assisted acceleration. Web application acceleration solutions generally employ this technique to improve the performance of secure web applications delivered via SSL.

I could go on about how web application acceleration solutions further leverage technology like TCP multiplexing to improve performance by eliminating the overhead associated with the constant opening and closing of TCP sessions, which in turns makes servers more efficient which in turn makes them faster resulting in ... faster application delivery. But I think that's enough for one day.

The truth is that web application acceleration technologies comprise more than just caching and employ multiple techniques that improve the efficiency of servers and the performance of applications whether they are delivered over the LAN, the WAN, or the Internet.

Technorati Tags: MacVittie,F5,application acceleration,caching,compression,SSL,performance,internet,web,http,tcp,protocols

8 things you can do with a proxy

Lori MacVittie — Wed, 08 Oct 2008 11:27:35 GMT

After having recently discussed all the different kinds of proxies that exist, it occurred to me that it might be nice to provide some examples of what you can do with proxies besides the obvious web filtering scenario. This is by no means an exhaustive list, but is provided to show some of the more common (and cool, I think) uses of proxies.

What's really awesome is that while some of these uses are available with only one type of proxy (reverse or forward), a full proxy can provide all these uses, and more, in a single, unified application delivery platform.

1. DATA SCRUBBING

Data scrubbing is the process of removing sensitive information like credit card and social security numbers from web application responses. This is particularly useful in preventing data leaks, especially if you're subject to regulations like SOX, HIPPA, and PCI DSS where the penalties for divulging personally identifiable information can be harsh fines - or worse.

Data scrubbing is is an implementation of a reverse proxy.

2. URL REWRITING

Rewriting URLs is something everyone has likely had to do at one time or another if they've developed a web application. URL rewriting is used to refer web requests to new resources instead of sending out a redirect response in cases where resources have moved, renamed, or migrated to a new version.

URL rewriting is an implementation of a reverse proxy.

3. LAYER 7 SWITCHING

Layer 7 switching provides an organization with the ability to maximize their IP address space as well as architect a more efficient, better performing application architecture. Layer 7 switching routes specific web requests to different servers based on information in the application layer, like HTTP headers or application data.

Layer 7 switching is an implementation of a reverse proxy.

4. CONTENT FILTERING

The most common use of proxies is content filtering. Generally, content filtering allows or rejects requests for content based on organizational policies regarding content type, the existence of specific keywords, or based on the site itself.

Content filtering is an implementation of a forward proxy.

5. REDIRECTION

Redirection is the process of, well, redirecting a browser to a new resource. This could be a new instance of a requested resource or as part of application logic such as redirecting a failed login to the proper page.

Redirection is generally implemented by a reverse proxy, but can also be implemented by a forward proxy as a means of redirecting rejected requests to an explanation page.

6. LOAD BALANCING

Load balancing is one of the most common uses of a reverse proxy. Load balancing distributes requests for resources across a number of servers in order to provide scalability and availability services.

Load balancing is an implementation of a reverse proxy.

7. APPLICATION FIREWALL

An application firewall provides a number of functions including some in this list (data scrubbing and redirection). An application firewall sits in front of web applications and inspects requests for malicious content and attempts to circumvent security.

An application firewall is an implementation of a reverse proxy.

8. PROTOCOL SECURITY

Protocol security is the ability of a proxy to enforce protocol specifications on requests and responses in order to provide additional security at all layers of the OSI stack. Protocol security provides an additional layer of security atop traditional security mechanisms that focus on data.

Protocol security is an implementation of a reverse proxy.

Technorati Tags: MacVittie,F5,BIG-IP,proxy,reverse proxy,forward proxy,full proxy,security,load balancing,application delivery,protcol security,URL rewriting,content filtering,data scrubbing,application firewall,internet,web

Virtualization: Just how far are we willing to take it?

Lori MacVittie — Thu, 18 Sep 2008 14:26:49 GMT

If your entire data center infrastructure is on one virtualized PC, you're doing it wrong.

Where's F5

The comparison between the power of a modern PC and a 1960's mainframe is often made in conjunction with a smug "look how far we've come" look.

But the way virtualization is headed today it's likely that mainframe holdouts will turn that smug look back on us with a blithe, "yes, you've gone all the way back to beginning."

If we're not careful, by the time we're through deploying virtual everything we're going to end up with a single PC comprising our data center. Which is pretty much like a mainframe, isn't it?

We're certainly headed that way. Virtual appliances for security, for switching, for many functions handled by network infrastructure are arriving daily. And we're lapping them up like a cat given cream.

Storage Decisions
Sept 23-24 in New York
Networld IT Roadmap
Sept 23 in Dallas
Oracle Open World
Sept 21-25 in San Francisco
Storage Networking World
Oct 13-16 in Dallas
Storage Expo 2008 UK
Oct 15-16 in London
Storage Networking World
Oct 27-29 in Frankfurt

Now I'm not going to go as far as @Beaker in his Four Horsemen of the Virtualization Apocalypse and claim that every time you deploy a piece of network infrastructure as a virtual device that God kills a kitten; but I think He just might kick one every time you deploy what is traditionally a network infrastructure function within a virtual appliance.

L2-3 switching used to be done in software, before the advent of network processors and high-speed backplanes and switching fabrics. When there were no VLANs (Virtual Local Area Network) and there were no ACLs (Access Control List) and there was nothing but forwarding of packets.

Routing used to be done in software before there were route optimizations and link load balancing and complex algorithmic configurations designed to optimize the flow of traffic in and out of a private network.

Load balancing used to be done in software before it got married to switching and figured out how to do incredibly interesting things with application traffic at high speeds and high volumes like acceleration, protocol optimization and security, and application switching.

So why are we thinking about reversing the advances in high-speed, high-volume network infrastructure by putting it back onto a platform that, while more powerful than its predecessors, is still heavily limited by the commodity hardware on which it will be deployed? Do we really want reduced capacity? Reduced performance? Limitations on concurrent connections, sessions, and users?

Why are we thinking about creating a single point of failure and introducing what would certainly become a single bottleneck in application and network performance? It's hard enough as it is to troubleshoot a network and an application, can you imagine the difficulty in troubleshooting a completely virtualized infrastructure?

How much functionality will we attempt to cram into virtual machines before we realize that we've reversed most of the gains we made with server virtualization in the first place? Will we really not be happy until we've crammed every piece of network infrastructure back into software on a virtual appliance? Didn't we learn from the 1990s that deploying technology simply for technology's sake was a bad idea?

Apparently not.

Technorati Tags: MacVittie,f5,virtualization,VLAN,switching,mainframes,pc,consolidation,security,load balancing,routing,server virtualization,internet,networking

The impact of the network on ... everything

Lori MacVittie — Thu, 11 Sep 2008 15:01:08 GMT

Back in the day when I was a technical architect and actually wrote code (yes, they did let me do that once) I got into a discussion with the rest of my team about the impact of our code on performance. I was saying white-space was evil because it can unnecessarily increase the number of packets necessary to transfer data. I wanted to go through the code (mostly JavaScript and HTML output) and reduce the white-space to make application response time better.

I was eventually overruled because, well, I just couldn't make the rest of the team understand the impact of our code on the network and performance and hey, one extra packet isn't going to really make a difference, is it?

Just as developers can adversely affect application performance because they don't always grok the network, network topology and connectivity rates can also affect application performance - and a whole lot more.

I stumbled across this great post on MySQL operational performance that describes this very scenario and thought it was awesome anecdotal evidence of the importance of understanding the network.

Where is F5?

VMWorld
Sept 15-18 in Las Vegas
Storage Decisions
Sept 23-24 in New York
Networld IT Roadmap
Sept 23 in Dallas
Oracle Open World
Sept 21-25 in San Francisco
Storage Networking World Oct 13-16 in Dallas
Storage Expo 2008 UK
Oct 15-16 in London
Storage Networking World Oct 27-29 in Frankfurt

It's also important for network administrators to understand how the topology of their network - and its speeds and feeds - can have an adverse affect on a variety of tasks, not just application performance. The core of the problem in the aforementioned post was a simple uplink between two switches with a significantly lower throughput than the rest of the network. A simple uplink reduced the total throughput from an anticipated 80 MB/second to 20 MB/second. That's huge, especially when you're talking about tossing around very, very, very large files.

Now if we were talking about a WAN link I'd mention WAN optimization because, well, there isn't much you can do about throughput limitations on WAN links. But this is a LAN, and while application acceleration technology could help with application performance in a similar scenario, the right answer here is simply to increase the uplink speed, or move the database servers all to the same switch with a higher speed uplink to the core switches/routers.

The network impacts everything because it delivers everything. Its toplogy and speeds and feeds are important for everyone to understand because it impacts the performance of ... everything. While I certainly think you should consider how F5 solutions can improve the performance, reliability, and security of your applications and infrastructure, sometimes the answer really is as simple as a bad cable ... or limited uplink speeds.

Technorati Tags: MacVittie,F5,MySQL,performance,networking,applications,application delivery

Damned if you do, damned if you don't

Lori MacVittie — Wed, 10 Sep 2008 14:03:42 GMT

There has been much fervor around the outages of cloud computing providers of late, which seems to be leading to an increased and perhaps unwarranted emphasis on SLAs the likes of which we haven't seen since...well, the last time the IT saw outsourced anything reach the hype-level of cloud computing. Consider this snippet of goodness for a moment, and pay careful attention to the last paragraph.

From Five Key Challenges of Enterprise Cloud Computing

I won’t beat the dead “Gmail down, EC2 down, etc down” horse here. But the truth of the matter is enterprises today cannot reasonably rely on the cloud infrastructures/platforms to run their business. There’s almost no SLAs provided by the cloud providers today. Even Jeff Barr from Amazon said that AWS only provides SLA for their S3 service.

[...]

Can you imagine enterprises signing up cloud computing contracts without SLAs clearly defined? It’s like going to host their business critical infrastructure in a data center that doesn’t have clearly defined SLA.

We all know that SLAs really doesn’t buy you much. In most cases, enterprises get refunded for the amount of time that the network was down. No SLA will cover business loss. However, as one of the CSOs I met said, it’s about risk transfer. As long as there’s a defined SLA on paper, when the network/site goes down, they can go after somebody. If there’s no SLA, it will be the CIO/CSO’s head that’s on the chopping block.

Let's look at this rationally for a moment. SLAs really don't buy you much. True. True of cloud computing providers, true of the enterprise. No SLA covers business loss. True. True of cloud computing providers, true of the enterprise.

What I find amusing about this article is that the author asks if we can imagine "signing up cloud computing contracts without SLAs clearly defined?" Well, why not? Businesses do it every day when IT deploys the latest "Business App v4.5.3.2a". Microsoft Office 2007 relies heavily on on-line components, but we don't demand an SLA from Microsoft for it. Likewise, the anti-phishing capabilities of IE7 don't necessarily come with an SLA and businesses don't shy away from making it their corporate standard anyway.

In fact, I'd argue that most cloudware today comes with an anti-SLA: use at your own risk, we don't guarantee anything.

The CIO/CSO's head is on the chopping block if he does have an SLA, because there's no guarantee that IT can meet it. Oh, usually they do, because the SLA is broadly defined for all of IT in terms of "we'll have 5 9's of availability for the network" and "applications will have less than an X second response time" and so on. But it isn't as if IT and the business sit down and negotiate SLAs for every single application they deploy into the enterprise data center.

If they do, then they're the exception, not the rule. And the applications this is true of are so time-sensitive and mission critical that it's unlikely the responsibility for them will ever be outsourced. Financial services and brokerages are a good example of this. Outsourced? Unlikely. The IT folks responsible for the applications and networks in those industries are probably laughing uproariously at the idea.

The argument that an SLA is simply to place a target on someone's head regarding responsibility for uptime and performance of applications is largely true. But that would seem to indicate that if you're a CIO/CSO and can wrangle any SLA out of a cloud computing provider that you should immediately use them for everything, because you can pass the mantle of responsibility for failing to meet SLAs to them instead of shouldering it yourself.

This isn't a cloud computing problem, this is a problem of responsibility and managing expectations. It's a problem with expecting that a million moving parts, hundreds of connections, routers, switches, intermediaries, servers, operating systems, libraries, and applications will somehow always manage to be available. Unpossible, I say, and unrealistic regardless of whether we're talking cloud computing or enterprise infrastructure.

Basically, the CIO/CSO is damned if he has an SLA because chances are IT is going to fail to meet them at some point, and he's damned if he doesn't have an SLA because that means he's solely responsible for the reliability and performance of all of IT.

And people wonder why C-level execs command the compensation levels they do. It's to make sure they can afford the steady stream of antacids they need just to get through the day.

Technorati Tags: MacVittie,f5,cloud computing infrastructure,SLA,reliability,CIO,CSO,cloud computing,uptime,Microsoft

The third greatest (useful) hack in the history of the Web

Lori MacVittie — Mon, 08 Sep 2008 11:13:30 GMT

Developers have an almost supernatural ability to workaround restrictions, even though some of the restrictions on building applications delivered via the web have been akin to a kryptonite. Like Superman fighting through the debilitating effects of the imaginary mineral, they've gotten around those restrictions by coming up with ways to implement functionality and improve the behavior of browsers and thus web applications anyway.

The first greatest hack was giving HTTP state. The second? Cookie-based persistence. The third? The CNAME trick.

THE PROBLEM

The reason the "CNAME trick" came about was a limitation on browser connections to a single host imposed by browsers, but particularly version of Internet Explorer previous to IE8. With only 2 connections per host name allowed and many times that number of objects on a page, the ability of IE in particular but really all browsers to quickly retrieve all those objects and render them was also hampered. This resulted in the appearance that the application performed poorly, when in reality it wasn't the application but the inherent delivery mechanisms that were slow due to limitations beyond the user's, the network admin's, and the developer's control.

Users, of course, don't care about any of this. All they know is that the application they are using is slow and they want it fast. And when some of those users are corporate business users, the developers are going to hear about it because the help desk is going to call them when they get barraged with complaints from users. This is the real reason developers develop nearly supernatural powers of hacking; they'll do anything to stop users from complaining.

THE HACK

Developers all over (including ours inside F5, working on building our application acceleration solution, WebAccelerator) figured that if the browser was going to limit the number of connections to a single host that the answer was simply to trick the browser into thinking it was talking to more than one host. Turns out doing this is rather trivial: simply add multiple CNAMEs for the same host to DNS, and then reference those as the host for some of the objects in the page. So www.example.com becomes www1, www2, www3, and so on.

This required changes to the application so that the additional host names were referenced, unless you made use of a proxy-based solution like WebAccelerator and BIG-IP Local Traffic Manager capable of rewriting outbound host names and virtualizing them to appear to the outside world as if they were a single host.

THE NEW PROBLEMS

This improved application performance, but at the cost of increasing the number of simultaneous connections to the server. This was "bad" in the sense that a web server, even well tuned, can only support X simultaneous connections at a time, and if each user was consuming Y connections per page, the number of concurrent users that could be supported on a single server was decreased by this hack. This made servers less efficient and required additional servers to ensure availability and scale.

Along comes AJAX, and the popularity of the "CNAME trick" rose rapidly. This is because AJAX became a way to provide near real-time updates to web browsers on a per-component basis. The result of this is a rich, interactive application that ends up maintaining a connection to the server on a nearly continual basis. So not only is a single application using more connections - and thus server resources - to load a page, it is also consuming more resources and connections throughout its execution.

Some web servers aren't good about dealing with virtual hosts. Rather than pretend that a single instance is all the virtual hosts, it will spawn more and more children instances, each one consuming resources until there are so many instances running that each one can handle fewer concurrent users than the parent.

The CNAME trick is also difficult to scale. Every time a new CNAME is added, it must be referenced within the application, which often means modifying applications. A costly proposition in terms of time and effort. If the CNAME trick is used as a reactive measure to address poor application performance, the entire application must be modified to reference the new host names.

THE SOLUTIONS

There are several solutions to the problems created by the CNAME trick, but they all take advantage of the same core principle: a proxy-based mediator. The proxy's job is to mediate for the client and aggregate connection requests to the server and make them more efficient, either by reusing connections to servers or by load-balancing them more efficiently, or by rewriting requests.

The advantage of implementing a proxy-based solution proactively is that applications don't necessarily need to be modified if the solution can rewrite host names in outbound responses. Basically, if the proxy is smart enough, it can change the host names in the page before it reaches the browser, and then aggregate and optimize them as the requests for each object come back in, essentially taking advantage of layer 7 switching to route all the requests to the appropriate web server.

The problem of additional connections can't be solved without a proxy of some kind. How efficient a web server is at handling the additional connections can be changed with tuning and optimization, but the additional connections and resulting consequences are going to hit that web server regardless without a mediator to deal with them.

THE FUTURE

This is a great hack, there is no doubt about it. It's one of the best ways to "workaround" the problems with browser limitations. Now that IE8 is increasing the connection limit from 2 to 6, the CNAME hack will be less necessary to combat the perception of poor application performance. But the problem of inefficiency and resource consumption on servers will not go away; in fact, it's likely to get worse as IE8 is adopted over the next year.

The increase in connections initiated from browsers will continue to strain the application infrastructure and, in fact, will get worse primarily because not everyone implemented the "CNAME trick" and thus not everyone's infrastructure felt the strain of those increased connections. With IE8 everyone will feel the impact of additional connections upon their application infrastructure - whether they're a small to medium business, a large enterprise, or a service provider.

Technorati Tags: MacVittie,F5,BIG-IP,application acceleration,performance,AJAX,IE8,CNAME trick,DNS,proxy,mediator,web,http,session,state,cookies,persistence,aggregation