Link Details

Statements like "...your reasons for NOT clustering have vanished, so there’s no excuse. Cluster. Now" make me cringe. How is that for a crappy advice?

I say: Do NOT cluster, unless you are perfectly sure you need to, and why you need to. And the need is not going to be one of scalability. There are other ways to scale, without the complexity in the app and in the setup.

I agree - clustering is not just for scalability. But I bet Wal-Mart.com would have trouble on a single Dell machine. For some huge sites, clustering is the only way. For other smaller apps, even two JBoss app servers clustered on the same litlle Celeron machine will give you the ability to deploy anytime day or night with no outage- that benefit is for every app, big and small.

You have some config files to change, but your app should not have to change at all (except for design upgrades). Even Tomcat 6.0 can be clustered for free in no time. And Terracotta makes your app clustered with zero-changes to your app. If you're a software pro - cluster your app.

"..If you're a software pro - cluster your app..", please, come on. Be just a bit serious here.

And it is not like if you don't cluster, you will have to live on one single dell machine, right. You can have lots of application servers taking the load. It might be true, that "For some huge sites" they need a cluster (maybe), but my bet is that 99,9% of the webapps written around in the Java world aren't gonna take that many hits. Sure, there is amazon and there is google and there is yahoo, but they are the exception. And they might need clustering. But I also believe, that amazon has not gone with a clustered tomcat, but with a homegrown solution, that does the job for them.

About what to change in the app. It depends. If you want the full monty from your clustering, in that, if an ongoing request to a server that crashes shall be retried on another server to keep the fail hidden from the client, you WILL have to write your app differently.

So, I still think, that the general advice to always cluster, is quite misleading.

I agree that the article is overzealous and wanted to vote down for that reason alone. But then again, I voted up because everyone on this thread saying, "don't cluster, there are other ways to scale" I think have been misled. If you say, "don't cluster, it is hard," then sure. But if you claim there are other ways to scale, you are playing a semantic game. Cluster the app. Cluster the DB. Buy more HW for the app (scale it up). Buy more HW for the DB. You are either buying bigger machines, or you are sharing state across processes.

I think the only logical way to scale w/o clustering at some layer or another is to partition / shard.

With all this in mind, the article does not in fact mislead at all.

My $0.02.

Cheers,

--Ari

"...I think the only logical way to scale w/o clustering at some layer or another is to partition / shard. "

You are quite right here.

What I am against is the advide to always cluster by default. I think everyone should consider their needs. In the, rare, circumstances where clustering is needed at some layer, one should carefully consider at which layer, to do it.

I don't know if I agree with the premise of "always cluster", but after clustering the rather large and poorly written app I'm working on with JBoss and now having an environment where I continuously integrate to that never goes down, it's hard to make an arugment against it. A couple hours worth of work is all it took, but that benefit alone is pretty huge.