I'm working on something else that's sort of related to this subject and noticed that rpaan polished the PHP code for this article on using PHP and iControl. It's nice. Great stuff, rpaan, and THANKS!

Imbibing: Water

This is an interesting article from Network World about how CIOs in Australia and New Zealand perceive security as being easier than reducing costs.

The IDC Annual Forecast for Management report surveyed 363 IT executives from Australia (254 respondents) and New Zealand (109 respondents) across industries including finance, distribution, leisure and the public sector.

CIO Challenges
Application layer threats	36%
Spyware	16%
Information Security	Bottom of the stack

The CIOs top priority for the next 12 months was reducing costs and addressing a lack of resources.

Okay,  here's a RADICAL idea. Let's reduce costs and address a lack of resources while dealing with application layer threats - all at the same time. 

Not kidding. A web application firewall (WAF) can address application layer threats. Because the WAF is performing an ever-vigilant watch over the applications, developers and security professionals can concentrate on other things - freeing up resources and reducing costs.

What's also interesting is that if the WAF is paired with an intelligent application delivery controller, capable of fully inspecting and manipulating requests and responses, you can also address that information security concern with the ability to dynamically adjust security policies when/if necessary to address emerging or newly discovered threats. While the CIO may not be so concerned about information security, I can't imagine that the guys in the trenches would put that concern at the bottom of the stack. They aren't called "Information Security Professionals" for nothing, after all.

Aren't convinced that a WAF is the right way to go? Well, the PCI Security Standards Council believes in WAF capabilities enough to make it one of two options in PCI DSS, specifically requirement 6.6. That's non trivial.

Also consider this analyst report from Stratecast, or this discussion on some of the benefits of centralizing application security.

Imbibing: Mountain Dew

Tech Republic blogger Toni Bowers discusses five high-tech skills that are waning as far as ability to command high salaries according to a recent Network World article. At the top of the list? HTML.

Denise Dubie writes in the Network World article:

As companies embrace Web 2.0 technologies such AJAX, demand for skills in HTML programming are taking a back seat. According to Foote Partners, pay for skills in technologies such as Ajax and XML increased by 12.5% in the last six months of 2007, while IT managers say they don’t see a demand for technology predecessors such as HTML. "I’m not seeing requirements for general Web 1.0 skills -- HTML programming skills," says Debbie Joy, lead solution architect for CSC in Phoenix.

Dude, wait? What?

I hate to be the one to break this news, but HTML is still very necessary in a Web 2.0 world. All the AJAX in the world isn't going to be very useful to clients if it can't be displayed and guess how that happens? Yes, good old HTML.

While it's true that in a Web 2.0 world the HTML is predominantly programmatically generated, but it's still HTML whether it's spit out by a server-side script/application like ASP or PHP or patched together using JavaScript and XML.

Someone still has to understand HTML and generate it and it isn't likely that the use of HTML is going to decline any time in the future. In fact, I wouldn't hire a "web application developer" who didn't know HTML. That'd be full of all kinds of fail. 

Now I've never been a fan of calling HTML "programming", because it's demeaning to code monkeys everywhere. (That's called irony, folks) The ability to write HTML makes you a programmer like banging out "chopsticks" makes you a concert pianist. And I think that the decreasing emphasis on HTML is related directly to the explosion of HTML "programmers" during the dot.com days, when anyone who understood how to write the markup for a table could get a fairly well paying gig doing just that. Today's web is built dynamically, and that requires "real" - or at least more real - programming skills because the languages through which HTML is generated are actual programming languages, requiring a basic understanding of conditional logic, variable manipulation, and parameters. That's not something that the HTML "programmers" of the dot.com era are going to be able to pick up out of an HTML reference guide.

So this article seems to be a bit misleading. HTML skills are - or at least should be - a requirement for web application developers because they are going to need to generate HTML. But the article is right in that the ability to slap together HTML isn't likely to help developers command a high salary, because understanding HTML in a Web 2.0 world is merely tablestakes. Trying to bank on your HTML skills today would be like trying to negotiate a higher salary because you can write a linked list¹. Yeah, go ahead and try it, I dare you.

HTML skillz may no longer be considered 1337, but they are still required and just as important - if not more so - as they have ever been.

Imbibing: Coffee

With apologies to the writers of Amadeus

MOZART [The fresh SOA Architect]

But it's new, it's entirely new. It's so new, people will go mad for it. For example, I have an activity in the second step - it requires calls to two services in parallel. Then a third service is called to verify the name of the customer, and a fourth to perform some security checks. Then a logging service makes five and so on. On and on, six, seven, eight! How long do you think I can sustain that?

JOSEPH [The jaded IT Manager]

I have no idea.

MOZART

Guess! Guess, Majesty. Imagine the highest number of services that could be orchestrated this way, then double it.

JOSEPH

Well, six or seven! Maybe eight!

MOZART

Twenty, sire! How about twenty?

Sire, only SOA can do this. In a traditional web application, if more than one service is called at the same time, it's just chaos.  No one can manage the flow. But with SOA, with SOA you can have twenty services all executing, and it's not chaos- it's a perfect orchestration. Isn't that marvelous?

The response that Joseph should give Mozart at this point is, "It is. Now answer me a question. How long do you think the customer will wait? Guess! Guess, Mozart! Imagine the longest time a customer would wait, then halve it. Will this new architecture be able to do that?"

The process of building out a SOA is a lot like composing an opera. There's a story(the architecture), an orchestra (the infrastructure), and a bunch of services (the singers). All three must be coordinated carefully in order to create perfect harmony.

You can't ignore any one of the pieces or you risk a lackluster performance that leaves no one satisfied and everyone wondering why they bought tickets in the first place.

A great composer like Mozart knew what melodies should be duplicated and by what instrument as well as how important the supporting harmonies were in creating the perfectly balanced musical score.

A great SOA architect also understands that the supporting harmonies (infrastructure) is just as important as the melodies (services) in building out a successful SOA.

Just as some melodies need to be duplicated by several instruments, so, too, do some services need to be duplicated in order to support service level agreements and to meet capacity demands. And just as counterpart harmonies support those duplicated melodies, balancing them, so too does a strong infrastructure support the duplication of services.

Whether you're just building out your first SOA or trying to improve an existing implementation, remember to consider the impact of infrastructure on its overall balance. It could be the difference between composing music that will live on for centuries (an architecture that will support the business for many years to come) and composing a song that you can't even give away free on the Internet (an architecture you'll replace in 2-3 years).

For more on the impact of infrastructure on SOA and performance, check out these resources:

SOA + WOA = NOA

SOA Delivery

The Role of the Adaptive Network in SOA

Centralized Authorization and SOA

SOA & Web 2.0: The Connection Management Challenge

SOA Performance: Round II

SOA and Performance

Imbibing: Mountain Dew

File virtualization and storage are gaining a lot of mindshare lately, probably because the longer a business runs the more data they have to store. And with compliance regulations, sometimes that means not only more data to store (like all your e-mail) but storing it for a very long time.

And then there's building out large farms of servers to support high volume sites. File virtualization makes a lot of sense when you're trying to manage large numbers of servers, especially if they're essentially clones.

And let's not ignore the other kinds of virtualization; if you're set on OS virtualization you're going to need to store - and potentially share - those images somewhere, and what better way to accomplish that then by using file virtualization?

What? You're not really up on file virtualization and its benefits? Then have I got some good news for you. F5 Acopia Data Solutions will be hosting a free webinar on May 22 on file virtualization. Learn how it works, how to reap the benefits, and get a copy of File Virtualization For Dummies®, hot off the presses.

You can find more information and details as well as register for the webinar here.

Imbibing: Coffee

The Green Tech Blog on CNET News postulates that the next green trend will be to s l o w down the innertubes, or more accurately, the flow of data. Now that slow down is apparently measured in terms of milliseconds, and is "not enough for Web surfers to notice" according to researchers.

But as we recently discussed, milliseconds at every hop can potentially add up to seconds, and seconds will certainly be noticeable by Web surfers - particularly those who might be engaged in sensitive financial transactions like selling and buying stocks. And we won't even discuss the effect on real-time communications like SIP from the potential jitter arising out of such a theory. Suggesting that routers can delay traffic for even milliseconds and then measuring only the effect on Web traffic is short sighted. This is Web 2.0, baby. We're converged, now, integrated. Routers don't generally distinguish between SIP and HTTP and RTSP. It's all just bits and bytes, forwarded on to the next hop. Delay one you delay them all.

I think there's a better way to go green, and it actually improves performance rather than degrades it. Why put the onus on network devices when a better solution - one that makes everyone happy - is to build out an architecture that's capable of improving performance, ensuring uptime, adding security, and will decrease the overall consumption of power?

Yeah, I don't get it either.

Imbibing: Mountain Dew

a.k.a The morning Lori was wrong

I got an e-mail newsletter yesterday with a link to BEA's Virtualization TCO calculator. As my team is engaged in a lively debate regarding virtualization and its alleged benefits (you can tell which side of the fence I'm on at the moment) I visited the calculator to see what it would say. Then I sent the following results to the team, a smug smile on my face because the virtualized OS environment turned out to be more expensive than the non-virtualized environment.

Someone, of course, pointed out that the power and cooling costs didn't quite jive. My thought was that maybe it does. After all, while you are reducing the number of servers in a virtualized architecture, you're also increasing the average utilization of those servers. That ought to even out in the end. But I didn't want to leave it to simply theory, I wanted some concrete proof.

So I did some research and found some real data¹ with which I thought I could back up my theory, then plugged that data into a spreadsheet. I thought "Ha! I'll show you that this isn't the rosy picture so many virtualization supporters like to paint."

So here's where I get to admit I was wrong. Yeah, I know - hard to believe, but it's true. And here's the data behind that startling epiphany. Each grouping of data is based on consolidation of 10 servers with average CPU utilization of 40%, 65%, and 80% respectively. The resulting number of servers is the number required to maintain the same load overall, but at 95% utilization per server.

It appears, then, that although there is a diminishing return on the amount of energy saved by consolidating physical servers and virtualizing the environment, still there is a return. Fewer servers == less power, even given that modern servers draw variable power based on utilization. Turns out that OS virtualization may indeed be more energy efficient in the long run.

Hmmmph. Well, there's still the issue of increased licensing and administrative costs.

The debate, I'm sure, will rage on.

¹ Power consumption data based on HP DL360 G5 servers using HP's Power Calculator

Imbibing: Coffee

According to a recent CIO article and survey data, the top challenge to virtualization success today is balancing server workloads and maintaining application service levels.  That makes sense; if you're going to create 3 or 4 or 99 virtual servers you need to be sure that the workload isn't going to suck dry the resources available on any particular machine. And, too, you'll probably need some solution to load balance those applications across virtual instances.

That part, at least, seems easy: get thee a load balancer, pronto. Turns out that the concern regarding balancing server workloads is more complex than most likely realize. A load balancer will, in fact, distribute server workloads across virtual instances. It likely won't, however, do so in an intelligent way and it almost certainly won't do much to ensure that service levels are maintained.

Top Challenges to Virtualization Success

(Respondents chose up to three)

SOURCE: CIO research

Application delivery will, however, address both those challenges in an easy, consolidated, green, efficient (have I hit all the buzzwords yet?) and flexible way. Seriously, an application delivery fabric is the best way to address this type of challenge and it does provide all benefits in one way or another.  

You see, an intelligent application delivery controller understands the load on the server and can decide - in real-time - whether any given request should go to one server or another based on that understanding. So if Virtual Server A on Real Server 1 super busy at the moment, an application delivery controller can send the request to Virtual Server B , instead. Virtual Server B might be on Real Server 1, or it might be on Real Server 2. It really doesn't matter, unless you want to start factoring in both the current application performance within a virtual server AND the resources available on the real server. Regardless of what factors you want to consider, an intelligent application delivery controller can take them into consideration and balance server workload across instances in a way that maintains application service levels.

Want to take it further? Do you want to automatically provision those servers to get the most out of your resources? Consider an application delivery network that can integrate with popular virtualization technology like VMWare. Such integration takes solves the problem of balancing server workload by dynamically increasing or decreasing the available server instances in real-time, according to current network, server, and user conditions.

So if you're struggling with balancing the load across servers - virtual or not - check out an application delivery network so you can move on to the next challenge: IT organizational politics.

Sorry, I wouldn't touch that one with a 10 foot patch cable.

Imbibing: Coffee

There's more than one way to go green with application delivery networks

The past few months have seen a high volume in the number of "green" products announced, many of them in the application delivery realm. Almost universally these announcements have focused on the products themselves as a method of reducing power consumption both in power required to run the device and in lessening the amount of heat generated that requires cooling.

But there's another way to "go green" with application delivery, one that doesn't necessarily rely on the application delivery controller being "green" itself.

The Three "R"s

We've long heard of the three "R"s (reduce, reuse, recycle) as a means by which we, as consumers, can reduce the sheer volume of crap that must be disposed of on a yearly basis. You may not be aware that this concept applies to efforts to go "green" in technology and, in particular, to the benefits provided by application delivery networks.

Application delivery networks can offload SSL termination from servers, which can reduce by up to 30% the resources required on a web or application server. By moving SSL termination and management onto servers, the freed resources - memory and processing power - can be used by the web or application server. This increases the capacity of your existing servers, which obviates the need to purchase additional hardware. The result? Less power consumed to serve your applications. On top of this, SSL operations are generally hardware accelerated in application delivery networks, meaning not only will you reduce the resources required for your applications, you'll improve their performance as well.

Application delivery networks are also capable of providing TCP multiplexing. TCP multiplexing can reduce the burden on web and application servers by reusing existing TCP connections, which translates into fewer resources. Much like SSL offload, TCP multiplexing reduces the number of servers you need to power your applications and thus saves grass and cash. This not only has a positive impact on the environment, but on your IT budget as well.

Our third "R", recycle, is not nearly as obvious as the first two. Recycling takes the form of caching in an application delivery network. By caching static content - and dynamic content that is generated by dynamic mechanisms - an application delivery network recycles content. In doing so, it reduces the resources needed from web and application servers and increases their capacity, again resulting in less power consumed, less heat generated, and a greener (grass and cash) effect. You may also be able to reduce the number of servers you need or, at a minimum, hold off on purchasing additional servers that would otherwise be needed to increase capacity, but would also up your power consumption.

If you really want to reduce your total carbon footprint, consider an SSL VPN for remote access and let your employees telecommute, either permanently or even just one day a week. By removing the need for employees to commute you reduce the amount of emissions they generate by driving as well as the volume of difficult to degrade plastic containers that come from stopping to grab a coffee on the way to work.

So if you're truly interested in going green - whether in terms of grass, cash, or both - consider the benefits of an application delivery network. Going green isn't just about devices and their power consumption, it's about how much more efficient and green it can make the rest of your infrastructure, as well as your employees.

Imbibing: Water

The shortest distance between two points is, according to geometry, a straight line. Unfortunately for everyone, there's no way we can hope to physically have a straight line between us and any server - unless we're in the data center troubleshooting a problem. Whether it's because of physical distance limitations, location, or the device we're using, there's bound to be many points along the path between our client and any given server.

But when we diagram network architectures we often obscure in a cloud the actual representation of the network - either because there's just too many devices (the Internet) or we consider the actual architecture irrelevant. But an accurate representation of "the network" can be important in unraveling application performance issues.

Most of us understand that there is a cost associated with every "hop" in the network, where every "hop" includes every device that data flows through on its way from the server to the client. In college we learned about Dijkstra's algorithm, which taught us how to find the shortest path through an interconnected set of points (hops). From that, we learned the basics of routing algorithms - whether we knew it or not at the time.

Every hop adds latency (cost), period. It may be so minute that it's nearly unmeasurable, but it's there if for no other reason than the requirement that data must travel a distance to get to the device, and traveling costs something, no matter how small a time interval that something may be. It stands to reason then that the more hops in a path the higher the cost of traversing that path.

The goal of application acceleration, then, is to reduce the cost associated with traversing a particular path such that data is delivered as fast as possible to the client. We want "the network" to act as close to a "straight line" in terms of performance as one can get, and the best way to do that is to reduce the amount of data traversing the path. Less data means mean time to travel and less time to process, making the total time to deliver data from application to client, well, less.

There are several ways in which application acceleration solutions can reduce the amount of data being exchanged:

1. Don't deliver it at all

In many cases, data already exists on the client, particularly web clients (browsers). By making better use of client-side caching, application acceleration reduces the amount of data traversing the network.

2. Compress It

Most applications exchange data in text formats - HTML, JavaScript, XML, JSON - and can therefore benefit from compression. Compression reduces the total amount of data that needs to traverse the network. But be careful! Compression benefits begin to reduce dramatically as the amount of data being transfered reduces in size.

3. Deduplication

Another way to reduce the amount of data being exchanged is to only send data that is new; that is, remove data that has already been transfered and replace it with a tiny marker instead. This reduction is typically how symmetric acceleration products work.

Another way that application acceleration can improve performance is to reduce the latency introduced by individual hops along the path. An application acceleration solution accomplishes this by performing what we often refer to as "offloading" tasks from other devices or, more typically, the servers. It is almost unilaterally true that the web or application server will introduce the largest amount of latency into the path and therefore solutions attempt to reduce that latency by taking on some of the functions normally associated with web/application servers. Some of these functions are:

1. SSL processing

By offloading SSL processing and bulk encryption/decryption to a hardware-acceleration solution, the total time required to process SSL is reduced.

2. Compression

Compression sits in both camps (reduction of data and offloading) because compression can be - and often is - a function of the web/application server. But it is often the case that an application acceleration solution can perform the task faster and much more efficiently than the server.

3. TCP Session Management

Managing TCP connections takes time, and application acceleration solutions offload much of that time by reducing the total number of connections required to the server and reusing them as often as possible. This makes the process of exchanging data between the server and the application acceleration solution much more efficient and reduces the total time required to deliver data to the client.

We are unlikely to ever be in a situation where there is a straight line between the client and the server, which means multiple hops must be traversed in order to deliver data (i.e. applications) to clients. Because we know that every hop has a cost, one of the best ways to reduce the cost associated with those hops is to reduce the amount of data being exchanged and let the most efficient "hop" in the network perform specific tasks.

And while it won't be the shortest path through the "network", it may well be the "fastest". And when it comes to your users you can be sure they aren't counting hops, they're counting time.  

Imbibing: Coffee

One of the problems with having kids and Internet access in the same house is dealing with the problem of someone duping your kids into believing they are someone they aren't. And it's not just predators that you have to worry about; kids are devious, they know they can pretend to be someone else (and often do) on the Internet and thereby mess with their friends' heads.

One of the reasons it's so easy to socially engineer someone else into believing you are whoever you want to on the Internet is that there's no real way to verify identity. Now I can't think of a way to do that given today's technology, but I do think that we could put a stop to some of the intential abuses of anonymity in IM clients. Experience says it is too easy for someone to claim to be "John from Ohio" when he's actually "Ed from Oregon" and it would be nice if kids - who are too often willing to believe anyone on the Internet - had some kind of simple mechanism that would give them a clue as to who is being honest and who isn't.

A simple way to resolve this particular issue, I would think, would be to add a function to IM clients that determines location based on IP. Yup, geocoding. Yes, there are anonymizers that blow geocoding's usefuless out the window, but for the most part simple geocoding would provide a good idea of when you might be being had and anonymizing is more difficult with IM than it is with web browsing. Originating IP addresses don't, for the most part, lie unless you're really good. And I'm guessing that most people who are trying to use IM as a social engineering platform aren't that good. So it would almost certainly put a stop to teenagers trying to impersonate other people from around the globe in order to "mess with their friends" when the geocoding information clearly shows they are in the same city as their "friend", and it'd probably catch "Ed from Oregon" pretending to be "John from Ohio". At least as far as location goes - names, that's another story.

Yes, I realize that travel makes this less useful in general but I'm not all that concerned, as an adult, where another adult may be. We're primarily focused in this case on providing a mechanism that can help us, as parents, identify potential social engineering attempts that target our children. And not only identify them but prove it to our children, who are too often certain that they aren't being had when, in fact, they are. Besides, anyone old enough to travel a lot shouldn't be chatting with my 15 year old daughter; that's exactly one of the cases we're trying to catch.

Because of the way IM works, IM servers could add this info to the info the collect about users when they login and send it with the other general info to buddies or it could be something added directly to the clients.

Maybe this already exists and I'm just not up enough on IM clients, servers, and extensions to know about it. If it does exist - that's awesome, where can I get it? If not, well, someone get on that, okay?

Imbibing: Coffee

Sometimes it seems that all we do is listen to complaints - about application performance, about security policies, about broken web sites, about the need to track a single HTTP request across 4 different systems and 9 separate - and uncorrelated - log files. It's overwhelming, at times; this complex web of technology that takes up most of our time and attention during the day and, for some, the night as well.

In the midst of all that rushing around just stop for a minute and look around you. Look at all the blinking lights, the cables that connect you to the outside world. Listen to the servers humming, the clickety-clack of someone typing.

Now think about everything that has to be working just right in order to get a packet from Point A to Point B. Consider all the people, products, and technology that went into buildling the infrastructure, the physical hardware, the applications, the operating systems, the drivers, the network processors, the cabling. Consider the amazing depth of amassed knowledge that is required for to even have the opportunity to complain about it in the first place.

Really think about how amazing it is that we can transmit messages, pictures, video, music, and text using light and electrical signals. Think about how incredibly awesome it is that for the majority of the time it all works correctly. The fact that the Internet works most of the time is nearly as overwhelming as the ginormous effort and knowledge it took to build it, and continue building it.

So go ahead, whoever you are, and pat yourself on the back. You are almost certainly one of the people who keeps things in the incredibly complex set of internetworks working on a daily basis. It might even put a smile on your face to know that you're part of a pretty amazing system without which businesses - and people - all over the world would be somewhat paralyzed, at least during business hours. If you think about what that means, how Herculean that task really is, you too might become a little overwhelmed and amazed that it almost always works as it should.

At least until the next time your beeper goes off.

Imbibing: Coffee

I didn't say it was your fault, I said I was going to blame you.

When the issue of application performance rears its ugly head like some kind of ancient dragon hell-bent on destruction (yours) it is often the application developer that ends up shouldering the blame.

It's also often the case that neither the network admin or the developer can do anything to banish the evil dragon of poor performance. That's because sometimes the fault lies somewhere between the network and the application, in the murky middle layers of the OSI stack - above the network layers.

And that's exactly why the developer is often left standing alone to deal with the problem, as if he's the poor village sot who drew the shortest straw in the quest to stop the dragon.

But because the problems are often below the application layer, there isn't really much a developer can do. It isn't the code, it isn't the web or application server, it isn't even necessarily the operating system. In fact, it's probably the case that everything is working exactly as it should be despite the angry cries coming from users who believe they could write out orders by hand and mail them in faster than the application they're forced to use.

TCP, as it's defined, is not a very efficient protocol. It was designed to provide reliable delivery of messages and is therefore quite insistent that it do so, regardless of the potential impact on performance. Using a variety of techniques including window sizing and a (some would say excessively) thorough acknowledge protocol, TCP ensures every packet is received. Therefore it can be performing exactly to specifications and still impede application performance.

And there's nothing the developer can really do to change that. It can't be changed by the code, or by web/application server settings, and there are only a few operating system level modifications that can be made to improve the behavior of the TCP/IP stack. And there's also not really anything in the routing and switching infrastructure that can improve the situation. Somehow TCP has to be made to be more efficient, and that's not something that either group can accomplish without some assistance.

This is where application delivery solutions can help. Because an intelligent application delivery controller sits in the middle, a proxy between the client and the server, it can "muck" with TCP and make it more efficient. For example, F5 BIG-IP implements a highly optimized TCP/IP stack called TCPExpress. TCP Express implements (and improves in some cases) many of the performance enhancing RFCs (Request For Comments) related to TCP such as:

• Delayed Acknowledgements, Nagle Algorithm – (RFC 896, 1122)
• Selective Acknowledgements – (RFC 2018, RFC 2883)
• Explicit Congestion Notification ECN – (RFC 3168, 2481)
• Limited and Fast Retransmits – (RFC 3042, RFC 2582)
• Adaptive Initial Congestion Windows – (RFC 3390)
• TimeStamps – (RFC 1323)
• Improve TCP TIME-WAIT Assassination Hazards – (RFC 1337)
• Improve TCP Congestion Management – (RFC 3168)
• Improve TCP Slow-Start for TCP with Large Congestion Windows – (RFC 3742)
• Appropriate Byte Counting – (RFC 3465)
• Improve TCP Fast Recovery Algorithm (NewReno) – (RFC 3782)

Each of these implementations is designed to improve the performance of TCP/IP and thus improves the performance of TCP/IP based applications (99% of all web applications fall into this category). These performance-related enhancements improve the situation on both the client and server side of the equation, because a full-proxy solution mediates absolutely between the two, giving it more control over the behavior of TCP/IP.

There's no code to change in your application, no modifications to router and switch configurations, nothing. A full-proxy application delivery solution can transparently improve the efficiency of TCP/IP and immediately provide performance benefits to all managed TCP/IP based applications.

So the next time someone is blaming you - whether it's your fault or not - for poor application performance, consider whether the problem might really lie within the realm of "things not under our control". And if that's the case, remember that you can get it under control by adding an application delivery solution to your infrastructure.

Imbibing: Coffee

I had several requests for access to my presentation at Web 2.0 Expo. Today, the fine folks at O'Reilly indicated that the presentation is now available for download.

Enjoy!

Imbibing: Mountain Dew