I don't have much beef with Ruby and RoR as I don't encounter it beyond simple web applications. In enterprise systems, dominated by Java and .NET, it is statistically non-existent. But nonetheless I was really startled when I read about concurrency "support" in both Ruby as a language and RoR as a framework. Well, basically, there are almost none in both at least at this point.

Now, in the year 2008, with multi-core CPU, "green threads" being taught in history CS classes, and with grid computing and overall drive for parallelization it is really preposterous and arrogant to think that language that has only rudimentary (if any at all) support for concurrency and a framework that is simply single-threaded (you need to start a separate processor - basically fork) can gain much attention from enterprise community. Let alone considering its scripting "baggage" and dynamic typing... It's like asking people to go back to CGI-type of web programming.

But somehow Ruby is getting popular for simple websites that have no apparent plans for growth. I guess for some having an outsider, "look, ma, no hands!" rebellion status often means much more than sound engineering and quality results...

Last week I posted a blog on the similar topic of why Ruby and RoR are not ready to be used in enterprise systems. I've got quite a discussion in response (over 30 comments) which was roughly divided in half - those who support my point of view and those who don't.

I don't use Ruby in development. I live and work in Silicon Valley and have yet to see the first person who's using it or the first project that is using it (granted I don't mingle much among those who develop website for living). But I stumbled upon an article about concurrency support (the lack of thereof to be precise) in Ruby and RoR and that's what provoked by previous blog. But...

...the funny thing is that this is really a small potato comparing to... dynamic typing in Ruby. See, I fully agree with those saying that Ruby/RoR are just in their first version and glaring wholes like lack of normal threading will be eventually patched - just look at JDK 1.0 and compare it to today's Java. No doubt Ruby, as a language and system, will mature over time. What will not mature is its dynamic typing foundation...

I can pretty much say that I belong to a silent majority that view dynamic typing as a clear regression as far as general purpose languages go. All of us used or using languages with some form of dynamic typing from time to time be it JavaScript, Tcl/Tk, Perl or Shell. Even back in 1995 we were using these languages and when Java was introduced it was a sigh of relieve, at least for a huge silent majority, with its static typing and one of the best strong typing foundation - checked exceptions leading the way in innovation here.

I remember that I felt that we can finally move away from the silliness and inefficiency of writing 1000s line of backends in Perl or C++ and move to something much more stable, robust and adequate for large projects - Java. Even in its first version Java was miles ahead of anything else for enterprise development - something its designers didn't really anticipated in the beginning. Java was and still is the best language and system for developing large and complex enterprise systems. Strong and static typing, checked exceptions, rich libraries, huge open-source eco-system, concise and familiar C-based syntax, and sane design for the most parts (thanks to the same engineering organization that produced Solaris) - all of these characteristics contribute to Java's success initially and over time.

I've read this short article on Dynamic Typing (http://www.dzone.com/links/dynamic_typing_more_superior.html) and I think it sums it up very politely and succinctly. Please, read it and especially read the comments (some of the them are truly delusional - where do these people come from?). Yes, when you write small scripts in Ruby or PHP or Perl you can get away with pretty much anything: dirty "duck typing", bizarre syntax border-lining on fetishism, no intelligent refactoring (no wonder most of Ruby-ist are working in Vi - and I love Vi, by the way), dozens of ways to do the same thing (welcome back to Perl), embedding types into variable names, spending hours resolving what should have been a compile time error (welcome back to C++).

But when you develop something more than a script on you web page or shell script in your environment using languages with dynamic typing is practically dumb. And that's the common wisdom of the silent majority. And when you read the comments on Soon Hui's articles you can really feel for McMurphy in the movie "One Flew Over the Cuckoo's Nest"...

I'm continuing previewing some of the features that GridGain team is working for upcoming release. One of them is support for RESTful applications. Basically, that's how you could, for example, invoke a grid task from your RESTful web application by pointing to this URL:

http://www.myhost.com:7080/gridgain/taskid=mytaskid&arg=myarg&timeout=5000

This will return XML document back with execution results which can be easily parsed by JavaScript in a usual Ajax way. That's it - you basically pass task ID, and optional argument and timeout and that's all it takes to execute a grid task. You can develop, test and debug your grid task as usual in any preferred Java IDE with all the productivity features that GridGain provides such as transparent deployment, our simple APIs or peer-to-peer class loading.

Note that this is exactly the same way as you would use, for example, Google Charts. Now, I don't know of any other grid computing framework that can get your Web 2.0 grid enabled easier than that!

Stay tuned and meanwhile download the current release of GridGain at http://www.gridgain.org/downloads.html

I found this interesting blog by Jorge Lugo about how GridGain was deployed used in EC2. Very nice read with source code and diagrams. Short and to the point. We are actually planning for much deeper integration with EC2 infrastructure but even at this point EC2 deployment looks pretty cool.

Enjoy!

I had a blog about a month ago talking about Android and how it is making mobile grid computing reality. The major points that I talked about were improved networking and CPU performance of the modern mobile devices combined with unified programming model delivered by Android - jointly bringing mobile grid computing into realm of reality.

Since then I had several discussion about it and I have several interesting follow up observations.

First of all, the devices in mobile grid are profoundly different from those found in traditional grid computing environment. While rack mount blades are completely faceless and void of any human interaction - mobile devices like phones and PDAs are almost an extension of a human being - people interact with phones constantly, pressing button, snapping pictures, listening to music, making calls, watching movies, etc. What I find fascinating is that if you extend this idea of mobile device being the extension of human's capabilities you can think of mobile grid consisting of human nodes... Indeed, every person with the mobile device is a node in the grid and his or her device is just a connection to the grid.

In this sense, mobile grids open up completely different types of applications to be run on the grid. Some of the obvious choices are human-based image recognition, short and massively parallel tasks, new types of security (requiring simple human interaction from a group of people), etc.

Second of all, mobile grids will require new business models or approaches. I can clearly see, for example, large operators like AT&T or Verizon offering discounted or free services in exchange for having a mobile device participate in the grid - while reselling this processing capacity to other businesses. Let's say you get free 1000 any-minutes if you let your phone to crunch some small tasks while you are not talking... not a bad deal!

Overall, I predict that mobile grid computing will become a new trend in distributed processing in the coming years.

There is an interesting BusinessWeek article by Olga Kharif mentioning our efforts with Android. Although our work is in the very early stages and we have yet to see how successful Android will be with major operators and handset providers - article gives good overview of the current state of the art and provides some thoughtful prognosis. Good read overall.

I do believe that mobile grid computing would be one of the next breakthrough enabling technologies for mobile market. Stay tuned!

I'm going to be presenting at JBoss World 2008 in Orlando on February 14th on topic of integration between GridGain and JBoss. If you are around - come see my presentation!

With upcoming GridGain 2.0 release we are going to round up our integration plans with JBoss by providing what I consider truly native blend-in integration. In fact, when you use GridGain with JBoss, GridGain basically becomes a part of JBoss container that looks as if it just acquired new functionality. Here's the list of integration points that we implement in totality with GridGain 2.0 (most of them has been available since GridGain 1.6):

• Loader for JBoss AS
• Support for and integration with JBoss AOP
• Integration with JBoss JMX
• Integration with JBoss Logging
• Integration with JBoss HA
• Integration with JBoss Cache (including support for dynamic data partitioning, load balancing and affinity map/reduce)
• Integration with JGroups

The reason I'm really excited about this integration is that it provides the first fully open source full-stack grid computing platform for Java, combining state of the art compute and data grid functionality. And that's why I think open source Java grid computing has never been more exciting!

Almost everyone who comments on the idea of mobile grid computing puts forward the skepticism about its possibility due to... battery performance in today's mobile devices.

So, the usual thought goes that if I let my cell phone crunch some numbers for extended period of time, let's say an hour, it will drain battery dry in the same hour. So, who needs it, right?

No. What's everyone is missing that mobile grid computing will require a slightly more sophisticated Map/Reduce implementation, specifically sparse load-balancing. Sparse load-balancing algorithm will perform splitting in such a way that any individual mobile device will only participate in the grid for short periods of time significantly reducing battery drainage. This logic is permitted by a simple fact that you may have tens or hundreds of thousands consumer mobiles devices in the grid at any given point of time - and you can use sparse load-balancing on such grid.

Sparse load-balancing is one of the areas in which mobile grid computing is fundamentally different from traditional server-based grid computing where utilization is the key. In mobile grid computing we are actually trying to reduce the utilization of an individual device but rely on a sparse distribution.

Another area where mobile grid computing is special is the use of redundant split, i.e. moving the same job to more than one node for execution - again relying on the fact that there are plenty of available grid nodes but each node has limited "reliability" for finishing its job.

Combination of sparse load-balancing and redundant split on mobile grid provides guaranteed execution with minimal impact on an individual mobile device.

With LEGO-like customization of every aspect of grid infrastructure GridGain is a perfect technology for mobile grid computing. Topology management and discovery, load balancing and dynamic map/reduce are all fully pluggable and customizable in GridGain.

There was an interesting question on our forums in regards to how many nodes we support and what are the limitation http://www.gridgainsystems.com/jiveforums/thread.jspa?threadID=168. Here's a good answer that was provided with some of my own addition...

First of all, we need do differentiate between Communication and Discovery functionality in GridGain.

Number of nodes really matters for Discovery and I don't think there is a limit - it's a matter of proper configuration. If you use the default GridMulticastDiscoverySpi, then it's really light weight and configuration tweaking would involve mostly setting appropriate heartbeat interval.

However, I think users should be careful when choosing the appropriate split size (most likely you are not going to be splitting your grid task into 100s of thousands of jobs - unless it is a mobile grid computing). To choose appropriate split size you should take into consideration that every job will be sent to remote node and there is communication overhead. So if your job execution time becomes comparable to communication overhead, you probably should not split any further.

For example, let's say you have 1000 nodes in your cluster but your ideal task split size is 50. You would execute your task, splitting it into 50 jobs, but assigning them to different nodes every time (using random load balancer shipped with GridGain 2.0). This would provide the fastest performance (optimal split size) and the best scalability (using all nodes in the grid allows for best load distribution and failover possibilities).