Nati Shalom's Blog

Explaining to your boss (or your wife:)) why tier based architecture doesn't scale

Two weeks ago I had the pleasure of presenting at the NY JavaSIG. The event was hosted by an old friend, Frank Greco, who has been doing a really great work keeping the NY Java community up to date with the latest and greatest for quite some time (Great work Frank !). Even though it was one of those freezing NY evenings, the room was packed with around 300 people.

In this presentation, I used an analogy that I refer to in many of my recent talks to explain the fundamental limitations of the tier-based approach. I thought it is worth documenting this analogy, for those of you who are looking for a simple argument to convince their managers to open their mind to alternative approaches. One of the things I experienced with this analogy is that everyone gets it (my wife included J)

It goes like this:

Imagine a Coca-Cola production line that consist of three factory lines: one producing the bottles, one filling them and the third shipping them. The current production line can produce 1000 bottles at any given day.

One day your manager says to you (you are responsible for the total production): "we’re going to launch a new campaign, we expect demand to grow to 10,000 bottles a day, how quickly can we be ready for this?". Excited to meet that challenge you immediately call the responsible persons in each of these factories and tell them about the new requirement. Jim, the bottle factory manager tells you "no problemo, I've just upgraded my entire machinery I should be ready in no time", Joe, the bottle filling factory line manager says - "I've already squeezed everything I can get from what I have, and it'll take me 6 months to upgrade my production line", and Ann, the shipping factory line manager tells you "it'll take me 1 month to get ready". How long will it take to meet the 10,000 bottles a day requirement?.... Easy – exactly 6 months, why? Because you’re only as strong as your weakest link - in this case the bottle filling factory line.

Coca-Cola Factory - "Tier Based"

You are probably asking by now how all this is relate to computing? Think of the tier-based approach as a production line which consists of a messaging-tier, a business logic-tier and a data-tire. This production line produces transactions. To be fulfilled, the business transaction needs to go through all the tiers in similar fashion to Coca-Cola bottles in our production line analogy.

As with the production line, in order to process more transactions in a given time period, we need to make sure that all the tiers in the chain of transaction processing flow are tuned to meet the new required throughput capacity. As with the production line, to go from a certain capacity to a bigger one requires a process in which each tier needs to be tuned/upgraded or even replaced to cope with the new required. This is going a continuous effort that happens for every scaling event. Each time you scale would require a different level of effort which in most cases this effort is unpredictable.

This is only the tip of the iceberg - things becomes much more complex when we add reliability constraints to this process i.e. we cannot afford down time of this production line at any point in time. In our factory analysis this will require that each factory will have its own DR site. Most likely each one will have a different approach on how it implements this reliability policy, and it’s going to be very hard to make these policies consistent across the production line. Same with our tier-based implementation. Each tier has its own high availability and fail-over model. The only way we can ensure that our transaction is consistent is by adding an external coordinator which will look at each individual transaction and make sure each tier processed it, before it can safely "say" that the entire transaction was  processed successfully. This synchronization process is going to hold all our operations i.e. we’re going to be busy most of the time doing synchronizations, which means that we’re not going to be utilizing our existing resources effectively. In the tier-based world this coordination is basically the two phase (XA) transaction.

I can easily continue down this path, and review the various limitations of the tier-based model, but I believe you get the picture. This model is built of “silos”. If you have a fairly static environment this model may work fine. However, where there is a strong dependency between silos, and we expect to deal with continuous scaling changes and upgrades, this approach is broken.

Is there a better way ?

To find a solution, we can refer again to production line optimization experience. One of the methodologies used to optimize a production line (and is also being adopted for optimizing development processes) is referred to as "lean".

Lean is a management philosophy. Ultimately, it focuses on throughput (of whatever is being produced) by taking a strictly system-level view of things. In other words, it doesn’t focus on particular components of the value-stream, but on whether all the components of the chain are working as efficiently as possible, to generate as much overall value as possible. (source)

In our specific example, if we take an end to end system level view it becomes clear that if we have strong dependency between the different units in our production line. It doesn't make a lot of sense to put them in different places under different managers, even if each of them serves a different purpose. By recognizing this dependency we can restructure our production line - this time we’re going to build each factory as a self-sufficient unit where each unit will handle the entire production line i.e. producing the bottles, filling and shipping them.  Since we can build all of the units as a complete replica of each other, we gain consistency across the entire sites, even if each unit can deal with only a small subset of the total required capacity. All we need is the right number of these units to meet the demand. If we need to increase the capacity ? Easy - we just add more of these production units without even needing to inform the existing units of this change.  In this approach, if one unit fails, it brings down only that unit and doesn’t impact the entire production line. More importantly, we eliminate the need for the synchronization overhead between the various components by co-locating them in a single factory. This way our production line becomes completely agile compared to the alternative.

Coca-Cola Factory - Self Sufficient Units

 

In our tier-based world we will do pretty much the same. Instead of having separate servers per tier we'll build our application out of self sufficient processing-units each containing the messaging, business logic and data components. We scale our application simply by having more of these units and load-balance the transactions between these self sufficient units. In other words, we`re doing the following:

• We take all the components of our architecture that are tightly coupled at run-time i.e. latency, fail-over, scaling, and group them under a single self sufficient unit of work which we refer to as processing-unit.
• We use many of these processing units to handle the required throughput.

 
Final words: 

It is not surprising that the production line analogy helps highlight some of fundamental deficiencies with tier-based architecture. There is a lot of parallelism and things we can learn from the "Lean" and "Agile" methodologies that already proved themselfs in optimizing production environment. One of the main lessons is to take the system end-to-end view, rather then trying to apply optimization on each tier separately.

In many cases, much more “bang for the buck” can be achieved simply by looking at an extended value-stream, as opposed to a localized one. (source: lean software archive)

The limitations of the tier-based approach are not just because of the limitation of a certain implementation or a certain API (J2EE). It is the fundamental thinking underlying the tier-based approach, which leads to the complexity of wiring these tiers to meet changing runtime requirements. Our suggestion to solve this problem is that instead of separating our application based on functionality (API) we will separate it based on runtime dependency and keep the API separation at a logical level and not a physical one. At first sight this may sound like a major shift in how we build our applications.  However - the good news is that we can abstract a large part of that change from our application code using virtualization techniques. The official name that we've given to this pattern is referred to as  Space Based Architecture (SBA). For more information on that pattern you can listen to podcast from a presentation that was given during the last TSS Symposium event.

By the way – when started talking about tier-based architecture, my wife lost me. But the production line worked. Try it…

Oracle aquisition of BEA - The kiss of death for the "open" J2EE App Server

The claim to fame of the J2EE application server market was the ability to define a standard platform for running business applications, and then have multiple vendors competing on providing the best implementation of that standard. Oracle's acquisition of BEA marks an end of an era in that regard. Let's face it, there is no real open market out there. Both Oracle and IBM are now trying to push their bloated solution packages, which have very little in common with each other.

So what does it mean?

First I'd like to start with an interesting analysis (A MUST READ) by  VAUHINI VARA and BEN WORTHEN  As Software Firms Merge, Synergy Is Elusive  about software acquisition strategy:

"As the big software companies flesh out their integration plans internally, customers on the outside are left with unanswered questions about their future. It often takes years for software makers to integrate all the products they have bought -- if they manage to at all -- making it hard for customers to decide what to buy in the meantime. Some customers worry about losing negotiating power in the long run as the number of product choices dwindles. And all the dealmaking can crimp a CIO's ability to plan, since it's unclear which software makers will survive."

In this specific case, Oracle and BEA have a lot of overlap in their product portfolios. I expect that it's going to take some time until all this huge merger will shape up.

But who needs J2EE application servers anyway?

We can't ignore the fact that this acquisition comes at a very interesting time. A time in which people are actually moving away from J2EE application servers, so an investment in an application server that is already mature and has a hard time to keep up with market trends as is more of an investment in the *past* and is going to further slow down any new development. In turn, this uncertainty will accelerate the trend for moving away from WebLogic. To understand this, see what John Matelski, Chairman of the International Oracle User Council wrote in an op-ed that is posted on Oracle’s own website:

Oracle’s dual commitment to Oracle Applications Unlimited and Oracle Fusion has always given fodder to the grassy-knoll folks. They point to the existence of both as proof of a lack of commitment to either, theorizing that trying to fund both initiatives will inevitably lead to a dilution of resources and, ultimately, a delay of Oracle Fusion or nominal support of Applications Unlimited.  And they already  announced a significant delay in Fusion Apps to 2009.

So what are the alternatives?

The good news is that the alternatives are not just IBM or to a lesser degree JBoss, the alternatives is based on open source and new platforms geared for SaaS, a-la-SalesForce, Amazon and Google as noted in another analysis here:

One wild card for Oracle is open source software, a movement that has seen growing traction and has expanded from the lower operating-system level to business software. Open-source software is freely available, collaboratively developed and often sold in the form of service subscriptions. It poses a long-term threat to the proprietary software at the heart of Oracle's business.

The open source movement has created an interesting alternative stack based on frameoworks such as Spring, Hibernate and Tomact, as well as new frameworks that are growing in popularity in the SOA world, such as Mule. Web 2.0 has generated innovation, such as Haddop (open source framework for parallel file search), Lucene (index server for search engines) and Compass (equivalent of Hibernate for Lucene) -- and lots of AJAX frameworks. Amazon and Google are gaining rapid adoption of their innovative SaaS platforms, which offer a cost effective alternative to IBM and Oracle. 

Where does GigaSpaces fit in?

For GigaSpaces this announcement has great timing. Many organization are already building their own open middleware stack as a strategy – we basically help them to go all the way with that strategy by complementing those frameworks with runtime capabilities that address scalability, high-availability, performance, latency, deployment management, monitoring and more.

The combination of GigaSpaces and the open frameworks, creates and Open Application Server alternative that is compatible, but independent from, the existing application servers. It is not necessarily bounded to a specific standard, but is still compatible with different platforms that support those same open frameworks, thus avoiding vendor lock-in. Specifically, users that build their business logic using Spring would be able to run that same application on top of WebLogic or GigaSpaces.

At the end of the day, GigaSpaces' value is measured on our ability to improve performance, scalability and simplicity, not on the API itself.

What makes GigaSpaces different than alternative application servers?

The vision is to be able to plug-in GigaSpaces to any existing development framework and give it a boost without touching the application. This is very similar to how storage works today: our application can access the storage device in a similar way to how it accesses local disk. This is achieved through virtualization, which abstracts the application from the underlying physical instances it actually utilizes.

We're already making headway through the Spring support we added, and more recently, Mule and Lucene. Other frameworks will soon follow.   To reach that goal we developed a unique approach for integrating these open frameworks. Instead of just bundling them together as separate tiers, we developed a virtual middleware framework, which provides data virtualization as a Data Grid, as well as Messaging virtualization and Services Virtualization, using a common runtime and clustering framework.

This way, applications that run on GigaSpaces can run across a compute cloud and scale dynamically when needed, while keeping the application code abstracted from the fact that it runs over a cloud. In addition to middleware virtualization, we also provide deployment virtualization through our SLA-driven container. This enables to abstract the application from the physical deployment environment.

Applications are deployed based on requirements such as hardware specifications (machine type, memory capacity, etc.), or software specifications (JVM version, OS, etc.). It also adds self-healing capabilities to automate the behavior in case of failure or a scaling event.  As a result, developing and running an application over the cloud is as simple as running on a single machine.  Testing also becomes extremely simple, because you can easily run the code on a single machine, and without changing anything, run it on the cloud to perform system testing; true agile development.

On top of that, we designed our platform to support Java, .Net and C++ out-of-the-box, and provide interoperability at the binary level, without compromising performance.

What does it mean for you?

If you're using WebLogic today, and wondering what should be your next step: the Open Application Server framework helps you to avoid making any strategic decisions today on a particular platform. You can write your application using Spring/Hibernate/Tomact, knowing that many vendors already support it. You don't have to wait until the big vendors will figure out what to do with their bloated stacks. There are alternatives out there, and obviously I believe GigaSpaces is one of them, that enable you to maintain compatibility with WebLogic or WebSphere, without being dependent on them. This way, you can achieve all of the benefits that GigaSpaces and the like can offer in terms of clustering, scaling, latency etc. with little risk.

What if I'm already using another caching product such as Coherence or Terracotta?

That's fine – as both Coherence and Terracotta support Spring, it's easy to plug them into our existing platform and enhance them with our messaging capabilities, as well as our SLA-driven containers and deployment capabilities. In fact, this combination would work much better than running them within WebLogic for many reasons. The main one is our "tier-less" approach and virtualization capabilities.  The fact that we can rely purely on memory for high-availability makes our platform extremely efficient compared to the alternative. In addition, it was designed from the ground up for the scale-out architecture model, which helps get more out of the data grid/caching products. Our native support for Spring makes the integration and configuration extremely simple.

Will it help me to reduce costs?

We conducted a benchmark that compares an Order Management System based on WebLogic/Spring vs. the SAME code running on GigaSpaces/Spring. It shows that by running on top of GigaSpaces you can reduce the total cost of ownership significantly due to the following factors:

• Increased server throughput which reduces the amount of servers and software licenses required to handle the same volumes
• Shorten time-to-market of new software products and services by:
  •     Reduce deployment complexity – there are no moving parts, just a single “cloud”
  •     Cut down testing and tuning cycles – to scale, simply drop in more processing resources with no code changes
  • Avoid development complexity – no need for complex J2EE application server configurations
• Increased reliability through better testability and self-healing capabilities
• Lower maintenance overhead through better manageability
• Utilize a single platform for Java, .Net and C++ 
• Utilize the same platform across various application types: transactional, web, real time analytics

The benchmark shows that cost-savings grow exponentially as the scaling requirement grows, due to the fact that the alternative cannot linearly scale.

Final words:

Oracle's acquisition of BEA is the kiss of death to J2EE Application Server platforms. History shows that this type of move takes a lot of time to mature, and in many cases, fails. It comes at an interesting time when many people are moving away from WebLogic and the likes. It looks like this move is going to push oracle even more to support legacy applications, while the market is moving in a totally different direction.

I wouldn't be surprised if the year of delay that with Fusion would repeat itself. Instead of developing yet another application server, we decided to focus on enhancing the open development frameworks in a seamless fashion, and through that, create an alternative Open Application Server platfrom. This approach not just saves you the need to make a strategic decision today, but it also takes you a step toward the next wave of application development: scale without re-architecting your system, and make it simple to develop,test and deploy. 

TuneWiki scale-out architecture

Geva Perry, and Jim Liddle wrote nice posts about the work that was done by our partner GridDynamics to scale-out TuneWiki using GigaSpaces. "GridDynamics is a GigaSpaces partner, headed by Victoria Livschitz, that has been doing tremendous work around our product. Check out their web site and the very cool projects they are working on in their blog, including the GigaPult project and the GigaSpaces Maven Archetype."

Here are some of the technical aspects of the work on TuneWiki.

This was the original architecture:

 

It consisted of:

• 2 Dell 8-CPU blade servers,
• Windows 2003,
• PostGRE SQL,
• Delphi-based API, IIS

The new architecture has the following topology:

 

It was built using:

• 2 Dell 8-CPU blade servers,
• Ubuntu Linux,
• PostGRE SQL,
• Apache Tomcat,
• TuneWiki Servlet,
• GigaSpaces XAP 6.0 - Data Grid/SLA Driven Container
• Spring - through OpenSpaces/Spring framework

Tomcat replaced the IIS server and was used for the front-end for user requests with a thin client user interface. The GigaSpaces Data Grid (read/write distributed cache) is used as the shared data store holding the lyrics information. The GigaSpaces  data grid is front-ending a PostGRE database using a PaaS (Persist ence as a Service) approach. With this approach the lyrics information is loaded to memory during initialization. Updates are done in-memory and kept synchronized with the back-end database through an asynchronous reliable replication mechanism to ensure that all updates arrive successfully to the underlying database, even in the event that one of the memory instances crashes.  This enabled a system throughput increase of 6-8 times compared to the baseline JBDC servlet, and a 20 times increase compared to the original version. The system can easily scale by adding additional instances to the GigaSpaces In-Memory Data Grid. System availability is ensured by the GigaSpaces fail-over mechanism.

Because the database was moved to a background server, the system can survive a database crash or downtime without effecting the users. During the downtime, users are served by the Data Grid. The Data Grid keeps logs of all the changes and "replays" them to the database when it comes back to life.

The SLA-driven container simplifies the deployment (it makes sure that the primaries and their backups do not run on the same machine. If a primary fails, the backup will become a primary and the system provisions a new backup. Concurrent client scalability is achieved by making the servlet stateless and load-balancing the http access.  From a capacity perspective so far it has gone as high as a quarter billion streams per day!

Summary:

The TuneWiki case study is interesting, not just because of the scalability it demonstrates, but because it shows how simple it is to scale. The fact that a complete re-write of the application was done in a very short period of time (a few days) is the best proof that with the right tools a Java-based web framework can be as productive or even more productive than the alternatives. It also shows that once scaling becomes simple, it can be easily applied at early stages of the application deployment, avoiding the need for continuous re-design. The use of the SLA-driven container demonstrates how concepts from the grid world can be successfully applied to next-generation web applications, and provides self-healing and automation capabilities.

If any of you have a cool application or idea like this one, it's not too late to submit them to our Killer Application contest and win the $10k grand prize!

What a year!

For the past few days I've been trying to write a 2007 summary, but I found this task to be extremely difficult because so many things happened this year on so many fronts. I thought that it would probably be best if I'll start by thanking all of our customers who chose GigaSpaces. Special thanks to those who were kind enough to be public about their choice as you can see here ,here and here

This year we saw that many customers found that GigaSpaces and caching solutions are almost incomparable due to the tremendous progress we have made with our 6.0 release (More details provided below). This led to an interesting trend: Customers who already worked with one of the alternative caching products decided to add GigaSpaces to their environment in conjunction with those caching products. In this context GigaSpaces acts as a high-performance SOA platform through the use of our SLA-Driven Container, as well as the messaging bus and Spring components. In fact, in Q4 we closed a very large enterprise deal with one of the leading investment banks for exactly this reason.

I expect that during 2008 we'll see more of this as we plan to provide official support for these sorts of mixed environments. If you think about it, it makes prefect sense. In the JEE world this is a fairly common scenario. For example, it's common to have WebLogic as the application platform in conjunction with other components, such as databases or messaging middleware from other providers, even though WebLogic offers these components. I call that a middleware mash-up:)

Another interesting trend that we've seen is a new class of customers using GigaSpaces:

1. Customers from other industries, such as Web 2.0 and online gaming (as you can imagine, there is similarity between the two)
2. Customers who chose GigaSpaces mainly to improve the reliability and responsiveness of their online services. This included online banking applications as well as an order management system for the launch of a cool phone in Europe (I apologize that at this point I can't give more details).

We've also seen increasingly more customers who chose Spring+Hibernate as their middleware stack and wanted to maintain the high availability, scalability and performance of their Spring application without the complexity of J2EE.  Rod Johnson of SpringSource gives a nice explanation of this in this presentation, which is available online here (See slide 33), and in this blog post:

Is it a Tomcat, or the Elephant in the Room?

"...An interesting force is that the highest performing grid/clustering solutions are not the app servers themselves, but specialist solutions such as GigaSpaces, Oracle Coherence and IBM ObjectGrid. There is no reason that HA features need to be associated with Java EE servers."

From a product perspective, we had ambitious goals to enable the scaling-out of stateful applications (the entire application, not just the data) in a way that will be as simple as running it on single machine. The other challenge was to enable the transition of EXISTING tier-based applications to the scale-out model in a *seamless* manner, just by plugging-in our runtime implementation.

We managed to achieve these goals by working on several fronts:    

• Develop a blueprint based on best practices to achieve scaling, latency, performance and reliability in a scale-out model. We refer to this blueprint as Space Based Architecture (SBA).
• Extend our product to support SBA by adding built-in components, such as the processing-unit, and event containers.
• Provide an end to end approach for virtualization of the application in a scale-out model through:

• Middleware virtualization - (Data, Messaging, Services)    
• Deployment virtualization - through our SLA driven container

• Provide seamless transition from the tier-based model to a scale-out model through API facades and declarative abstractions. 

To validate our assumptions, we took a classic transactional application based on the tier-based model and compared it with SBA in terms of complexity, performance and latency . We applied the SAME CODE to both tests (the only change was within the DAO). The results of the test showed, beyond any reasonable doubt, that Space-Based Architecture can drive applications to linearly scalable performance and flat latency during scaling events. You can view the results of this test in the following presentation Scale Out Your Spring Applications in 3 Simple Steps. More details can be found here.

On the data virtualization front, we introduced capabilities such as PaaS - Persistency as a Service and .Net support that addresses both performance and the completeness of our Java-based feature set, including support for SBA (not just caching), and pure .Net components, such as SessionState. We already customers who have been in production for some time with a pure .Net system, built entirely on top of GigaSpaces.

Later in the year we introduced our partnership with Microsoft and our strategic integration effort with Excel. You can find more details on this exciting solution in this white paper. I also gave an online demonstration of it in the latest Grid Association event available online here.

We have also made significant progress with our C++ version, and have prospects running with our private beta of our new C++ support. The new C++ release is going to revolutionize the simplicity in which C++ applications can be written in a distributed environment.  Public beta will be available until end of January .

What's interesting is that we were able to maintain native API support in each language and complete interoperability among Java,.Net and C++ using what we refer to as Portable Binary Serialization format (PBS). This enables interoperability without compromising on performance! We are even able to run C++ services as part of our SLA driven container, which means that you can deploy C++ services just by pointing your service to the dll or shared library. This means that the C++ service can also run embedded within our OpenSpaces Processing Unit.

We made a huge effort in ensuring all these new capabilities are simple to use. Our choice of Spring for our new development framework - OpenSpaces - paid a lot of dividends, as it enabled us to simplify not just how you wire the caching component to your application, but also how you develop, test and scale your entire application in a "cloud" environment. To Spring users, OpenSpaces will fell like a native extension of their existing development framework, where complex things such as transaction handling, partitioning, scaling, fail-over and deployment are abstracted from their development code. Here's an example of feedback we received from one new user who tried our platform, Srini Penchikala:

I have been trying GigaSpaces on my local computer to learn more about
the framework. It's a great implementation that supports simple design and
a scalable and performant solution. Integration with Spring framework makes
GigaSpaces even more powerful.

You and your team have created a great product.

Another effort that helped us achieve simplicity is our award-wining documentation wiki and its Quick Start Guide and webcasts, which provide a walkthrough for writing your first scalable application.

In 2007 we also launched several major community and open source initiatives. One such initiative was our open source development framework, OpenSpaces. Another one was the Start-Up Program (which complements our existing free community edition).  We also announced our killer application contest, in which users can put their skills in distributed programing and scaling to the test and win a $10k grand prize. Some of the interesting submissions that have already been made include applications that will scale on Amazon EC2, scaling the Lucene search engine, scaling gaming applications, integrating OpenSpaces with PHP and other cool ideas. We're going to continue down this path during 2008, and open up more aspects of GigaSpaces, such as our Product Management processes. See below what one of our users had to say on our forum:

All I want to say is that the forum is awesome....so quick response. Thank you all involved with GigaSpaces for providing such nice support

We will also be officially announcing our new developer community portal, OpenSpaces.Org, by the end of January. It is a collaboration platform for users in the GigaSpaces community by sharing code, suggesting and contributing extensions, as well as providing tools and examples.

Now if this wasn't enough innovation wait until you see what we have planned for cloud computing:) We started an effort to enable GigaSpaces deployment on the Amazon Elastic Compute Cloud (EC2). We're about to release our second update of this and the plan is to have it fully integrated with our product release in 2008.

When I look back I'm quite proud of how a company our size is able to get all of this done. Indeed, we wouldn't have been able to achieve all of this if it weren't for the tremendous effort of our R&D team. It started with some new strategic hires and continued with a major investment in making our development process extremely efficient by applying new agile development methodologies such as Scrum (see this from Guy Nirpaz, EVP of R&D, here).

We also made a substantial investment in automating our testing process by developing a distributed testing framework we call Tigris. This framework enables us to run tests on multiple platforms (Windows, Linux, Solaris), Java (1.4, 1.5, 1.6, Sun, JRockit, IBM), .Net, c++ (Windows 32/64, Linux 32/64) with different cluster sizes and topologies -- all fully automated. It has become so successful that we're actually being pressured by our customers to provide them with our testing framework and consult them on our methodologies.

2008 looks very promising. I see great opportunity for GigaSpaces to become the de-facto scale-out platform. I expect to see continued adoption from the in the Spring community seeking a solution for scalability and high-availability, without the complexity of J2EE. I also expect to see greater adoption in the Web 2.0 market, as we're adding support for dynamic languages, as well as integration with web frameworks. As I mentioned, we're going to continue our effort to support Amazon EC2 as part of our platform to enable a simple evaluation of our product, run distributed testing and run a full-blown on-demand production environment. I expect that the significant progress on the .Net and C++ fronts with our next release will enable us to further penetrate those areas as well.

I'm very excited by all this progress and working closely with customers who are building their mission critical applications on top of GigaSpaces. What's nice about it is that our customers never cease to amaze me with their appetite for achieving even more. They are moving so fast in building large clusters that one of our next goals is to allow simple, out-of-the-box large cluster deployment and massive object sizes. With all this excitement,  I decided that this year I am finally going to spend some time and write a book...

Happy New Year!