Apps
Contact
Seminars
RSS FeedSeptember 27th, 2009
Clustering vs. Load Balancing – What is the difference?
These 2 terms – clustering and load balancing – are used in the same sense by a majority of IT people with relative impunity.
Clustering has a formal meaning. A cluster is a group of resources that are trying to achieve a common objective, and are aware of one another. Clustering usually involves setting up the resources (servers usually) to exchange details on a particular channel (port) and keep exchanging their states, so a resource’s state is replicated at other places as well. It usually also includes load balancing, wherein, the request is routed to one of the resources in the cluster as per the load balancing policy.
Load balancing can also happen without clustering when we have multiple independent servers that have same setup, but other than that, are unaware of each other. Then, we can use a load balancer to forward requests to either one server or other, but one server does not use the other server’s resources. Also, one resource does not share its state with other resources.
Each load balancer basically does following tasks:
- Continuously check which servers are up.
- When a new request is received, send it to one of the servers as per the load balancing policy.
- When a request is received for a user who already has a session, send the user to the *same* server (This part is important, as otherwise user would keep going between different servers, but not able to really do any work). This part is not required for serving static pages, in that case, there are no user sessions.
What does it mean from a user’s perspective? Which one is better?
Every time some one asks a generic question – which one is better, the answer is invariably “It depends”. This isn’t political equivocation, but simply restating the fact that if one was better than the other in all circumstances, then the other wouldn’t exist.
Clustering saves the user’s state, and is more transparent to the user, but is harder to setup, and is very resource specific. Different application servers have different clustering protocols, and don’t necessarily work out of the box (don’t you believe any of that marketing fluff). Load balancing is comparatively more painless, and relatively more independent of application servers.
From a user’s perspective, it means that if the user is doing something on the application, and that server goes down, then depending upon whether the system is doing clustering or load balancing, the user observes different behavior. If the system is clustered, the user may be able to continue doing the transaction, and may not even realize that the server has gone down. If the system is load balanced without clustering, that means that the user’s state will likely be lost, and the user will be simply sent to the other server(s) to restart transaction. The user has lost some work.
Hopefully that clarifies it somewhat.
A (soft) joke
I doubt if one article can clear years of misused terminology. The saving grace is that, it may give us one more of the soft computer science jokes that geeks can fall backwards on, the refined geeks scoff at, and no one else understands:
Q: Are you doing clustering or are you doing Load Balancing?
A: Yes.
September 20th, 2009
YAGSC (Yet Another Grails Struts Comparison)
I have recently been inundated by emails about Grails (mostly good, some neutral, some outright complaints), even though my email inbox isn’t much different from a certified black-hole. The great divide seems to be part philosophical and part technical. There are already quite a few technical comparisons of Grails vs. Java/Struts out there, such as: CompleteOpenSource, Nabble and StackOverflow, not to mention the big comparison over at JavaOne, but some of the philosophical issues seem harder to tackle:
- Unsubstantiated Claim #1: Hesitation to move to Grails is really an unwillingness to learn anything new on part of Java developers.
Really? This is a subjective claim, and I am sure it is going to be neither true nor false. But my personal experience on this issue suggests that Java developers do not want to learn Grails simply because they want to focus on solving new problems, not focus on solving new problems in a new way! It is the “new problem” that is of interest to them, not the “new way”. One could argue that “new way” can make things much faster for them, but the Java developers frequently argue back that business (and not technical) problems are the ones where they are spending the time, so the “new way” isn’t likely to change much in that case. This represents an implicit high level of maturity in Java/Struts based enterprise systems. - Claim #2: Grails is easier for development.
Java, since its day one, has been known to be harder for development than say VB. Still, that has not stopped Java from progressing and reach dizzying heights. So, what does that teach us?The language/framework needs to be easy to develop, and scalable/efficient to execute/deploy. Which of these two attributes is more important – that is an inane question. Can you turn one knob up and the other knob down, and come out better? I don’t know.With Java/Struts, apparently, the difficulty in development was not a show stopper. If Grails promises to ease development, but is even an epsilon less scalable, that already makes it a partially ordered set. In fancy terms: Grails, in that case, is not a Pareto optimization over Java. In layperson’s terms: win some, lose some. - Claim #3: Grails doesn’t have the same security of compile time checks.
The bad news is that for a production system, this isn’t so good. The good news is that by integrating unit tests, the impact of this problem can be minimized. - True, but pointless Claim #4: Convention over Configurability.
This one is surprising. Grails lovers claim CoC to be a big plus. Java developers don’t see why this should be a reason for celebration at all. Configuring a project takes very little time these days, and if you do that, and retain the choice of configurability, then should you be interested in something that takes 10 less minutes to setup, but is not as configurable?
Obviously enough, jury, is still out on this one.
September 15th, 2009
XMarks
This is one browser extensions that I find very helpful. It is such a simple add on, but keeps the bookmarks on my home PC, work PC, laptop, netbook all synchronized. I just discovered that it now frees me up to organize my favorites wherever I am. Earlier, I would avoid organizing my favorites knowing very well that I also have to do it at 3 places, so inertia had a value. Now, being organized has a value, and I love it!
Here is the link to xmarks: http://www.xmarks.com/
September 11th, 2009
Strunk and White’s Golden Rule
In The Elements of Style, Strunk and White make one of the most obvious, yet one of the most overlooked rules in English – be concise!
I just reviewed a company brochure, and after 3 iterations with the pained writer, finally got them to cut down the introduction from 4 pages to half a page. Boy, it feels good.
September 7th, 2009
Skype is loose! YouTube is Next?
I do feel good when my predictions come correct. 
eBay decided to let go of Skype! To me, the merger never made any sense. But, I am pleasantly surprised to find that eBay didn’t lose that much money after all. It bought Skype for 2.6B, invested about 0.6 B in it over 3 years, then sold it for 2 B, but kept a 35% stake. So, considering an investment of 1.2B, if Skype, as a new found company manages an annual profit of about 360M, eBay should be OK. That seems like a stiff target, but doesn’t sound like a bad deal overall.
The big question is, is YouTube next? I wouldn’t expect to see anything before 2010 Q4, or perhaps 2011, but it would make sense to me if YouTube were a separate business from Google.