A Grid for Every Application
What can I tell you about the attributes of the perfect application for a Grid environment? Or, should you be asking about the perfect Grid environment for your application? As much as you would like these two questions to lead you to the same answer, they rarely, if ever, do. In this article, I will discuss what I like to call the Application Grid—the perfect Grid setup for your application. I am staying away from the term "virtualization" because it is too abstract, and means different things to different people.
Round and Square
Putting your application on the Grid is like trying to fit a round peg in a square hole. Anyone who tells you otherwise is sugarcoating the truth!
Click here for a larger image.
Figure 1: The ultimate Dilemma
Why is this so? Your application is flexible, adaptable, simple to grasp, manageable, and most importantly—controllable by you! If your application, for example, requires access to a database, it is as simple as using O/JDBC to connect to a remote database. You don't really need to worry about where in your code you connect to the database, how you manage the connection, and so forth. You can connect at the beginning of your application, use the connection while your application is running, and close the connection before you exit. You don't really need to close the connection, do you? How many times you said to yourself, "it's okay—the connection will timeout eventually!"
The best part is that the handful of developers who wrote the application know exactly what to do or, more importantly, not to do to make the application work. The best analogy I can give you is the classic TV antenna scenario that existed before you got cable TV. You knew, for each channel for a given time, where to point those rabbit ears to get the best reception. The reception might have not been perfect, but you had some control. Let me ask you a question: What do you do now when your cable or satellite TV reception is not good? Do you call the cable company and ask them to move the satellite until your reception clears up?
Finishing Each Other's Sentences
Deploying applications in a distributed environment, and Grid, the most distributed of them all, is like trying to finish someone else's sentence without knowing who that person was or when they finished speaking! Not that easy, is it?
Why is this so? Well, it's simple; because it is in a distributed environment and by definition, you may not and most likely, do not have instant accessibility and control over all the distributed pieces. If one part finishes (an event occurs), you don't really know so until the notification of that event (a message) reaches you. If you never receive the message, you don't know whether the message was lost, or that event never took place. To make matters worse, in a Grid environment, you have a heterogeneous infrastructure  in which you may have old servers, new blades, different types of OSes, and so forth. What ends up happening most of the time is that an application that was written for a single-CPU environment gets distributed, and all of a sudden you have tons of bugs and issues to deal with. The infrastructure did not introduce these bugs into your application; it simply made them more apparent and visible. I don't claim that I have a solution to this problem; nonetheless, it needs to be stated. This is a problem that exists; I am simply stating the facts.
I wanted to start this section with the following [radical] claim:
"There exists a Grid environment and setup for every application; it's just a matter of finding the configuration that best fits your needs."
How is this so? "Grid-enabling" is simply done by adding a layer of management and provisioning to your application. This is something you have to and you do today; all grid-enabling does is to automate the process. Again, I wanted to draw an analogy with the EAI era. You picked any application and qualified it as an EAI project. Very few applications did not qualify for some sort of an EAI-type project. With Grid, it is the same story. Given proper management and virtualization environment, you could Grid-enable any application. The trick is that the infrastructure must be adaptive and allow a range of configuration and optimization options.
Each application behaves differently on the Grid; some applications may benefit more than others, but what all applications have in common is the amount of effort that it takes for Grid-enablement: none-trivial! There is no pill you can swallow; there is no magic wand; there are only guidelines and best practices. The goal is to look for patterns in the infrastructure and in the application to guide you in this process. Below is a list of checkmarks or application attributes that you can refer to determine the applicability of a Grid solution.
Table 1: Grid-enabling application checklist
|The application has distinguishable and discrete work units||High||Think of the classic SOA model. You need to be able to specify when one unit of work starts and when it finishes.|
|The application is composed of repetitive work units||
|This is a workflow model of a Grid. You can parallelize at the workflow level as opposed to work-unit level.|
|The application requires external components||Medium||Database, various system access needs, and so forth. This will be a balancing act between the security and flexibility of the Grid infrastructure.|
|The application has SLA requirements||High||This is almost given. Any application requires a certain level of SLA; the Grid must be able to accommodate this per application.|
|The application needs or requires scalability||Low||This is a surprising one to most. Your application may be one client and service, and that is all. The reason that this application may be considered for the Grid may be to meet SLA, or other requirements.|
|The application requires management automation||
|This is the primary and the most important reason why an application should be considered for the Grid.|
Page 1 of 2