I was in a customer meeting last week and we were talking about what Terracotta means by transparency. The definition became clear by example. The customer wanted two things:
- Code that worked with or without Terracotta present
- An eventing / listener pattern that worked across threads in 1 JVM and across JVMs with Terracotta
They were thinking of using Terracotta Distributed Method Invocation where a method can be annotated such that entering it on one JVM causes some threads somewhere in each JVM in the cluster to also enter that method at the same time. But this would fail to meet their needs as there is no notion of distributed methods when Terracotta is not present.
So I pointed out that we can do base wait() and notify() clustering. They thought that this was kewl and it would work transparently, but then they added another requirement, "things have to be simple / abstracted from the average team member."
The solution was Spring Events. Terracotta clusters Spring internals, which no other solution on the market can do. The Spring Eventing solution provides simple abstraction of eventing / listeners and then extends that listener pattern out to a cluster of JVMs when TC is present. "PERFECT! They exclaimed."
This brings me to my point. Vendors all speak in hype, jargon, and gobbledygook.
Another example...there are many vendors who offer "POJO clustering with Spring Beans" including Terracotta. What's the difference? POJO is POJO, right? Wrong.
Forget POJO. POJO was well-defined by Fowler and is really not to important to this discussion. What is critical is that Terracotta uniquely works from within Spring to cluster many Spring internal constructs. When using another "Clustered Spring" architecture, what is happening is that Spring is injecting the clustering vendor's objects into Spring Beans at runtime, making the lifecycle calls to the clustering library transparent. This is identical to when Spring injects a messaging dependency, or a database dependency, or an O/R-mapper dependency. Spring is doing all the simplification. Spring is doing all the work. This speaks to the power of Spring, not the clustering vendor's product!
Terracotta is the only product on the market that takes a Spring singleton and clusters it (at least about which I am aware). Terracotta clusters the Spring app context, Spring Events, and more and nothing else can.
In short, I get worried for you--the user--when all the vendors boil things up to such a high level as to just say "we lower costs and make things easier." Well duh! If your software didn't lower costs and didn't make things easier, why would I buy anything from you?
The question is how does a particular solution help? In what specific way does it help?
Let me try explaining the unique value of Terracotta without jargon, and please give me feedback as to whether I succeeded or not:
Transparency
Terracotta can drop in and drop out. I have said it before. Only Terracotta can take an application and spread that app across JVMs; and only with us can that app still run on one JVM when Terracotta is completely removed / deleted. Think about a database-backed Hibernate app. Most development is done in POJO when using Hibernate (esp. with Spring). But delete Hibernate and there is nothing making calls to the database leaving the app with no way to reach its data. Clustering vendors other than Terracotta, when removed, will break the application! Terracotta believes that transparency leads to flexibility and simplicity. That's why we made the product this way.
Low latency, high throughput
There is lots of discussion of partitioning out there where the rhetoric goes something like, "moving the data adds latency and thus partitioning will lead to zero latency by bringing the compute to the data instead of the data to the compute." The problem with this claim is again that it clouds the real issue. Only Terracotta plugs directly into heap / RAM. This means that when threads need data, those threads needn't copy an object from the clustering library's internal cache into a POJO. With Terracotta the object you hold a reference to is the object you in fact read from. Reading memory-resident objects is the only way to achieve zero added latency. And as for high throughput, since Terracotta is not creating copies of objects for every thread that needs a reference, we in fact do not add new garbage to the app. A customer last year tested for themselves and found that Terracotta-based clustering delivered 300 requests / second per app instance whereas the nearest competitor delivered 100 requests / second per instance given a certain load generating script. What was key, however is that the application under Terracotta was using 30% CPU whereas the competitor-based version was using 95%. Terracotta could be driven a full 3X faster leading to nearly 10X the throughput. Serialization / deserialization was the other vendor's bottleneck. What happened to "moving the compute to the data?"
See what I mean? jargon and gobbledygook leads the community to think that solutions are similar in terms of transparency and performance. Meanwhile, discussion and actual use cases like the one last week makes it clear to me that the similarities are only in message, not in implementation or capabilities.
This is part of the reason we open sourced Terracotta. It is not the same and the best way to confirm is for yourself. You will find that, while it is not perfect, it is as transparent and can be as fast as I am asserting. Will you have to make application changes in order to scale? Maybe. Maybe not. But our definition of transparency is to be "drop-in / drop-out" and no more. Don't be afraid of a few changes.
Is transparency important to you? Is simplicity?
Is scalability? And the lowest latency possible? Is a memory-read operation the lowest latency that can be achieved in your opinion? Or is there something faster that I do not see?
Let me know! And good luck, whichever path you choose!
--Ari
