So, GigaSpaces released XAP 8 on January 31st. They asked TheServerSide to run the standard press release, and I do believe the release was mentioned in the newsfeed at some point, but the only thing TheServerSide hates more than pushing press releases is the idea of forcing our readers to tread through them. So, rather than doing a press release, we asked GigaSpaces to at least give our readership something they could sink their teeth into and perhaps dissect a little.

In that spirit, GigaSpaces got back to TheServerSide with a top five list of reasons how XAP makes life easier for the enteprise development professional.

The verbiage still sounds like a press release, but at least it's not nearly as painful to read.

So, does GigaSpaces have a case here? Does XAP 8 really make life all that better? And better than what? Just release 7? Or does it make it better than GridGain, or Terracotta's offerings, or what even Amazon or SpringSource, with their vFabric platform, have to offer? Maybe some of those vendors would be bold enough to come up with a top five list of their own?

Top Five Reasons:

Why GigaSpaces eXtreme Application Platform 8.0* Makes Developers Lives Easier

1)      Move from the cloud to the data center and back – or operate simultaneously

• Write the code once and run your applications anywhere – it remains platform agnostic, allowing you to maximize the use of your commodity servers or cloud vendors without hassle

2)      Use what you know and what you have

• Access your data and processes with JPA, Memcached, .Net, C++, JMS, and many others, meaning that you can quickly leverage the platform, easing the migration of existing applications and allowing a wider set of applications to use XAP as their primary data and processing backend

3)      Scale dynamically and linearly

• Scale your data, applications, and logic without any compromises in performance and functionality

4)      Manage terabytes of data while ensuring high-speed processing

• The functionalities of scalability, caching, and distributed processing are combined into an integrated whole

5)      Give your administrators peace of mind

• The improved elastic service management functionality ensures minimal manual intervention in production while providing the best possible SLAs under any condition
• The all-new alerting mechanism and improved Web UI provide proactive problem detection and faster resolution

The new schema-free API and backwards compatible communication protocol enables organization to change their data model, business logic and even platform version with virtually zero downtime  

Edited by: Cameron McKenzie on Feb 10, 2011 8:52 AM

It is very dangerous to select a product just based on a feature list. A product can be better on paper, but it could be way worse in practive.

I have been using Gigaspaces on a daily basis for the last 1.5 year and although it certainly has got good parts (I like the datagrid functionality), it also has lesser parts.

Apart from the library itself, good practices to use a library can make a world of difference. It could be tightly integrated in the application code, leading to tons of WTF's. But with some love and care it can also be pushed on the background. 

I guess the same goes for any other framework. 

For companies starting out with Gigaspaces, I would really recommend being very careful. In no time you can have a extremely complex, buggy non scalable system that grinds even the best developers to a complete halt and it can take some serious time/effort to get everything on track.

Peter, and I smelling a "Top 5 Things to Avoid" article from you? I'd be interested in your insight on the topic.

Peter, interesting. What are you doing that gives you a nonscalable system? I've certainly seen less-scalable stuff out of space-based architectures, but they've always been a square-peg-in-round-hole solution - where one basically designs the application to be nonscalable.

He did mention that you need to use some good practices. It seems to be what he acknowledges to be some 'bad practices' that can get you in that mess. I too am interested in what they are. Or maybe, what the "Top Five" are? 

Sure, he mentions "bad practices." But here's the thing...

In no time you can have a extremely complex, buggy non scalable system that grinds even the best developers to a complete halt and it can take some serious time/effort to get everything on track.

For one thing, there's no application or framework on the face of the earth for which that's not true. For another, it implies that there's a fundamental issue with XAP that makes it susceptible to this sort of problem - which may be true, but from my experiences, is not.

I'd love to find out what happened to make that true, because I, too, want that "things not to do" list.

Traditional Java EE apps tend to be slow, because people pay attention to tiny bits of the components Java EE makes available. It's fairly easy to leverage more of the Java EE spec to get some impressive speed; that said, it's easier to migrate those same architectural components to a tuple space and get ten times the scalability, if you're taking the stupid path to it. We have migration stories from real customers where they got 1700 times their previous performance by using a simple migration path.

If you actually design your application around a tuple space, it's easy to get numbers that would dwarf that kind of improvement. 

What I suspect has happened here is that a process has been put in place where the granularity is very coarse - i.e., transactions queue waiting for a single resource or something like that. I don't know, but I'm very interested.

The idea behind Gigaspaces, is that once you are on the right box, you should remain on the box (so have the complete stack on every box), so that essentially everything becomes local and can be done with very high speed. Once you stray from this path, things get 'interesting' and non scalable.

Another anti pattern is using the Gigaspace POJO's as your internal domain objects and as DTO's. Gigaspaces implements the JavaSpaces model, although less strict. But even than, you can have domain objects where everything is exposed through getters/setters, primitive fields are non existing, and even expose internal state to the outside.

We have figured out that splitting up the 3 different ways domain concepts are used in seperate objects gives a lot less headache.

-  seperate DTO's to connect remote services (exposes through GS). Only the fields others should see are going to be part of these DTO's.

- seperate domain objects that can have all the richness you need them to have

- Gigaspace tailored objects to communicate with GS. So nasty non primitive fields used for QBE are no problem anymore.

It doesn't make GS good or bad,, but if used badly you can be in a world of pain. I would like to see a list of bad/good practices of how to deal with GS correctly. It is a powerful environment, but it needs to be used with great responsibility.

Another thing to watch out for is an explosion of processing units. A half year ago we ended up with 150 mb of artifacts that needed to be deployed (even for the tests) which makes testing/deploying extremely slow. Having a code-test-code cycle of 45 minutes is just killing for productivity.

We have been working hard to get all clutter out of the system and currently are at 40/45MB of artifacts that need to be deployed (I'm aiming for 30).

 

The cycle time now is reduced (for most cases) to a few minutes. We are still dealing with some deadweight, at least we are booking progress again.

Interesting - but not quite valid.

There is no "right box" for a gigaspaces deployment. Routing can certainly encourage colocation of associated data, and that definitely makes things *extremely* fast, but there's no requirement for colocation - and nodes will cache recent data to the best of their ability anyway.

The domain model stuff, well, hmm. Which version of GigaSpaces are you using? We've allowed many possible domain model constructions for quite some time now, and it's not difficult at all to have domain attributes that aren't necessarily "exposed" to the outside. I'd say the amount of customization you have to do to accomplish this wouldn't be any greater than in any other persistence mechanism.

The primitive field restriction - a holdover from JINI that makes sense in context - isn't so much a problem once you use Java 5 or later.

The reason it exists is to allow wildcards in QBE; you can specify primitive values that serve as wildcards, but it's easier to choose a value that has no meaning (i.e., null, which is what we do for object references by default.) That said... QBE, while very useful, isn't the only query mechanism by any means. You can use QBE, or a document query model, or even SQL for querying, none of which suffer that limitation, if that's what you want to call it. (I can understand if you do.)

An "explosion of processing units" can indeed be a problem - but why did you have an explosion of processing units? If you're coupling processing units tightly, to the point where you have to do a mass upgrade, then something else is awry. Your domain model can be upgraded in place; a processing unit is designed to be testable in isolation.

I'm not necessarily blaming "user error" here, because I can see situations in which the problems occur - and maybe I'm so used to using simple things to get around these situations that I'm not recognizing how serious the problem can be. I'm certainly open to finding out more.

>> Interesting - but not quite valid. There is no "right box" for a gigaspaces deployment.

I'm not talking about deployment. In our case we have a system that essentially is extremely good scalable since partitioning can be done on a well spread routing id (some generated UUID). So once you hit the 'right box' you can remain on the box and every request you do (while that user is logged in) ends up at the same box.

But if this isn't done, and you keep jumping around because at one moment you are routing on one type of id and the other one on another, the system will be less scalable (and cause a lot of network communication).

>>The domain model stuff, well, hmm. Which version of GigaSpaces are you using? We've allowed many possible domain >>model constructions for quite some time now, and it's not difficult at all to have domain attributes that aren't necessarily >>"exposed" to the outside. I'd say the amount of customization you have to do to accomplish this wouldn't be any >>greater than in any other persistence mechanism.

We are using GigaSpaces 7.10 (the latest 7 version at least.. haven't upgraded to the 8.0 release).

And if your 'pojo' gets serialized over the line to another machine, that machine will know everything about the internals of the sending machine. So I would certainly like to see what your solution is without relying on DTO's.

>>The primitive field restriction - a holdover from JINI that makes sense in context - isn't so much a problem once you use >>Java 5 or later.

>>The reason it exists is to allow wildcards in QBE; you can specify primitive values that serve as wildcards, but it's easier >>to choose a value that has no meaning (i.e., null, which is what we do for object references by default.) That said... >>QBE, while very useful, isn't the only query mechanism by any means. You can use QBE, or a document query model, >>or even SQL for querying, none of which suffer that limitation, if that's what you want to call it. (I can understand if you >>do.)

There certainly are solutions for this problem, but if not applied correctly, your objects are going to suck big time and Gigaspaces will be extremely tightly coupled at everything you do.

The approach we are currently taking, so using normal dto's for communication, normal pojo's for the domain objects and gigaspace tailored objects (that are part of the repo's) for gigaspace 'storage/quering', saves a lot of pain.

>>An "explosion of processing units" can indeed be a problem - but why did you have an explosion of processing units? If >>you're coupling processing units tightly, to the point where you have to do a mass upgrade, then something else is >>awry. Your domain model can be upgraded in place; a processing unit is designed to be testable in isolation.

I think because there were not enough people that did care. Everything was modelled as a processing unit, even our infrastructure logic for doing io was modelled as a different processing unit, meaning that you had to remote if you wanted to do some io. And because a different routing id was used, it could be that you hit different machines for processing a single requests. We already abolished the 'infrastructure' tier and made it to a normal layer, but currently we still are going to hit at least 2 machines to deal with a single request.

Another problem was that for being able to do IO, no streams are used, but bytearrays since afaik there is no direct support for streams. I guess I don't need to explain what the consequences are of this approach (especially if you know that data with sizes to hundreds of megs could be send).

>>I'm not necessarily blaming "user error" here, because I can see situations in which the problems occur - and maybe I'm so >>used to using simple things to get around these situations that I'm not recognizing how serious the problem can be. I'm >>certainly open to finding out more.

The problem is that most of the initial design was done by the Dutch Gigaspaces partner. So I would have expected that they would have known better.

Perhaps I should rephrase the last remark:

Even a company that knows a lot about gigaspaces is able to do it wrong, so to use gigaspaces badly, you certainly need to know about the do's and dont's of Gigaspaces. If you don't, it is very easy to cause havoc.

That is why I said in the beginning that one really needs know what one is doing when working with Gigaspaces and that one needs to apply common sense, instead of relying on the framework to solve it all.

Using a framework that makes linear scalable applications possible, doesn't automatically mean that your application is linear scalable if that framework is used.

Heh, I can see where the problems would occur, indeed. I hope you didn't think I was just sitting here thinking "You're just doing it wrong..." and you're right, there is no magic bullet you can use. I think it's easy to take XAP and build extremely scalable applications with exceptionally favorable runtime characteristics - and at the same time, i recognize that there are some issues that are going to be "hard" no matter what. (I/O springs to mind, where you'd really want nodes to handle things properly.)

There's definitely nuance. Incidentally, anything i can do to help your deployment succeed, let me know.

Had seen this on twitter today: 

Lots of overlap between GridGain and GigaSpaces. I'm liking GridGain's deployment model though. 0 secs to deploy or waiting 20 mins for a space to start.

Make up your own conclusions...

Nikita Ivanov.

Interested in seeing what the deployment model was for that space, as I've not seen anything like that, and I've deployed on some truly craptastic configurations and machines.

I like the way the message has been delivered. :-)

Like Gigaspaces, there are some players in the market which are doing very good job. Product like NCache is one fine example of it.  NCache is an enterprise level distributed cache for .NET and Java and also provides a fast and reliable storage for ASP.NET 
and JSP Ses sions.