Posted:
Updated: June 28, 2016
When thinking about how Grid Computing software can be architected there are many angles one can look from. One such angle that is rarely seen is whether to consider the software architecture from the "Resource" point of view, or from the "Task" point of view.
As much as abstract it sounds this question is rather very fundamental to how your Grid Computing software will be used. Let me explain by starting with some loose definition of these two different views.
When taking a "Resource" point of view you are basically implying that the task that is executing on the grid is "dumb". Such task knows how to execute itself and usually that is about it as far as any interesting behavior. In this scenario the "Resource" (i.e. software that manages the task execution such as resource manager, task scheduler, failover manager, task loader, etc.) is a king as it decides where, how and when task gets executed. Most of the current Grid Computing software falls into this category.
Alternatively, if one takes "Task" point of view, the task itself becomes much more intelligent as it now "knows" where, how and when it gets executed. Symmetrically, the role of "Resource" becomes much simpler.
We at GridGain Systems, Inc have chosen "Task" point of view from the beginning for a number of reasons. In retrospect, I view this decision as one of the two most important ones (another one being AOP-integration). Let me list these reasons as they are interesting on their own:
"Task" orientation is not a new concept. University of Wisconsin-Madison's work on Condor project (http://www.cs.wisc.edu/condor), for a example, provides a fine example of resource request/provider matching. While not purely "Task" oriented it provided important milestone in encapsulating task's behavior into a separate concern closely related to the "Task" itself.
As much as abstract it sounds this question is rather very fundamental to how your Grid Computing software will be used. Let me explain by starting with some loose definition of these two different views.
When taking a "Resource" point of view you are basically implying that the task that is executing on the grid is "dumb". Such task knows how to execute itself and usually that is about it as far as any interesting behavior. In this scenario the "Resource" (i.e. software that manages the task execution such as resource manager, task scheduler, failover manager, task loader, etc.) is a king as it decides where, how and when task gets executed. Most of the current Grid Computing software falls into this category.
Alternatively, if one takes "Task" point of view, the task itself becomes much more intelligent as it now "knows" where, how and when it gets executed. Symmetrically, the role of "Resource" becomes much simpler.
We at GridGain Systems, Inc have chosen "Task" point of view from the beginning for a number of reasons. In retrospect, I view this decision as one of the two most important ones (another one being AOP-integration). Let me list these reasons as they are interesting on their own:
- Primary user of the Grid Computing software is the developer who writes code (task) that will be executed on the grid. As simple as it sounds - it is often overlooked as many current (if not all) Grid Computing products tend to view the developer of grid enabled business applications as a "necessary evil" for an elegantly manageable infrastructure of the grid itself...Having the "Task"-based orientation enabled us to give the right tools to the right user via simple APIs with unmatched feature set.
- "Task" orientation enabled us to simplify the user-facing APIs. Indeed the whole user API for GridGain consists of less than a couple of dozens of interfaces, and simple AOP-based usage scenario requires just a handful of interfaces to learn.
- "Task" orientation allowed us to concentrate the behavioral logic in one place - in the task itself, making the task extremely intelligent and autonomous (and, yes, IBM's notion of self-healing software is fully implemented in our design). Task itself makes the decision on execution topology, failover strategy, resource collision resolution, splitting/aggregating, etc.Now, one can ask a legitimate question: why not separate the concerns of executing the task (the task body) and managing its execution in the grid environment (scheduling, failover, collision resolution, etc.)?
The fallacy of this question (and this argument) is the same as in roles separation in EJB 2: the real world just does not work this way. You will be hard pressed to find an organization that would have a dedicated EJB developer, EJB assembler, and EJB administrator. Likewise, in Grid Computing world the developer that writes the executable body of the task is usually responsible for the logic that defines where, when and how this task will be executed.
"Task" orientation is not a new concept. University of Wisconsin-Madison's work on Condor project (http://www.cs.wisc.edu/condor), for a example, provides a fine example of resource request/provider matching. While not purely "Task" oriented it provided important milestone in encapsulating task's behavior into a separate concern closely related to the "Task" itself.