They say that timing is everything in life.. this time was no exception.
Yesterday I published my score card for 2nd generation PaaS and how it differs from Application Servers.
A few hours later, I received an email with a presentation from one of our new customers that is going to present at our GigaSpaces Roadshow.
This slide caught my attention:
* Note that GS stands for GigaSpaces.
The customer is a large ISV (1900 employee, $3B in revenue...). Their new product is a real-time BI system that needs to process events in real time from multiple data sources -– social media included (most other alternatives do that in batch mode) and produce actionable reports on customer activities. They had fairly challenging scaling, latency, and cost requirements:
- Massive Scale, 100M Customers, a billion events a day
- Business real time < 100ms
- Low cost 0.05 customer/year
Now it is not often that a company the size of GigaSpaces competes with giants like IBM and Oracle on one of their core IPs and leaves them so far behind.
How was this possible?
Well, our advantage is in our disadvantage –- size. Let me explain.
Removing the Silos
GigaSpaces as a case study
As a small company, we have to be extremely efficient at what we do. We adopted Lean methodology and Scrum across the board, and we stick to that model quite religiously. Every feature goes through millions of automated tests. We manage to build GA-quality releases every two weeks.
On the product side, we have designed our product in a way that follows the principles that I laid out in my previous post, i.e. -- without Silos. In GigaSpaces everything is mapped to data. Tables, Queues, even method invocations are mapped to the same underlying data structure representation.
We maintain ONE cluster throughout the entire stack to manage this scalability and high availability of the data. ALL of our APIs are simple facades on top of our shared data cluster (a.k.a space). This means that when we optimize performance, fix bugs, improve scalability, and add new features -- it applies immediately through the entire stack, including the .Net and C++ parts of our product.
The fact that all of our APIs share the same data opened new opportunities for optimization that weren’t possible before. For example, we can avoid a lot of the synchronization overhead that is associated with passing a message and then updating it. We can also mesh the driftnet APIs without unnecessary copies.
As an example, I can choose to use the key/value store API for low latency transaction processing and the SQL API for analytics over the same data that was produced through the key/value APIs.
Because of our size, we couldn’t afford the high maintenance and support that often comes with the type of deployments that we deal with. As a result, we were forced to develop lots of built-in automation and troubleshooting tools as an integrated part of our product, and later we integrated it with the development framework and application in such a way that every application is made operationally ready from its inception.
Now, the nice thing in all this is that both we and our customers benefit from that efficiency. We gain more customers without increasing our costs. Our customers get a better quality product, short fix cycles, and more features faster.
The latest 8.0 release is the best evidence of this, IMO. We managed to deliver 3 times more features than what we normally accomplished in previous releases, and all that with only a minor increase in our development team.
*A Little Promotion*
If you're in London on the 2nd of February , Paris on 3rd, San Francisco on 7th, or NYC on the 9th, I’d like to welcome you to join our Roadshow and hear more first-hand stories from these customers (Dow Jones, Sears, Amdocs, and many more top-tier organizations). See you there!
You can register and read the full details here.
