Happy New Year Everyone!
The coming of a new year tends to invoke thoughts about the future as well as a some reflective moments concerning the past. In terms of our most recent history, 2006 was a watershed year for us at GigaSpaces. And, we have every confidence 2007 will see ever greater global acceptance of, and demand for, our Space-Based Architecture solution. Thanks to all of you, inside and outside of the company, who helped make the past year so successful. In fact, thanks as well to all who have helped the company grow and prosper since its founding in 2000.
Even though GigaSpaces today is more then 6 years old I’m still getting questions on how and why it was founded. While answering those questions I realized that the answer helps others get a better understanding of our approach and why we’re doing things the way we do. I therefore thought it would be best if I would simply make that answer publicly available hoping that others could benefit from it as well.
Why and When GigaSpaces was founded?
GigaSpaces was founded in early 2000- The background that led us to start GigaSpaces was mainly our CORBA middleware experience and the realization of the complexity involved in building highly distributed and stateful systems with existing middleware technology (namely J2EE and CORBA, at that time). We came across this complexity, mainly, in two areas: Command and Control, as well as B2B exchange (a private case of Trading System).
We realized that highly distributed computing patterns were going to be more popular due to the increase in network speed. We anticipated an increase in compute power via commodity resources and, at the same time, that the increase in memory capacity would make memory-based solutions a much more viable approach for handling high performance data distribution. In short, we saw these challenges as an opportunity. At that time JavaSpaces had just emerged and by taking a deeper look into it we found its potential to provide a totally different approach to distributed computing . An approach that would revolutionize the way middle-are is built nowadays due to its inherit simplicity (i.e. 4 APIs: Write, Read, Take and Notify), and the fact that it could address Messaging, Data Distribution and Parallel Computing issues simultaneously using those 4 simple APIs. After conducting a short survey we realized that the only way we could capture the value of the space based programming was if we kept the simplicity of its APIs while implementing it in a virtual manner i.e. distributed applications will use the 4 APIs as if they are interacting with a single server, even though in reality they will in fact interact with numerous servers. To reach this transparency, we virtualized the physical space nodes through a cluster-aware proxy, the proxy took care of routing each each call to the appropriate physical space instance based on different topologies and policies (Partitioning, Replicated, Sync-Replicated, Async-Replicated etc.).
Who were our first customers?
Our first substantial customer was a leading telco vendor, who decided to build their next generation call center application on top of GigaSpaces. They evaluated our approach against other messaging and database approaches. In fact, they spent a lot of time looking into the various solutions before choosing GigaSpaces. For those who are not familiar with call centers, a call center can be viewed as a state machine, which is basically an event driven stateful environment. In this environment, an event can be an incoming-call, call-forward, or call-ended, while the ‘state’ can be Incoming, Waiting, Active, etc. To scale this environment using traditional approaches required combining both messaging and database at the application layer. This created serious complexity and a huge performance overhead especially where the ‘state machine’ (i.e. the call center app) had to be distributed, as in the case of this vendor. Not surprisingly, this vendor found that our space based approach was more efficient since they could rely on the space cluster to deliver the events and maintain the state simultaneously and leverage the locality of the data through the notion of embedded spaces.Since we were able to remove any reference to centralized server (the entire architecture was completely peer to peer) this led to:
- Benefits in performance since most of the operations resolved into a local, in-memory call
- Simplicity since we reduced the amount of moving parts
- Use of the simple Space API to address:
- The messaging requirement
- Distributed state sharing requirements
- Scalability
Since then we have improved those patterns and broaden them significantly to provide different data distribution topologies and persistence models. We also implemented a complete virtual middleware on top of this model which implements existing standard APIs such as JDBC on the data side and JMS on the messaging side. Both were designed to enable different users to gain the scalability and performance benefits of the space model while still using existing traditional APIs.
The main principle that we kept throughout this process was to keep all those capabilities topology-driven i.e. a user could write his code once and then switch from persistent to transient space, from embedded to remote, add local cache etc. through a simple configuration change with no change to code. Having achieved this in the year 2004, we started focusing on the financial industry where the increase in the volume of data due to electronic trading created a huge drive for scalability and performance.
The space-based approach was a perfect fit since it provided:
- The ability to gain performance by bringing the data into the application memory
- Scalability by distributing the data over a cluster of machines
- A high degree of reliability without the use of disks or even Data-Bases by keeping at least one copy of data available on another machine.
It is this experience that later led to the emergence of our Space Based Architecture Architecture which addresses the scalability and the performance of the entire application and not just the data or messaging layer.As we approach 2007 we see a growing demand for such a solution in other verticals and other types of applications. Wherever an application is distributed and stateful and can’t scale just by buying a bigger machine (they are forced to scale-out) GigaSpaces becomes a perfect solution. Traditional tier-based approaches simply cannot address these challenges. I believe that 2007 is going to be turning point in the world of distributed computing in which Space-Based models will have a major role in shaping the future of how we build low-latency high-throughput applications. I particularly liked the way “Fuzzy ” put his prediction in his recent blog post.
That’s the GigaSpaces story in a nutshell with a short glimpse of the future as I see it.If you have further questions or are interested in more information please feel free to send me a direct email or simply post a comment to this post.
Nati.
