Only a recent comment on one of my previous posts made me realize that it's been more than 6 months since I posted anything here. There are many reasons for that, but I guess they all boil down to one simple fact -- I just got too busy.
The good news is that the book is finally out, so I should have more spare time to devote to blogging.
Back in February I did a podcast about a book with Cameron Purdy for the Oracle Author Podcasts series. One question Cam asked during the interview was "why is Coherence such an important part of scalable architectures", and my answer was basically because "it is the right tool for the job". I'd like to expand a bit on that answer here.
The part of a typical application that is most difficult to scale is a data layer. Scaling web servers out is trivial -- you simply add more of them behind the load balancer. Because HTTP is naturally a stateless protocol, HTTP requests can be easily balanced across many machines.
The situation is similar with the application servers, but with an important difference -- in order to be able to scale application servers out, we need to make middle tier services stateless. This is not necessarily a bad thing, but it can lead to both performance and scalability problems if done incorrectly.
Unfortunately, very few services are truly stateless in real life. What is usually the case is that they need some data to process, so the common approach is for a service to load data from the data layer, process it, and persist the result back in the data layer. That means that in order to make application services stateless, we need to push all the state (even the transient state, such as HTTP sessions) to the data layer. This puts additional load on the data layer -- the more web and application servers we have, the harder our data layer will have to work to satisfy incoming requests.
The problem is that most applications use RDBMS as a data layer, and relational databases are both difficult and expensive to scale. When you use master-slave replication, clustering or sharding to scale your database, you significantly increase both the complexity and the cost of the system. Even if you use an open source database, such as MySql, you will have additional hardware and administration costs. In the case of sharding, you will also increase development cost quite a bit.
The bottom line is that relational databases were simply not designed for scale out. Even though we have come up with different solutions to scale them, all of them feel like a kludge to a certain extent, and have some fairly significant limitations.
On the other hand, Coherence and other in-memory data grids were designed with scalability as a primary goal. In the case of Coherence specifically, it is trivial to scale the cluster out by adding more machines. Coherence will dynamically repartition the cluster, which will automatically reduce both the data volume and the processing load across the cluster.
The net result is that in-memory data grids allow you to put state back into the application. This can significantly reduce the load on a database -- it is not uncommon to see database load drop 80% or more after Coherence is introduced into the architecture. They also allow you to keep transient data, such as HTTP sessions, only within the grid, reducing the load on a database even further.
I have covered scalability, as well as performance and availability, in a lot more detail in the first chapter of the book, which can be downloaded for free, but the bottom line is that in-memory data grids can help you achieve all three when used properly within the architecture, and will allow you to use relational database as it was meant to be used -- for data persistence and complex relational queries.