So I’ve created a new blog: datacenteroverlords.com. This deals with all the issues surrounding the modern data center, such as virtualization, networking, storage, and of course load balancing. The name comes from the new role that’s forming around the multiple disciplines involved in data centers. Some call it the data center admin.

Behold my mighty data center!

I prefer the term “Data Center Overlord”.

I’ll likely be blogging there exclusively now.

The fact is, we’re more addicted to cookies than even Cookie Monster

Came upon this post on Slashdot.org, a criticism of HTTP cookies entitled “HTTP cookies, or how not to design a protocol“.    It goes into many of the security issues surrounding HTTP cookies, and how the popular criticisms (privacy) aren’t the real problems.

The problem is, HTTP cookies are absolutely vital to everything we do on the Internet. Any website that we visit where the server builds up customized content (even if it’s just selection which region we’re from, like on Fedex.com), depends up on cookies.

Want to play a nasty prank on a co-worker who doesn’t lock their screen when they leave their desk?  Disable cookies on their browser.  Nothing works.

Cookies are just about the only mechanism in use to create a unique relationship between a client and a server. In other words, a cookie is the only way to establish a session.  Other than cookies (or long URLs), the HTTP protocol does not

In the end, we’re worse than cookie monster with our cookie addiction.

Systems supporting only snort rules and lacking a positive security model are not usually not considered a web application firewall, but rather an intrusion prevention system.

Which is an interesting question: What is a Web Application Firewall exactly? How does that differ from an IPS (Intrusion Prevention System), and is there any meaningful distinction between the two?

Amazingly, Wikipedia doesn’t have an exact definition for Web Application Firewall (just Application Firewalls, but that’s something a bit different).  But here’s the definition of “Web Application Firewall” according to OWASP:

A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as Cross-site Scripting (XSS) and SQL Injection. By customizing the rules to your application, many attacks can be identified and blocked.

I think the KEMP box qualifies, but the range of devices that qualify are vast.  While the KEMP box has WAF capabilities, it’s clearly an entry level box ($2,500) while the Breach box is higher end.  It’s like the difference between the KEMP LoadMaster and F5′s LTM/BIG-IP: They’re both Application Delivery Controllers, but they’re clearly not in the same league or market.  And that’s fine, if all we had were high-end load balancers, the SMB would be squeezed out.  I’ve not tested a Breach box, but I wouldn’t doubt that they offer superior protection.  It’s just a matter of whether the customer can afford it.  The world needs BMWs as well as Camrys.

What do you think?

Other than bragging about my nerdrunning abilities, this post is also to see what tools are out there that people use in terms of HTTP analyzers.  The two I commonly use are listed below:

• Firefox: LiveHTTPHeader
• Internet Explorer: ieHTTPHeaders

Now, given that you’re reading this on a web server, and there are obviously millions of websites, you may be asking yourself what the heck is he talking about?

I think what we consider web servers are actually application servers. I’ll ‘splain.

The server that lbdigest.com sites on runs the web serving software Apache. However, it also runs PHP, which combined with Apache forms an application server. Blogs, Wikipedia, webmail, photogalleries, social networking sites, they’re all applications.  Web serving is the easy part, but a web server (Apache, IIS, etc.) is pretty useless by itself these days.  Application platforms such as PHP, ASP, Java/Tomcat, .NET, etc., give the web its power.

It used to be that major websites had a 3-tier architecture.  You had web servers, app servers, and database servers.

3-Tier Architecture

I haven’t seen that in a while.  Most everything nowadays is a 2-tier architecture.  The web and app layer are combined, although the database server is still typically separate.

2-Tier Modern Architecture

In the case of lbdgiest, web/app/database are all on the same server.  So while calling this server a web sever isn’t inaccurate, a more accurate description would be that it’s an application server.  I think you’d have a hard time finding a web server on the internet that isn’t also an application server.  After all, when is the last time you saw a static web site?

1997 called, and they want their static web page back.

But it made me think to the last time I came across a Sun machine. I think in the past 3 years, I must have professionally logged into one Sun machine and configured around a dozen Sun servers to be load balanced. Meanwhile, I’ve logged into dozens of Linux and Windows machines and configured load balancing for many more.

I started out in the server world, Solaris mainly (Solaris 2.5.1, what a treat), and as Linux gained acceptance, Linux as well. I tried to stay away from Windows systems, but that’s darned near impossible now, so I’ve pretty much embraced Redmond. Getting into load balancing, and its networking entanglements, was purely by accident.

It’s disheartening, really. In professional services, in the enterprise, Fortune 500, and even SMBs, I don’t see Sun around like I used to. In fact, I rarely deal with them anymore. It used to be I had to have the Solaris NIC tuning scripts memorized to get them going on full duplex (because you’d think that auto-negotiate in Fast Ethernet would work, but you’d be wrong).

Sun used to have its own ecosystem, where thousands found gainful employment working in the incestuous Sun world, but I don’t think that’s really the case anymore. There was a time when a Sun certification meant something (not that I ever got one), but while I don’t think they can hurt, a Sun cert probably doesn’t go as far as it used to.

I’m sure there are many Sun installs in place and going in place, but it’s clear deployments are a fraction of what they used to be. I miss those hulking, noisy beasts.

Some of the results I felt warranted a few comments, so I’ve written a few up.

Question 1:  Which load balancers do you use?

The first question was a multiple-select question (responders could select more than one applicable option), which was simply “What load balancers do you use in your environment”.

It was no surprise that F5 BIG-IP V9 came out as number one, with 30% of respondents saying they used BIG-IP V9 (BIG-IP V4 was a separate option). Second was also no surprise, with Alteon. While Nortel hasn’t kept up with most of the other vendors in terms of product evolution, there is still a strong install base as well as a vibrant eBay market for used gear.

The big surprise was Foundry coming in a close third, with 23% of all respondents using Foundry in their environment. Personally, I’d written them off in the L4-L7 world. Since then, I’d learned they’re making somewhat of a resurgence, at least in terms of marketing push. What I’m not sure about is whether this 23% represents a previous install base, or a new install base resulting from their new push (or some combination there-of).

Cisco CSS (the old ArrowPoint boxes), F5 BIG-IP V4, and NetScaler rounded out the next tier.

On the value market load balancers, Coyote Point had 2 responses, Barracuda had 1, and KEMP had none. So this tells me this site and my mailing list isn’t really reaching the value market user, although that’s been changing very recently.

While most were happy with their current vendors, many had switched vendors in the past.

Question 11:  Which features are most important to you?

This one was very a very insightful look into the mind of the load balancing consumer. Not surprisingly, Gigabit Ethernet was the most commonly selected feature, although I wouldn’t have guessed it would be number 1.  This was followed by cookie persistence and SSL acceleration, also expected.  What was somewhat surprising was that the next most commonly selected feature was programming rules (such as F5′s iRules). Only a couple of the vendors have this, and while the barrier of entry is higher than most of the other functions of a load balancer, this would seem to indicate that this would be worth the investment.

Question 13:  What application platform do you use? 

I had somewhat expected this, but it was still pretty surprising to see how many different platforms were in use.  It just underscores that everyone’s environment is unique, and it’s not possible to cookie-cutter the application world.

Question 14: Do your applications require persistence?

I’ve heard arguments against having stateful applications before (where state information is stored only on one server, and not shared amongst a cluster of servers).  But the fact is from this survey and my own anecdotal experience, most applications deployed are stateful. I think the reason is that most application platforms operate this way by default.  Built-in session handling in Java, PHP, etc., can be bypassed with a home-grown stateless implementation, but that would be fairly involved.  It’s just much easier to write a stateful application, and slap some cookie persistence in there.  And in question 15, we see that cookie persistence is overwhelmingly the choice of persistence.

Question 18: Do you utilize your load balancer for SSL termination and/or acceleration? 

I knew a lot of sites did, but I was surprised to see it was 70%.  HTTPS is becoming commonplace, and it’s much easier to deal with the issues of SSL (persistence, cert management) with a load balancer.

Question 22: What type of work do you do primarily?

I honestly had no guess on how this one would end up.  It turned out to be pretty even, with a slight bias to network realm.  But the high number of dealing with both underscores the ever blurrier lines between Layers 2-3 and Layers 4-7.

Take a look at the results, and feel free to comment with your own interpretations.  Vendors are of course welcome as well.

I don’t know of any companies that don’t offer Layer 7 capabilities at this point, and if there are, they’d better get Layer 7 soon. Especially if Layer 7-capable devices don’t cost any more than non-Layer 7 devices, why get a Layer-4 only device?

This is especially important considering my recent post “A Load Balancer By Any Other Name…” and the email debate on the load balancing mailing list. Layer 4-only devices don’t really exist anymore, everyone has moved up the stack.

Layer 4 load balancing is dead. Long live Layer 7.

OK, so I didn’t invent them. And I wasn’t the first to treat them as separate markets, but that’s neither here nor there.

“Premium market” or “enterprise market” is pretty apt for the market defined as catering to Fortune 500, dominated by vendors like F5 and Citrix.

But I’m struggling with the term “budget market”, because it has something of a negative connotation. Originally, it was the SMB market. But let’s face it, the term SMB is a snoozer. Budget sounds so very… generic brand dish soap. But that’s not what that market is. It’s more like comparing a Toyota Corolla to a BMW 7-series. Both are quality cars, but one has a nav system, heated/chilled seats, and tons of other fanciness that are great but tend to really jack up the price. They are cars for two separate markets, and there’s no use chastising one or the other.

So I went through a few names, and here is what I had considered:

• Yugo Market
• Happy fun-time market
• Generic Brand Market
• Awesome Market
• Proletariat Market
• Value Market

Value market seemed to be the better choice, which came up in a conversation I had recently. It’s not overly snarky, and it doesn’t have any of the negative connotations that the term budget might have.

So I dub thee, the Value Market.

The reaction to such a seemingly innocuous subject was actually the most impassioned discussion the mailing list has seen in nearly 7 years of operation. Many of the vendors weighed in, and their position is fairly unified: They call these devices “application delivery devices/platforms/etc.”

There wasn’t much from the user side in this discussion, but I’ve talked with many, many users and load balancing administrators. In my day to day environment, I work with the premium products exclusively. On the side, in writing, and answering emails from various users, I primarily deal with the value market. In either case, the consumers, users, and the periphery (those that don’t deal with load balancers directly, but their operations are affected/serviced by load balancers), almost exclusively call these devices simply “load balancers”.

The vendors argument is understandable: These devices (especially from the higher-tier vendors like F5 and Citrix), do quite a bit more than just load balancing (although they still do load balancing). TCP multiplexing, application security, compression, caching/web acceleration, SSL termination, and they’ll babysit your kids.

But here’s my argument: While these devices do a lot more than what were first called “load balancers” from the late 90′s, but they’re still load balancers. They serve the same basic function (albeit with a lot more functionality) and sit in the same place in the network. The term load balancing is ambiguous, but so is application delivery. The difference is, most people know what load balancers are, and not many know what type of device the term application delivery entails.

Also, I don’t know of anyone who’s ever been confused by the term “load balancer”, thinking it meant a simple, Layer 4-only box. From feature-rich F5 to a Linux Virtual Server box, they’re both called “load balancers” by those that deal with the technology. If anyone has a need for any more specificity, they use the vendor’s name.

There really aren’t any Layer-4 only devices anymore. Even in the value market, where vendors are more likely to refer to themselves as load balancers, the devices perform Layer 7 URL parsing/switching, cookie persistence, and more.

So I understand the desire to differentiate, but the proposed terms are only slightly less ambiguous as the load balancer term, and are far less well known. So myself and others in the industry continue to call these devices “load balancers”.