2006-2007 News
 Dec 03, 2007 | Every 4 Minutes Someone Starts GridGain |
| Oct 30, 2007 | GridGain Partners With GigaSpaces |
| Oct 16, 2007 | GridGain 1.6 Released! |
| Sep 18, 2007 | GridGain: Presenting at IEEE/ACM Grid 2007 Conference |
| Sep 07, 2007 | GridGain: Presenting at Colorado Software Summit 2007 |
| Aug 31, 2007 | GridGain: Presenting at JavaZone 2007 |
| Aug 17, 2007 | GridGain Support Forum (beta) Live |
| Aug 13, 2007 | GridGian 1.5.1 Released! |
| Jul 25, 2007 | GridGian 1.5 GA Released! |
| May 15, 2007 | GridGain: Ready for IBM Grid Computing |
|
December 03rd, 2007 |
Every 4 Minutes Someone Starts GridGain
by Nikita Ivanov  |
Every four minutes someone around the globe starts the GridGian. In of itself these numbers are not that
impressive and we have plenty of statistics from usage to website hits - but this one remains my favorite. We
have released the first major version of GridGain just four and a half month ago and today GridGain gets
started every four minutes...
Being the young project and a very specialized software - this is certainly great progress in my view. See
for yourself what makes GridGain one of the leading Java grid computing frameworks.
|
October 30th, 2007 |
GridGain Partners With GigaSpaces
by Nikita Ivanov |
NEW YORK, NY -- October 30, 2007 - GigaSpaces Systems, Inc and GridGain Systems, Inc today announced their partnership,
which offers a high performance grid computing platform for Java. The joint offering integrates GigaSpaces'
eXtreme Application Platform (XAP) with GridGain's computation grid framework, enabling businesses to process
high volumes of data -- transactional or analytical -- in extremely short periods of time. In addition, the two
companies will cooperate on joint marketing and sales efforts.
GridGain provides an open source computational grid framework that enables Java developers to improve general
performance of processing intensive applications by splitting and parallelizing the workload. With GridGain,
developers can achieve better overall throughput, better scalability and availability of services.
GigaSpaces XAP provides a single platform for scaling-out the data, messaging and business logic of an
application. By integrating the two products, GridGain customers can enjoy a highly-scalable grid computing
platform for both computational and data-intensive applications. For maximum performance, GigaSpaces allows
GridGain to run computational tasks in the same physical machine in which the relevant data resides in memory.
Full Press Release can be found here.
GridGain team just released GridGain 1.6. This release is about stability, documentation and...
JUnit integration! We are very excited that GridGain 1.6 is the first grid product with natural
and elegant integration for JUnit. Few lines of code to change or simply add annotation - and your JUnits
are running on the grid saving you time on your build - great feature and a great use case supporting our
believe that grid computing can be an everyday tool for every Java developer.
Download GridGian 1.6 today and enjoy better core product stability, GlassFish integration,
Apache 2.0 dual-licensing for binary linkage with our APIs, much improved performance for AOP grid
enabling, better documentation and examples - and don't forget to try our new JUnit integration!
|
September 18th, 2007 |
GRIDGAIN: Presenting at IEEE/ACM Grid 2007 Conference
by Nikita Ivanov |
"Java Grid Computing with AOP" vendor presentation will be shown this Friday at 8th IEEE/ACM International
Conference on Grid Computing (Grid 2007). We are really excited about this conference as this is focused
exclusive on grid computing. There will be plenty of fine folks from academia and business and talks are
looking very interesting. This year this conference is hosted in Austin, Texas which should be fun place
to visit.
See us at Grid 2007.
|
September 7th, 2007 |
GRIDGAIN: Presenting at Colorado Software Summit 2007
by Nikita Ivanov |
We will be presenting at Colorado Software Summit 2007 (CSS2007) in October 21-25. CSS07 is a unique developer's
conference in many ways... It is about the only conference that is build around the attendees: each presenter
runs his presentation every day for a week so that everybody who wants could attend each and every talk
removing usual conflicts when you have to pick one talk out of 2 or 3 going on concurrently.
It is a simple fact but hugely important for attendees: during 6 days you get to see practically all talks.
Your days away from work are very productive. CSS reminds more of a training camp on new and upcoming
Systems, Inc rather than a traditional conference. And it doesn't hurt that it is situated in a
beautiful rocky mountain resort and you can always drive to Boulder to unwind after the long conference day...
|
August 31th, 2007 |
GRIDGAIN: PRESENTING AT JAVAZONE 2007
by Nikita Ivanov |
I will be presenting at JavaZone 2007 in Oslo, Norway September 13-14. JavaZone is one the largest European
Java conferences and this is a great opportunity for us to talk about GridGain project and most importantly
about the technology and ideas behind it and our view on grid computing in general.
I will be presenting
on "Java Grid Computing with AOP - Fun, Simple and Productive". In this presentation I will show a live
coding example where I will create a simple grid application in just 10-15 minutes. Should be fun!
JavaZone is a must go if you can travel (and if you are in Europe - you are just couple of hours flying
away at the most).
|
August 17th, 2007 |
GRIDGAIN SUPPORT FORUM (BETA) LIVE
by Nikita Ivanov |
We have been picking up steam with support questions and we decided to put up an online forum
for GridGain project. Huge kudos to Jive Software that provided open source free license to us
which doesn't get any better - Jive Forum is a golden standard in online forum software.
This is a beta release as we going to be studying what works better and what structure and
configuration suits project's needs the best. Give it a shot. It can be found on any page on
our website on the right navigation bar in "Developers" section.
Check out the forum at http://216.93.179.140/jiveforums
GridGain team just released GridGain 1.5.1. This point release is about documentation and better examples.
We also fixes several bugs that made their way into 1.5.0 GA. No new features have been added and
it's fully backward compatible. Enjoy better documentation and more examples. Check out also
updated screencast!
This is an important release for our project. This release was about hardening core functionality
and APIs as well as providing new integrations. GridGain now supports Jboss, Spring, AspectJ,
Weblogic, Websphere, Coherence, GigaSpaces, JXInsight, and Mule with native integrations either
as loaders, AOP frameworks or SPI implementations.
We also significantly improved our core functionality and simplified the APIs in many ways.
Among new features we've added ability for jobs in split to communicate with each other via
common task session (for common connected task problem-space).
We've also added new tracing SPI and exciting implementation for JXInsight that provides
great tracing and monitoring capabilities for GridGain.
Oh, yeah, and we switched ascii-logo back to INFO log level. So, what are you waiting for :-)
|
May 15th, 2007 |
GRIDGAIN: READY FOR IBM GRID COMPUTING
by Nikita Ivanov |
As member of IBM PartnerWorld program GridGain complete validation for "Ready for IBM Grid Computing"
seal. We were surprised by the level of attention we were given and breadth of the partner programs
that IBM provides for its partners, even to small startups like us.
IBM offers plenty of specially designed solutions for partners to run and validate their software
on practically any IBM hardware or with almost any IBM software, setup demo configuration, etc. Level
of assistance was really great too, offering to "hold the hand" on each step. Overall, unexpectedly
great job from such a behemoth like IBM...
|
July 30th, 2006 |
GRID COMPUTING AND SOCIAL NETWORKS
by Nikita Ivanov |
Social networks have been lately in a spotlight. The concept is clear and it works: provide
web-tools for ad-hoc networking between individuals or group of individuals.
Some time ago I noticed that there is some similarity between the basic concept of social networks
and the grid computing product we are currently pushing to release. In fact, social networks are
based on capability of ad-hoc networking between previously unknown to each other entities. In our
product, grid tasks are autonomous and practically self-managed and ad-hoc decisions (ones that are
based on immediate and current context) are at the core of our design.
Stretching it a bit further one can say that our grid tasks form social networks when they get
executed... which I think is an interesting way to look at it.
Look at these three articles:
The overriding theme of these three articles (and they are based off the same IT research in UK) is that Grid Computing is:
- too expensive
- too complex
- too ambiguous in its value
Not surprising these are the same pain factors we attempts to address in our upcoming product:
- it will be licensed under LGPL and its runtime will be available free of charge
- it will provide revolutionary simplicity in usage
- it is developed with small to mid-size business in mind that don't have months and months or even years to realize full ROI
The same research claims that only 8% of participating IT organizations has Grid Computing in their production operations - and
so Grid Computing is "not catching on".
To me this number is rather startling, indeed - almost one in 10 companies in UK with any substantial IT already has Grid
Computing in their operations. Given the nature of the Grid Computing application and shortcomings of the current offerings - I
find this number encouraging and pointing to built-up demand that is unmet by the current products.
One of the unique features of our upcoming GridGain 1.0 product is AOP-based integration.
Since the beginning, the integration part of Grid Computing products was a sore point. APIs are complex,
non-intuitive and vendor generally assumed that people writing grid-enabled software would be willing to
spend a significant time on grid-enabling process (changing their applications, learning complex grid APIs, etc.).
When we set to tackle this problem in GridGain we quickly realized that AOP can be a ticket here. Now, I've had
experience with AOP a number of years ago (when AspectJ just came out) and having studied and used it back then quite
intensively I came away rather disappointment by how little applicability it brings. I still believe that AOP is a
niche technique but when you find such niche it usually fits like a glove.
I think AOP makes an almost perfect fit in our product and that's why:
-
Grid-enabling (at least in Java) most often comes down to grid-enabling a method call. No matter whether you
are grid-enabling an existing code or developing a new - you will most likely deal with one method. Java5 annotations
and AOP pointcut model provide perfect tooling for defining all necessary information to grid enable a specific method.
-
AOP allows us to grid-enable not only the application for which you have source code, but also for applications for
which you don't have a source code (or even documentation). For non-splitting scenarios (like in on-demand computing)
you don't even have to know anything about the method - even a signature.
Think about it: using GridGain with AOP integration you can grid-enable your current application, someone else's framework,
your favorite app server or even a standard JDK. In simple cases you don't even have to write a single line of code as you
can apply aspects via external XML definition - and in the same time you have full power of AOP's pointcut model at your disposal.
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:
-
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.
The usual answer is - Google it... Oh, you did? Well, the odds are that you are not any closer to the answer - and you are not alone.
Working on Grid Computing for the last 5 years I've accumulated my own share of strange looks on people faces when trying
to describe to them the grid computing idea. What is fascinating is that the actual concepts behind Grid Computing are very
familiar, simple and logical to anyone with basic understanding of how computers work.
Grid computing is not a technical term - it is a marketing term. There is no technology called "Grid Computing", there are no
products that implement "Grid Computing". The term "Grid Computing" collectively defines a set of distributed computing use cases
that have certain technical aspects in common.
There are four main use cases in distributed computing that are most often referred to as Grid Computing. Not all of them are
equal in their usage or usefulness for everyday business. Yet they probably represent more than 95% of "Grid Computing" today:
1. Computational Grids
Computational Grids account for a lion share of Grid Computing usage now and will certainly retain this lead in the near
future to the least.
In a nutshell, the idea behind it is very simple: if you have a task that is executing unacceptably long time, you can split
this task into multiple sub-tasks, execute each sub-task in parallel on a separate computer, combine results from the sub-tasks
and get the original task's result O(N)-times faster, where N is a number of sub-tasks in the split.
Computational Grids amount for almost all real-life applications of Grid Computing. The reason for this is quite obvious: unlike
other use cases it provides clear and unumbigious value and is applicable to a wide verity of business tasks. When properly
explained, it is easy to understand and easy to see how it can solve the real-life problems.
Despite ill-fated comparison to academia HPC, Computational Grids can be applicable to businesses of any size - from small
size companies to Google and Yahoo of this world. For example, even a relatively small company may have a need to speed up a
business report generation from 1 minute to 5 seconds to make it suitable for online access on their website - and in most
cases Computational Grids is the only practical approach to achieve 10 times performance improvement.
2. Utility or On-Demand Grids
This scenario is probably most over-generalized among all by the technology "visionaries" (you've surely read by now about
comparing computing resources to utility aspects of electricity or water services and how you will be able to tap into this
new type of utility by simply plugging in your computer into imaginary "computing" socket on the wall).
In a nutshell though it has surprisingly simple idea: if you have a number of tasks that from time to time spike in execution
and overload your computer(s), you can offload execution of some of these tasks during the peak time to other computers, often
located remotely. This has the following interesting characteristics:
- In most cases you only pay for the actual usage time of remote computers vs. buying your own computers that will idle for
the most of the time (off peak). As an example, SUN is offering $1/CPU/hour server farms which you can rent in hour increments.
- You solve the scalability but not performance, i.e. you can execute more tasks without slowing down, but you won't be executing
each task faster (in many cases you will be executing each task actually slower due to extra work for off-loading task to a remote
computer, remote computer being less powerful, etc.).
The main point of Utility or On-Demand Grids is on-demand computing availability which for certain types of businesses makes it an
attractive economic choice. For example, all online retailers experience repetitive cycles of increased customers' activity: major
holidays, back-to-school season, etc. During these cycles the activity spikes (sometimes in order of magnitude) and on-demand
computing can provide economically sound solution of handling increased load.
You may ask why not split the tasks as we do in Computation Grids and achieve the performance increase as well? The answers lies
in the fact that in majority cases the usage pattern of Computational Grids requires the constant availability of all computing
resources making on-demand point irrelevant - there is a constant demand in Computational Grids.
3. Data Grids
Date Grids allows for splitting data onto multiple computers. Much like Computational Grids splitting computations, Data Grids
allow placing data onto multiple computers or storage resources and treat them virtually like one.
However, the show here has been "stolen" by replicable distributed caching which accomplish almost the same and is readily
available today from number of vendors. More over, unlike illusive Data Grids caching technology is highly integrated with
server-side Java development. For the best example of distributed replicable caching look no further than Coherence
from Tangosol.
Another caveat of Data Grids is that their value is often unclear comparing to NAS or similar Systems, Inc.
4. Management Grids
Management Grids are only mentioned here because of Oracle. Oracle was the first company that put up a TV advertising
campaign promoting what their call "Oracle Grid". In an essence, it is a specific fault-tolerant database implementation
plus some administrative tools that allow Oracle database operate in a distributed environment in a managed fault-tolerant mode.
Oracle's grid is probably the best example of technology that has almost nothing to do with what most of us think about
the Grid Computing - yet it is routinely referred to as such.
As you can see in most cases the term Grid Computing means Computational Grid. It represents majority of uses cases and
provides clear and ready value to the user. But wait, there is more to it...
What about SOA?
There is a lot of talk going on about synergy between Grid Computing and SOA. It is however driven primarily by
implementation concerns at this point rather than by any deeper considerations. Clearly, Grid Computing can deliver
unchanged value without SOA, yet WS-* based implementation (such as Globus) can be beneficial in some cases (highly
distributed heterogeneous environments that should only exist in unfortunate legacy-support situations).
Any other prognosis (like OGSA) is nothing more than a fiction at this time.
What about cluster computing and traditional HPC?
Pundits from academia would like you to believe that there is irreconcilable difference between "primitive" cluster
computing and "sophisticated" Grid Computing. The truth is that in most cases you won't really recognize one from the
other and differences exist primarily in theory.
As far as Computational Grids are concerned the difference is minimal, if any.
Global Grids vs. Enterprise Grids?
Another categorization you can find in the media is Global Grids vs. Enterprise (non-global) Grids. In all cases you can
safely rename this discussion as Non-commercial Grids vs. Commercial Grids as Global Grids (in their pure notion) have
almost no applicability to commercial application.
In the same time, Universities find Global Grid much to their advantage as they usually don't concern themselves with
security, complex resource allocation or any other concerns that are daily dealt with in the business world.
What about OGSA/OGSI proposed by GGF and WSRF from OASIS?
Grid Computing is plagued by over-generalization, science fiction "specifications" produced by various consortiums
(whose primary reason is to collect the membership fees from the companies that want to get marketing value off a
joining such consortium or organization). As harsh as it may sound these efforts are primarily responsible for the
confusion that exists in understanding of Grid Computing.
OGSA being the most popular example of such "specifications" (and alphabet soup of relative documents surrounding it)
reads indeed like a good science fiction. As visionary as it sounds (and some part of it will likely materialize in the future)
it is best to be left for a late evening reading.
Disclaimer:
All opinions expressed in this blog are of their respective authors and do not represent the opinion of GridGain Systems, Inc. Vendors, journalists, bloggers, etc. are not free to quote with attribution to GridGain Systems, Inc without an explicit permission.
|
PRODUCT
NEWS
