POJO Mojo

History

Orion Letizi, Tim Eck and I worked together on the world's largest retailer’s (read: hundreds of millions of transactions per day) Internet site. We focused on developing tools that other great teams alongside us used to solve business problems. Our customers were those teams of engineers (developers and operators). They used our products and tools because the tools were purported to have addressed operational needs around availability and scalability with minimal impact to the developer's code. However, this was just not the case. We had API's, just like every one of Terracotta's competitors. And no matter how carefully designed, the API always failed to address one team or another's view of their business problem. Teams regularly went out to the Internet and open source community in search of alternatives, most of which ended up being incorporated into the existing development toolkit (Struts, for example) or obviated by our efforts (Apache JCS, as another example).

It quite honestly took our leaving that company and clearing our heads before the light bulb went off. After a few months of rest, with no production system to help maintain, we had come to a key realization: there are design approaches and tools for solving business problems, and there are design approaches and tools for solving operations problems and these tools conflict. The tools needed for solving operational challenges with availability and scalability didn't need to be exposed to the developer of a business app; they should focus purely on business logic. If only that were possible. But that state of the art was clustered caching. While clustered caching is useful, it is incremental in its value add to developers because it changes the shape of the business logic (breaking object identity, flattening object graphs and normalizing them into mapped data structures, etc.), and it is incremental to operators because they are still dependent on developers to address bottlenecks that occur [sometimes uniquely] at runtime.

So, we decided to create Java software that could be invisible, drop-in and transparent. State of the art solutions designed to address operational needs weren’t working. We had tried re-writing the apps and APIs alongside business developers, app by app, and that was too expensive. We decided that we needed to laser focus on the root cause of operational pain--I/O bottlenecks and the associated availability and scalability challenges those bottlenecks pose at runtime. We then worked backwards from the pain to the design patterns that cause that pain (OR impedance mismatch, clustered HTTP session, message-based apps). And we landed on the conclusion that it was truly an application agnostic opportunity.

So Here We Are... Today

We have about four production customers and many labs out there, where we are solving real operational problems. The customer app team meets us in their own lab and we fix the applications right there, together, on the fly.

Terracotta is focusing on Java clustering and caching and the associated I/O challenges. Our Terracotta Virtualization Server (TVS) makes both development and product operations easier. We view the challenge of clustered I/O as a logical “T”, that addresses both horizontal and vertical I/O.

On the horizontal, we are talking about conversations between app servers. Virtualization in the horizontal axis means not having to know how many copies of the app are deployed; virtualizing the VM boundaries with our DSO product. DSO is our clustering component of TVS and allows several JVMs to appear and act like one.

Virtualization in the vertical axis means not worrying as much about the scalability of the SoR and definitely not having to scale the system of record with the number of app servers in the horizontal axis. Our HA-JDBC product caches the data and allows the JVMs to share the cache. HA-JDBC is all about transparency, clustering, and caching, just like DSO.

Today, clustered caching is no longer sufficient. We hear it all the time: the effort of altering the pure business logic for clustering far outweighs the benefits. We have addressed the need that is out there in the Enterprise with our clustering solution. Tomorrow, we promise to stay ahead of the curve by leveraging our industry-lead in transparency to solve other problems of unnecessary complexity (imagine a completely transparent OR-mapper that hides Hibernate completely from the code base...it will take a marriage of our DSO and HA-JDBC products to deliver, but we know we can do it). Check out the evaluation copy of TVS on our web site and experience transparent clustering for yourself.

I encourage you to keep checking back weekly as I dive into more technical Java issues and related topics. Please drop me a line at blog@terracottatech.com with questions and suggested topics. If we use your topic, you will get an awesome POJO MOJO t-shirt (and maybe I will even answer a few questions).

Kewl.

--Ari