LAS VEGAS – Ari Zilka, co-founder and chief technology officer at Terracotta, a Java clustering solution provider, says the company is poised for growth in an era where clusters, grids and cloud computing are becoming commonplace. Zilka, who once held the position of chief architect at Walmart.com, spoke with eWEEK Senior Editor Darryl K. Taft at TheServerSide Java Symposium here.
Can you summarize what Terracotta’s mission is and what its software does? I know you have a clustering solution, but what’s your claim to fame?
Terracotta’s claim to fame is having been the first purveyors of networked attached memory or JVM-level [Java Virtual Machine] clustering in the market. Terracotta helps you scale Java applications linearly across a bunch of machines without making code changes. Further, we help you start simple on one or two nodes and stay simple as you grow. This saves you time and money.
The way we deliver this simple scalability is that we plug in to the JVM instead of to your application’s source code. Ours is the only technology on the market that allows applications to trust their local memory view of the world at all times instead of having to work through APIs. This means that we are the lowest latency provider of scaling because your application memory operations happen directly to local memory, always. Simultaneously, we are the highest availability solution because we write all changes to memory to disk in our Terracotta server process. This means an application running on top of Terracotta is completely re-startable from a data center power failure without losing any information.
Users rely on our speed and availability to lessen their dependency on Oracle. If you had a JVM that could spread across hardware machines and whose memory was durable and couldn’t be lost even if the JVM was stopped, then there would be a class of application data you just would not bother putting in Oracle anymore. Especially because Oracle or other relational databases tend to get used underneath Hibernate inside Java applications for sharing data across application instances, and for a durable storage end point for business objects.
With Terracotta, just use Oracle for SQL queries and reporting. Otherwise use Terracotta as Network Attached Memory underneath Java machines, making those JVMs look and act like one.
The end result of running an application with Terracotta instead of a database is that developers see a simple object-oriented program without Hibernate or JMS [Java Message Service] while production operations teams find that they have no single point of failure and add-a-brick in order to scale at runtime.
Where does your expertise come from?
Our expertise stems from our work at Walmart.com. There we were the platform team, responsible for the core application server, its scalability and availability characteristics and the ease of development of the Web site running on that application server environment. We learned there that developers find a stateful, in-memory object-oriented programming model easiest to work with, but operators cannot live with the complexity where no JVM can safely be powered down if all data is only in memory. We learned that operations folks benefit from a stateless model where all the data is stored in Oracle and the entire site could be started [and] stopped without losing any data or transactions.
It was at Walmart.com we also learned that Oracle’s database is woefully mismatched to the task of supporting arbitrary and linear scale underneath modern n-tier applications. So we at Terracotta have been wrestling with the question for a long time of how to deliver the ideal development model and operating model simultaneously for scaled out Java applications running on top of a database.
You guys recently released version 2.5 of Terracotta [in December]. What are some of the highlights of that release? What have you been working on since the 2.5 release?
Terracotta 2.5 is actually quite old now – 2.6 will be out in less than a month. [Terracotta] 2.5 introduced Maven support for people working with Terracotta during development. It introduced better Hibernate second level cache support, and [offers] a few tuning tools for getting applications running on Terracotta to scream.
While 2.5 was focused on making Terracotta work with more frameworks such as Hibernate, 2.6 has had a singular focus-making it possible for the average user trying to lessen their dependency on Oracle to get Terracotta integrated, tuned and launched into a production environment in seven days or less. To that end we have been doing what I call making the engine bigger and providing more telemetry into what our engine is doing at runtime.
We have now reset the bar for the industry on how easy it is to visualize what a clustered application is doing with its objects at runtime, as well as how easy it is to make an application go faster with minimal changes. [Terracotta] 2.6 is between 30 percent and 300 percent faster than 2.5, depending on the use case. And I personally witnessed, just yesterday, an open-source framework person integrate his technology to Terracotta in under 30 minutes, and then tune it to go over 100 times faster than his initial model, all in less than four hours end-to-end.
The Terracotta model is going to continue to get easier to adopt throughout this year, meaning our focus will remain getting people to production in less than seven days from initial download.
Growth and the Future
Terracotta also recently received another round of funding to the tune of $10 million. What do you plan to do with that?
Terracotta has very many paying customers today and we add more every week. This year, however, our goal is to grow the revenue by about 10 times from last year. You might think that this implies we will invest in scaling the sales team by 10 times, but we will not. We are investing in growing the core engineering team with these funds. We are currently the largest clustering entity that I am aware of [20 to 30 developers working on core product almost 24×7 around the world]. We intend to grow the team in order to introduce more performance, more tuning tools and more platforms and frameworks even faster than we deliver these today.
Our CEO and I are in total agreement that our business should scale by making the product easier to integrate and faster to deploy toward the goal of saving yourself database licenses and CPUs. It shouldn’t grow purely by brute force.
What is Terracotta’s value to the customer? That is, why would a customer choose Terracotta over … Oracle or GigaSpaces or Appistry?
Terracotta is designed to give developers pure Java and object oriented programming universe where the JVM boundaries melt away without needing messaging or databases while simultaneously delivering a runtime where any JVM can be stopped arbitrarily without regard to what it was doing-stateful objects and stateless memory written to disk in a single platform at the same time.
This lowers the database dependency for the average app by as much as 90 percent while simultaneously increasing application throughput by 10 times, as measured by our users.
Users regularly report that we are 10 to 100 times faster than alternatives, and since we are flushing all data to disk at those speeds, we can uniquely be used for mission critical data that you would otherwise assume must belong in Oracle’s DB. Sure, keep your users, sales order, products and inventory information in Oracle’s DB. But you can work with these objects for arbitrary amounts of time outside Oracle without risk of loss or inconsistency.
We’re fastest, most reliable, and, at the same time open-source software (OSS)-so free unless you want to pay.
What’s Terracotta’s relationship with the Spring Framework and SpringSource the company?
I have lots of respect for the Spring folks. I wish we and they had more time to spend together, if simply for the fact that they want to make enterprise Java applications very easy to build and maintain while we want to make apps easy to scale and run in a production environment. Our charter is quite complementary and we both understand that. But both they and we are mostly heads-down working through giant queues of features in our own products.
That being said, Terracotta has direct support for running Spring application in a Terracotta environment. I think more than 50 percent of our users use Spring. It is and will remain important to us.
Some critics have said Terracotta’s technology appears to be a lot of hocus-pocus-that your process of enabling users to run a clustered application but yet write to a local JVM is essentially a lock-in strategy. Is that true?
I think you are asking two questions. I used to hear the hocus-pocus claim in regards to our technology sounding too good to be true. We open-sourced so that those who are so inclined can read the source code to see how it works. We also open-sourced because the OSS community wanted to integrate and rely on our approach inside their frameworks and products which was impossible if we were proprietary. Today we integrate with and are used by more frameworks than all other options combined. As for lock-in, yes, you are locked in with Terracotta. We are the only solution that clusters applications at a JVM-level allowing them to scale nearly linearly without changes. I like to say that with Terracotta you cluster the application you wrote instead of having us dictate to you how scalable applications must be built. That’s lock-in, but only because the alternatives ask you to tightly couple and embed their architecture and scalability approach in everything you do.
What’s Terracotta’s strategy for scaling transactional applications?
Terracotta is internally transactional and all nodes always have a consistent, up-to-date view of the data. As a result, our view is leave the replication to us especially since we don’t replicate. Avoid transactions as much as you can. Only introduce them when you want to read from one system of record and write to another atomically [e.g., writing two databases at once as part of one business operation].
Always remember that Terracotta persists to disk at in-memory speed so getting us to participate in a JTA [Java Transaction API] transaction using an external data source as our backup is just not needed.
Terracotta and the Database
How many Terracotta servers can be active at one time?
Your question probably refers to the simplest use of Terracotta that most clustered caching vendors like to point at where one Terracotta server is active at a time. This is the default and is designed to be highly scalable and available and low effort. It is not the only mode we support, however.
The correct answer is any number. We have options where the number of active servers is transparently managed by Terracotta. We also, somewhat obviously, allow developers to chop up their data manually and run any number of application partitions. The first form is transparent and automatic. The second is not transparent and requires manual partitioning strategies.
Do you see Terracotta as replacing the database for users?
No. I have run companies in the past whose products were databases. I know the difference between Terracotta and a database and the difference is quite vast. I cringe, for example, when people ask how to back up a Terracotta server to tape. We are honored to have been integrated in such cases where there is no more need for a database because we are there persisting to disk, but I really don’t want to build a querying engine, reporting interfaces, batch processors, data migration tools and the like for Terracotta. So we don’t replace a database as much as avoid it.
What do you mean by avoid it?
When I say ‘avoid the database,’ I am referring to what I call detached mode. This is simply the act of taking a database entity and instead of Hibernating it to Oracle on every change, closing the Hibernate session and batching up lots of changes before calling commit()-essentially detaching the Hibernate POJOs from Oracle for a while. As an example, take e-commerce shopping carts and checkout. Create a new sales order using Hibernate, but then get the user’s payment info, shipping info, etc., all using in-memory objects and Terracotta. Only when the user hits “confirm order” and the credit card is authorized do you bother to commit all those POJOs back to Oracle. This will save lots of database traffic.
Do you have any plans to support the .Net environment?
Yes. I spoke with Microsoft last year and they expressed interest in making a version of Terracotta for .Net. I always want everything we do to be out in the open and Microsoft is very open to open source working relationships so this is a strong possibility for us.
Do you have any regrets about going open source with the Terracotta technology? How has it been better than remaining proprietary?
In my opinion as an engineer, Terracotta had no choice but to open-source. Our approach is new and disruptive. As a proprietary vendor, we had to go convince everyone who might use it, one by one, that what we do (a) works and (b) is a good idea. As an open-source company, users convince themselves of these two things. By the way, given that I am a developer, the only way I can be convinced that a technology works is to use it. I can’t use anything that I have to pay for up front, before I confirm for myself that it is real. We expect no less of the Java community. OSS is vital to Terracotta’s health as a technology.
And being open has been great. I could quote Web site download and visitor numbers that might be impressive. What’s more important is that I am sitting here at a Java user conference where fully half the people I have spoken with-about 100 in total-have come to me having integrated Terracotta and now having questions about how to optimize their use case. This means developers are playing with it, using it and going to production and that’s what we wanted from open source.
Can you cite any particular success stories of customers using Terracotta?
Well, yes, several. But how about just three for now?
PartyPoker.net, the world’s largest online gaming site, announced a few months ago that they are building their entire gaming platform based on Terracotta, [going] forward. When they made that announcement, they had been in production on various levels for almost a year. Partypoker simplified their code base and increased application throughput by switching from by-hand replication strategies to Terracotta and JVM-level clustering for sharing user and game status in their cluster.
Adobe.com uses Terracotta to make some of their Web site’s online services highly scalable and available.
A very popular and documented use case was done by Mark Turansky of BenefitFocus. His story is quite compelling.