Simple scalability - that's the Terracotta value proposition. In this Quick Q&A with SYS-CON's Cloud Computing Journal editor-in-chief Alan Williamson, Geert Bevin (pictured) - Evangelist at Terracotta Inc - explains that how Terracotta helps enable Java in the Cloud...and clarifies the difference between the commercial and OSS editions of Terracotta.

Cloud Computing Journal: In a nutshell what is Terracotta?

Bevin: Terracotta's primary value is simple scalability. We deliver this using a high-performance distributed durable caching technology we call Network Attached Memory (NAM): NAM hooks right into the memory of the Java Virtual Machine (JVM) and allows users to share critical in-memory data between servers within the application tier, thereby avoiding unnecessary use of the database as a coordination point or a high availability mechanism. Databases as central "traffic cops" could become a scalability issue in many applications, especially those deployed in cloud infrastructures. We work with a lot of Java frameworks, including Spring and Hibernate, in a plug-in fashion, but you can also use Terracotta to scale and cluster Plain Old Java Object (POJO) applications as well, since we can hook directly into Java memory at the platform level.

Cloud Computing Journal: Is this a more sophisticated memcached for Java?

Bevin: Many people have used memcached with great success, but Terracotta does offer some capabilities that memcached does not. First, for those parts of memory it has been configured to share, Terracotta writes all memory changes asynchronously to disk, so the memory state is recoverable in the event of any hardware failures or machine restarts. With Terracotta, a server shutdown or power failure doesn’t mean important context for the application is lost. Second, Terracotta can provide a distributed read/write cache that is coherent across all application nodes. Also, Terracotta also has an in-process caching layer right in the application server’s local JVM, so many reads never even leave the local machine; with memcached, you have at least one network hop for any read out of the cache.

Cloud Computing Journal: To what is Terracotta ideally suited?

Bevin: Terracotta is ideally suited to applications where scalability is a concern, where you need expand capacity on the application tier easily while maintaining high performance or when you want to ensure that any member of the application tier can take work over from another with no loss in application state. In applications where the database is being used as a central point of coordination, Terracotta can be an excellent fit for reducing database bottlenecks and database licensing and hardware costs.

Cloud Computing Journal: Is Terracotta Java for the cloud essentially?

Bevin: Terracotta definitely makes it much easier to run Java applications in cloud environments, since we can make elastic expansion and contraction of the application tier much simpler to manage. Terracotta shares data with just TCP/IP ­ unlike many other solutions, theree are no multicast requirements, so set-up and provisioning are much simpler. Our partnership with VMware augments this capability, giving users all the push-button management capabilities they expect from VMware, including easy provisioning with server isolation, guaranteed resource capacity to meet SLAs, and more efficient overall hardware utilization. Furthermore, Terracotta offers streamlined change management and enhanced application integrity from application memory that is resilient to failures/restarts and can be shared between servers. This creates a truly adaptive, on-demand deployment model in which an application server within, or added to, the cluster can seamlessly take over the workload from any other server.

Cloud Computing Journal: What is the maximum amount of memory I can store?

Bevin: Online, the "hot" items need to be in RAM because Terracotta automatically swaps the least-used portions of Java heap out to our server array where everything is also copied to disk for recoverability. Essentially, the Java heap can be as big as the available disk, subject of course to reasonable garbage collection considerations. This means users can build a distributed cache without worrying about the amount of RAM on each machine. You don't need enough RAM to contain the whole cache.

Cloud Computing Journal: Just how much can Terracotta scale out to?

Bevin: Terracotta is deployed in some very large applications in industries like financial services, travel and leisure and online gaming. Terracotta delivers mainframe-class transaction volumes with dozens of connected application servers and multi-server Terracotta Server Arrays. The product is also deployed in a large number of applications with two application servers where Terracotta’s HTTP session replication was faster and simpler that other solutions. So there is a range of successful deployments, from two servers to 150 running on Terracotta.

Cloud Computing Journal: Have you any numbers you can share, with say, Amazon EC2?

Bevin: Terracotta has been working on EC2 for more than two years now to include some customers who run key IT components for their business entirely on EC2. We’re in the midst of some testing to establish performance numbers we can share in more detail later, but it is already clear that Terracotta scales linearly in EC2. In our benchmark HTTP session replication test the application scaled linearly to 35 JVMs with one Terracotta server in the server array, and when a second Terracotta server was added, the application scaled linearly to 70 JVMs. We can very easily add or reduce incremental capacity to an application in EC2 to meet changes demand; more importantly, we can also make sure that new servers are immediately aware of application context so they can take over activity and ensure that no work is lost as servers are taken offline. The in-memory data the application needs to function seamlessly across changes in cloud topology is all handled easily and reliably within Terracotta. The types and number of EC2 machine instances you need will, of course, vary with workload, especially since throughput tends to be a bit lower in cloud infrastructures.

Cloud Computing Journal: What is the difference between the commercial and OSS editions of Terracotta?

Bevin: The free OSS edition, Terracotta ES, has all the core clustering features that enable simple scale-out for Java applications, as well as the Developer console that customers use as a valuable visual tuning aid to eliminate a lot of work. Terracotta ES is a great way to do development and testing; when you get to production, though, you should consider Terracotta EX or Terracotta FX. Terracotta EX has the same general feature set as ES, but comes with phone support, support SLA, and a commercial license with wider distribution rights. Terracotta FX includes the support access, SLA, and commercial license of Terracotta EX and adds not only Terracotta Server Array Striping, which allows users to stripe data across an arbitrary number of Terracotta servers, but also the Operations Center, a user interface that lets operators manage a number of applications running on Terracotta more easily (including taking backups and performing advanced diagnostics).

Cloud Computing Journal: A Terracotta server is always required; what sort of specification does that machine need to have to ensure the whole cluster does not suffer performance?

Bevin: The right specification for the servers in the Terracotta Server Array depends on the application workload, but we have seen applications run successfully on a range of devices, from commodity x86 hardware to bigger machines like SPARC gear from Sun. The same goes for a case like EC2, where we've seen various machines in use, depending on workload.

Cloud Computing Journal: How do network delays affect the distributed nature of the app?

Bevin: Terracotta only sends the bytes that change over the wire, not entire objects, so we're less sensitive to network delays than competitive solutions , which generally cannot propagate these "fine grained" changes to data as well as we can. Also, if you load-balance and constrain data overlap on application servers, there is very little coupling between machines; this means that only a reasonable amount of data needs to be sent through Terracotta to provide proper coordination, further reducing any sensitivity to network delays.