Gojko Adzic, who works at software consulting firm Neuri out of London, posted a question on LinkedIN: Are you using GigaSpaces in production? Gojko further asks: “What are your experiences with it? What are the pitfalls? What were the biggest benefits?”
Several of our customers and partners have weighed in with their responses and we thought it is worthwhile sharing them here. More answers get added over time, so it’s worth checking out the original link. Here are the answers:
Hi Gojko. Virgin Mobile use GigaSpaces in production. I was head of architecture there, and responsible for its introduction. It sits behind the web site and other sales channels managing incoming orders and coordinating the fulfillment process. I’ll assume you are are familiar with concept of spaces and distributed computation so will stick to the practicalities.
Good points – elegant programmatic model, really easy to get the business involved in relevant aspects of the design, product itself is very robust, deploys easily, scales like a dream, documentation and online wiki very good, GigaSpaces people are friendly and even the sales team can talk about code which is a pleasant experience, keenly priced when compared with alternatives.
Pitfalls – requires an appropriate network infrastructure (all nodes in one space need to be on same LAN, there are workarounds but you don’t want to encounter them late in a project), the concept of “mobile code” can be confusing for some developers, so plan plenty of training and get experienced help early, the design options can be confusing, operational tools for tech support is getting better but you might need to roll a few of your own. There’s a London-based outfit called PSJ Solutions who have built some interesting add-ons for this purpose.
Hope that helps. Feel free to contact me directly if you’d like more.Steve Colwill
Principal at PSJ Solutions
see all my answers
Gojko
Following up on Julian Brown’s answer, my company PSJ Solutions did a lot of the initial development work for Virgin using GigaSpaces and helped get it into production. I’d support Julian’s views as to benefits and pitfalls, but add that one of the specific pitfalls on this project was that the infrastructure was heavily partitioned with firewalls which limits one of the big wins for JINI technology -i.e. ability to discover, bind and heal distributed components. As Julian says there are mechanisms to punch through firewalls, but ideally this should only be necessary at the margins of your data centre not between machines running collaborative services.We’ve also experience with developing financial systems based on GS. The main performance requirement with these systems was latency and you do need to look at the distributed design with this in mind. Fortunately GS makes it very easy to re-configure late in the day to colocate or distribute components for serialization efficiency.
I’d also add to Julian’s remarks that there’s also a mindset shift required by developers to get the most out of the scalability potential. I’d liken it to the mindset shift from procedural to OO (if you can remember that far back…;-)). At PSJ we’ve ended up, after using this technology for a couple of years, codifying a number of space-based architectural and design patterns in re-usable code frameworks. We’ve found this a strong productivity boost internally and also helps our clients’ developers get productive quickly with the paradigm.
Hope some of this helps. Please feel free to contact me again if you need any further details.
regards
SteveVictoria Livschitz
Enterpreneus, technologist, computer scientist, software architect
see all my answers
Hello. My firm, Grid Dynamics, is a consulting company focused on grid technologies and performance engineering. We have a lot of experience with Gigaspaces; in the last 12 months we ran 6 customer implementation projects and one full-blown benchmark against the usual suspects (Tangosol, Gemstone). Customers and applications vary wildly from intra-day trading for financial services firms to fraud detection for online retailer to content delivery for mobile entertainment provider.
To me, the greatest benefit of Gigaspaces is transparent application scaling. You can take the app – web app or enterprise app, pretty much AS IS, and make it run much faster and scale much better on appropriate back-end infrastructure. A couple of typical points of reference:
– throughput of content streaming to mobile devices was improved nearly 50x from a single box of identical configuration by putting Gigaspaces in front of the database and performing minor application optimization.
– fraud detection over a very large dataset (nearing terabyte) was proven to go down from 500 ms per score to under 20 ms under extreme traffic flow.
In our experience, the biggest challenges in bringing the system to production and maintaining it there tend to belong to two buckets:a) Integration with other production enterprise systems. This is different for every client and complexities cannot be underestimated.
b) Adequate funding and “right mentality”. Often customers don’t have the appreciation for the level of system engineering that goes into making grid systems work well in large-scale environments. You have t
o consider, profile and optimize everything end-to-end – network backbone, storage, servers, os, threading, VM tuning, application, messaging, monitoring, failover, cross-datacenter disaster recovery, staffing, operational support. We see cases when people under-budget by time, resources and staff by a factor of two, or more.
Feel free to ping me if you like to chat more specifically.
VictoriaHi Gojko,
I think between Julian, Steve and Victoria, you have a good idea about the capabilities and challenges of the Gigaspaces framework. I would like to add our experience in using the framework to deliver a high volume, low latency transaction processing infrastructure in production earlier this year.I was head of engineering and architecture at a major payment processing network and we needed a network grid framework to achieve horizontal scalability of servers managing persistent socket connections without all connections on all servers. We had the software framework that we intended to use but were looking for a space based architecture that would address this specific need. We were introduced to Gigaspaces by our enterprise service partners, and they decided to come in and integrate with our existing solution as part of the POC. The solution was demonstrated in less than 3 weeks and we had a linearly scalable solution at the end of the exercise. We put in additional development effort with tremendous support from the Gigaspaces team over the next few months to deliver a solution with industry leading performance numbers in terms of concurrent connections, transaction response times and ability to handle failure. The partitioning and clustering capabilities of the GS framework worked flawlessly out of the box. They needed a little tweaking given the high number of processing threads in our application, but this influenced some application re architecture on our part as well; for the better. We did have some challenges in implementing the space overflow feature which allows in memory data to be streamed to a DB or file system in case of overflow, and decided to implement our own custom solution. I would revisit this over time due to some significant improvements on the platform since the time that we decided to work with it. Julian hit the right note about operational tools needing improvement. That was the only piece of the custom code delivered to us that had some threading issues, but the new version of the application has addressed them adequately. We look forward to upgrading to the new version soon.
The best part of the solution in our particular case was the manner in which the solution scaled horizontally. This took a tremendous burden off my architecture teams and we could focus more on functional development of our solution rather than work on the framework. The GS team is an absolute pleasure to work with. We had resources working around the clock in the US and Israel to address issues we had pre-production. The support from the senior staff at Gigaspaces is impressive. The team has demonstrated tremendous thought leadership in the area of grid frameworks and space based architectures.
The last point I would like to make is echo what Steve said about requiring a mind shift in design approach to leverage the most out of the space based architecture. Once understood, the framework makes complete sense and does look to be the most encouraging and elegant design approach to building scalable architectures and separate the complexities of the infrastructure from the functional complexity of your application. What we now have on our GS framework is a highly available, highly scalable computing framework that we can use across multiple applications. I find this the most elegant way to build legacy like processing infrastructure using commodity components.
I wish you luck in your implementation and hope you join a growing community of GC users.Keerat Sharma
Platform Engineer at Gallup
see all my answers
We do use it in production (at Gallup). I echo a lot of what the prior answers have stated.
*What are your experiences with it?*Our experience with the company has been good. GigaSpaces is pleasantly surprising in that you can get programmers from your side to talk to programmers on their side without any fuss. Our need for GS was simple: we were reaching a point where we needed to hold more data in memory than was possible within a single virtual machine. To this extent, it has proved very successful.
GS isn’t a flavor of the day toy. If you’re committed to it, research it, and understand it. You can even create your own proof-of-concept implementation with it. We found it very helpful spending time doing R&D and interacting with the GS folks to discover how best top set up our partitions.
*What are the pitfalls?*Considering that GS is probably used as a infrastructural mechanism, to help scale or provide specific services, I’d say that there are some “Use with common sense and/or care” flags, as opposed to direct pitfalls.
You need people that understand the core concepts. We found that a good way to evaluate the potential issues was to immerse ourselves in the foundations of Jini, RMI, NIO and JavaSpaces. After we had a good understanding of those core concepts, getting to understand GS and what value it added was fairly simple. But, you need to invest in people and time up front.
We also found it beneficial to spend time up front, getting the programming side and the network infrastructure folks to blueprint how the network would be laid out. This is a fairly important step, and I’d advise doing it at the start of the implementation.
*What were the biggest benefits?*Bang for buck. The cost of building a system (even with existing open source elements) that can replicate single dimensions of what GS can offer will outweigh the cost of using their system. Put this way- with GS, you get an enterpris
e system- partitioning, replication, failover mechanisms and the like all out of box.
You can write whatever you want to interact with the space, at whatever granularity you like. We decided to write some specialized code to monitor the space in a really lightweight fashion.We got huge average latency reductions. If you’re using it for a cache, you can do the math on how many expensive hits you stand to reduce. The larger the cluster, the greater the benefit really.
