Love is the Enemy !!!

Well, I am certainly not talking about Nick Black’s song and I am certainly not against love. Then what is this you ask? While I let you think about what this blog is all about, go ahead, listen to the song anyway

Now this is about indeed about a “different kind of love”. Today, we talk about the scaling of our environments. Not all of our IT environments are actually scalable in every way. Network is perhaps the most scalable thing that you would see in the IT infrastructure today, if we think for a moment as to why is that, why can a 300 MHz CPU, 256 MB RAM, with virtually no storage outperform an application running on tens or hundred's of beefy servers?

Why can network components handle tens of thousands of connections which hundreds of servers have a tough time processing. (I know some of you might be going… Err! … Servers actually have to process it, and not just forward it! )

The answer lies very simply and plainly with us. “LOVE”, what I actually mean by this is basically when the network component sends out packets, its doesn’t actually care if the return / reply was sent, when was it sent, was it sent at all, through where was it sent, did some one else process the return packet so on and so forth. This gives them immense speed and scalability.

On the other hand applications sit and wait for the packet to return, these connections keep their memory occupied and hence there is delay, new connections are not taken in that easily, etc. There by making scaling very very difficult.

Now, since the scaling of applications are difficult, so is taking them to cloud, cause cloud is all about scale and not about state.This possibly was one of the few reasons for the cloud and the fact that compute is one of the first things in the cloud.

Even while moving these application to the cloud, we see this as a challenge, if the application is all about state, they are still not able to use the full potential and benefits of the cloud, so now naturally the next question arises, how should these applications be designed for speed. Again the answer is a single liner.

If you can, then have the application as event based and NOT state based, which means, the application execution should be completely asynchronous, it makes a call and forgets about it. When the response arrives, it triggers a event, the application picks up the event, recalls what it was and continues processing. Off course this cannot be done for all the applications, but most of them can work in this way, all it needs is basically the application would require some sort of web service or equivalent for the other systems to trigger off events.

So, that’s it folks, I leave you with this thought, if you have comments, I would love to hear them!


Popular posts from this blog

HA Proxy for Exchange 2010 Deployment & SMTP Restriction

Juniper Aggregate Interfaces (LACP/No LACP)

Configuring Multicasting with Juniper EX switches (Part 1)