Topics

Featured in Development

Alex Bradbury gives an overview of the status and development of RISC-V as it relates to modern operating systems, highlighting major research strands, controversies, and opportunities to get involved.

Featured in Architecture & Design

Will Jones talks about how Habito, the leading digital mortgage broker, benefited from using Haskell, some of the wins and trade-offs that have brought it to where it is today and where it's going next. He also talks about why functional programming is beneficial for large projects, and how it helps especially with migrating the data store.

Featured in AI, ML & Data Engineering

Katharine Jarmul discusses research related to fair-and-private ML algorithms and privacy-preserving models, showing that caring about privacy can help ensure a better model overall and support ethics.

Featured in Culture & Methods

This personal experience report shows that political in-house games and bad corporate culture are not only annoying and a waste of time, but also harm a lot of initiatives for improvement. Whenever we become aware of the blame game, we should address it! DevOps wants to deliver high quality. The willingness to make things better - products, processes, collaboration, and more - is vital.

Featured in DevOps

Service mesh architectures enable a control and observability loop. At the moment, service mesh implementations vary in regard to API and technology, and this shows no signs of slowing down. Building on top of volatile APIs can be hazardous. Here we suggest to use a simplified, workflow-friendly API to shield organization platform code from specific service-mesh implementation details.

Ehcache Joins Terracotta

Two of the most notable open source Java caching solutions have joined forces with Terracotta's purchase of Ehcache. Terracotta, unique for providing JVM-level "pojo clustering", can take multi-threaded single-JVM apps and have them run across multiple JVMs with no code changes. Ehcache is nearly ubquitous with hundreds of thousands of deployments; it provides the standard HashMap style interface similar to Oracle Coherence. The combined entity likely has the largest install footprint of all Java caching products. InfoQ spoke to Terractta CEO Amit Pandey and Ehcache founder Greg Luck.

For Ehcache users, joining Terracotta will bring:

The same Apache 2 license they currently rely on

A new hosting environment operated by Terracotta with state-of-the-art forums, source control, maven infrastructure, etc. all running alongside sourceforge infrastructure that will remain in place

A dedicated team of engineers working full-time on EHCache performance and features

A single-node version of Terracotta that can run on the desktop w/o their server array

Full freedom to run on the latest version of EHCache at all times, knowing it works with Terracotta

One vendor support structure for their caching interfaces / libraries as well as their scalability / reliability runtime.

Amit Pandey commented that:

first thing will ensure a seamless user experience, make sure that the integration between EHCAche and Terracotta gets tighter than today, such as offering a standalone download of EHCache with a distributed coherent backend from Terracotta. You can do that today since we’ve partnered but there is extra work that you have to do as a developer. We'll be able to to make the joint performance of the integration different than the standalone piece with all the bytecode stuff that we’re well known for.

For Terracotta the acquisition is "definitely a competitive blow to Coherence" according to Amit. Buying Ehcache gives Terracotta an easier path to adoption for the existing Ehcache install base which Terracotta claims "numbers in the hundreds of thousands, including the vast majority of the Global 1000." Buying Ehcache also gives more options for developers building distributed cache-based appliactions. While Terracotta was known for transparent POJO clustering, "the transparency is our greatest strength but some also criticize us that people have to go figure that out" said Amit. Greg Luck added:

Ehcache provies a very simple way of doing caching. I think Terracotta is simple but it requires a bit more thought. There are people who love TC for the pojo apporoach [but also] the mainstream that may not want to try something new. A lot of the sort of sizzle and attraction of TC appeals to the more cutting edge and people very pojo in their thinking but there isa whole class of folks in the J2EE world who are quite happy with a very simple api model.

Asked about the combined entitty's advantages over Coherence:

Footprint. If you’ve built your app on ehcache, and you have a simple drop in upgrade for distribution now.

Multiple approaches to caching. Traditional Terracotta pojo caching as well as the api-based approach.

Open source. Greg Luck said that "Coherence is not open source. For a developer to decide to use coherence the decision needs to be made at a higher level (cto), while Ehcache and Terracotta development can start from the grass roots. So for people that want massive scale with coherence, they can start with ehcache on one node then move distributed with terracotta easily."

Greg Luck commented that he sees consolidation as important to keep competitive, even though he had rejected 3 offers from other companies in the previous years:

As you saw with SpringSource last week, there is definitely consolidation going on, partly triggered by Oracle’s acquisition of Sun. Caching and distributed caching is particular important, and there is a risk that open source projects could get shut out. There is a still an array of new competitors like Apache Dynamite, Memcached - from my point of view it’s get big or get out.

On the topic of memcached, Greg Luck talked about the integration with Terrracotta eventually improving Ehcache server, a Java competitor to memcachd that offers a RESTful api allowing it to deploy behind load balancers for easier scale across clusters: "today, each node has a 100% copy of all that data. That means to you’re limited to whatever your GC can handle. Our customers have run up to 20gig. What happens if you want to run a terabyte sized cache? Up to this point, you couldn’t do that with ehcache.. With Terracotta we’ll figure out what the product roadmap looks like."

Ehcache will remain an Apache 2 licensed project available as today via sourceforge, Maven, etc. The acquisition means that Greg Luck is joining Terracotta, and the copyrights on the EHcache codebase is now owned byTerracotta Inc., in the same manner that JBoss years ago purchased Hibernate. Greg Luck posted a personal note about the acquisition.

"definitely a competitive blow to Coherence" ?

Your message is awaiting moderation. Thank you for participating in the discussion.

Competitive blow?!? We've looked at EHCache some time go for similar reasons and decided to pass. To say that something like EHCache is anywhere near to competition with Coherence or GigaSpaces is simply misunderstanding the market and/or technology.

I understand the marketing spin and all - but, please, let all be a bit realistic.

Competition

Your message is awaiting moderation. Thank you for participating in the discussion.

Competition is good, and Terracotta has a different approach that may prove to help with some needs that had gone unaddressed by products such as our own (Oracle Coherence). Greg's got a good track record with ehcache and now he's getting paid to do what he loves. While the competitive hyperbole is silly, I nonetheless find it flattering that we (collectively) are building technology and businesses that have gone from niche to central in enterprise software (despite all the competition, our business continues to grow at "ludicrous speed"), and I find it even more flattering that companies want to compare to and compete with the product that I work on :-)

Re: Upon further look...

Your message is awaiting moderation. Thank you for participating in the discussion.

Nikita: thanks for your input.

Couple of misstatements you made that I want to point out:1. Transaction support is not present in either EHCache or DSO but is coming shortly2. EHCache has replication and invalidation options. Terracotta has affinity-based replication. Between the 2 we offer as many options as any use case I have seen requires.3. RMI-based, JGroups, JMS, all are available with EHCache. I will not comment on your opinion on RMI...it is yours to have.4. Asynchronous cache operations are indeed built in to EHCache. Different cache regions can in fact have synch or asynch replication and all is controlled via config. Very easy to use.

As for Exactly the same properties--as established above, this is not true. More importantly, it is not relevant as EHCache has _the de facto API_ in caching and we are getting behind it with dollars and people to make it even better plus keep Terracotta in lock-step with EHCache always. Terracotta has no issue with API's. If I stated otherwise, I guess I misspoke. What I always meant is that clustering and caching are 2 separate but related concerns. Clustering should not put any new and unique demands on an app if it can avoid it. In some cases, such as Gridgain or more generic master/worker clustering and interfaces are one-and-the-same and people come to a framework with clustering built in because that's the business requirement (divide and conquer). In the case of caching, developers want eviction, eventing, easy memory and cache size tuning. And they want a clustered version to "just work." This makes Terracotta and EHCache a "spaghetti and meatballs" kind of pairing...not overlapping or redundant with each other in any way.

BTW, its a shame you are so upset and stuff because grid-based computing and Terracotta go together quite the same way as caching and Terracotta and if you wanted to integrate, I am sure our community would support the effort.

Re: TC+EHCache without bootclasspath additions?

Your message is awaiting moderation. Thank you for participating in the discussion.

Peter,

great question. Round about answer here (bear with me).

1. Our Hibernate product that launches Friday works w/o the bootjar. But it does need a javaagent then. This is because of some technical reasons in the Hibernate use case but I wanted to get the message out that our bootjar and associated config for locks, etc. are not present in the Hibernate product

2. Distributed cache products built on the new Terracotta+EHCache do not need a bootjar or agent at all. Unless you want to share memory directly, the old-fashioned DSO way. Both options will be available when constructing a cache (we call these copy and identity caches internally right now). Copy caches don't need bootjars or agents. Identity ones do. You, the developer, will have the freedom.

Re: Competition

Your message is awaiting moderation. Thank you for participating in the discussion.

I agree with Cameron, competition is good and while we've (from an IBM WebSphere eXtreme Scale point of view) previously only seen Terracota on small setups (2 nodes or so), I'm sure the new capabilities (static striping etc) and that it fits into EHCache which has a lot of prewritten adapters in open source software will mean we see more of him :)

It's all good for growing the market and increasing customer awareness.

2 nodes or so?

Your message is awaiting moderation. Thank you for participating in the discussion.

Now, that's rough :)

On a serous note, my view (and I repeat that this is mine and somewhat biased view) Terracotta is a technology that has a very narrow applicability - but when it fits it fits like a glove. And I'm sure they scale to more than 2 nodes... :)

Re: TC+EHCache without bootclasspath additions?

Re: Competition

Your message is awaiting moderation. Thank you for participating in the discussion.

Billy - your sampling seems to be way off target.

I run Field Engineering at Terracotta and the consultants on the team are routinely working on 25+ Node deployments. Although, given Terracotta's Server Based architecture, the number of Nodes isn't much of a factor in terms of determining the "enormity" of any specific usage - it is more a function of the amount of clustered I/O against that data-set.

We actually strive to reduce the number of nodes so the customer saves on H/W and Management costs since Bloat-out is not the same thing as Scale-out. You Scale-out application nodes based on Application TPS that it needs to support and Terracotta-Server JVMs (Terracotta Striping) based on clustered-data-set-sizes and I/O against that.

Re: 2 nodes or so?

Your message is awaiting moderation. Thank you for participating in the discussion.

Yep - I'd be curious to know why Mr. Ivanov feels that way too.

In the several hundred deployments Terracotta Consultants have been involved with, we have seen everything from Http-SessionClustering to DistributedCaches in various flavours/topologies/frameworks, to Data/Compute Grids to highly availabile Queues.

Applications in production today involve distributed ConcurrentHashMaps, HashMaps, LinkedLists, ArrayLists, LinkedBlockingQueues and complex object graphs in all shapes/sizes/hues. In terms of frameworks where Terracotta does the smart-replication of the underlying state - EHCache, Quartz, Hibernate 2nd Level Cache, Spring WebFlow, Spring Security come to mind as the more popular ones. And in between all of this, more esoteric usages such as using a JVM based Sequence Generator (instead of relying on an Oracle Sequence) or clustering a CyclicBarrier so one can have a quorum of JVMs before they are pressed into rotation and the list goes on...