I won't write about tricks with GridGain today. I just want to talk about grids, both data and computational ones.
Recently I was asked about their applicability when talked about grids. The question was "Why should I use it. I think grids are not for our application. We don't compute anything." And I understood how far we are from the people who write their applications.
And I think it's time to explain grids. Regardless the vendor (GridGain, Gigaspaces, Terracotta or Hadoop ...) grids are intended to make application robust, flexible, scalable and reliable.
When you start coding any kind of application you hardly ever think about the fact that in most cases your requirements will be changed when you finish development. The number of users/requests will be increased 10 or even 100 times and you would have to change your code and hardware. Your would have to buy another license for the application server that you use. Of course there is a LAMP and "cool" developers use it but don't you think that there are plenty of companies which don't use Perl or MySQL?
So what do you do to make your application reliable? Scalable? Use EJB or any other container specific features, may be web-services. You have to pay for the license, you have to set up and administrate application server cluster and define load balancing, database access, deployment schema. But let me ask you what would you do if you need to execute your code on the same box where data are located? You would deploy your code there right? The answer is no. This is not quite correct. Data could be moved from one Database box to another and you should spend a lot of time to reconfigure your cluster.
This is nightmare, believe me I saw it and worked with such systems.
Grids are the cure in most cases. They give us another development model especially if you use Spring or Spring-like frameworks to configure entire applications. Whatever grid you use it gives you the way to join computational tasks (your code) and data (data grids) together and execute code on the same node where data are.
You should not even think about deployment in most cases (For example GridGain allows you not to deploy your code - it will be deployed at runtime).
So you need to define set of different jobs and probably let grid know what kind of data they need. That's all. Grid will deploy, balance the load, provide failover and thus reliability, scale your application and in most cases it is free.
So what would you choose application servers or grids? Or both of them?
Recently I was asked about their applicability when talked about grids. The question was "Why should I use it. I think grids are not for our application. We don't compute anything." And I understood how far we are from the people who write their applications.
And I think it's time to explain grids. Regardless the vendor (GridGain, Gigaspaces, Terracotta or Hadoop ...) grids are intended to make application robust, flexible, scalable and reliable.
When you start coding any kind of application you hardly ever think about the fact that in most cases your requirements will be changed when you finish development. The number of users/requests will be increased 10 or even 100 times and you would have to change your code and hardware. Your would have to buy another license for the application server that you use. Of course there is a LAMP and "cool" developers use it but don't you think that there are plenty of companies which don't use Perl or MySQL?
So what do you do to make your application reliable? Scalable? Use EJB or any other container specific features, may be web-services. You have to pay for the license, you have to set up and administrate application server cluster and define load balancing, database access, deployment schema. But let me ask you what would you do if you need to execute your code on the same box where data are located? You would deploy your code there right? The answer is no. This is not quite correct. Data could be moved from one Database box to another and you should spend a lot of time to reconfigure your cluster.
This is nightmare, believe me I saw it and worked with such systems.
Of course application servers provide standard access to the features like JMS / JMX / JNDI / Databases and so on and grids don't implement them but in most cases you don't need those stuff and more of that usually you can start grid inside your favourite Application Server or Web Container (like GridGain does).
Grids are the cure in most cases. They give us another development model especially if you use Spring or Spring-like frameworks to configure entire applications. Whatever grid you use it gives you the way to join computational tasks (your code) and data (data grids) together and execute code on the same node where data are.
You should not even think about deployment in most cases (For example GridGain allows you not to deploy your code - it will be deployed at runtime).
So you need to define set of different jobs and probably let grid know what kind of data they need. That's all. Grid will deploy, balance the load, provide failover and thus reliability, scale your application and in most cases it is free.
So what would you choose application servers or grids? Or both of them?
0 comments:
Post a Comment