The “also ran” Clareti VTL (or as I called it, “the only VTL going after the enterprise not doing dedupe”) from Gresham software was quietly sold to Tributary Systems, Inc (a storage VAR) in October. I’ve never heard of them prior to today. Maybe I’m a cynic, but I doubt this move will change that much.
When I think about the Gresham Clareti VTL, I think back to a briefing meeting I had with them at SNW a few years ago. It was a guy from marketing, and a techy-type (who I later found was the core architecture of the product). They were doing what I would describe as HSM for tape; that is, they were using disk as a high-speed cache to large tape libraries. They would stack smaller virtual tapes onto larger physical tapes allowing you to seamlessly migrate physical tape types in the background while keeping everything the same on the front end. The problem was that I hated this idea. I think tape stacking is evil and unnecessary in the open systems world. (It was necessary in the mainframe world where you couldn’t append to tapes, resulting in lots of unused tape. So replacing that with virtual tape on the front and stacking all those data sets onto physical tapes gave huge value. In the open systems world we know how to append to tape and this really isn’t an issue.) I also didn’t think that tape conversion was that big of a deal. There are ways to migrate from LTO-2 to LTO-4 without making all your tapes completely invisible to the backup app (which is what happens when you virtualize and start stacking them). Oh, and they had no plans to do dedupe because they saw disk as just a cache to tape.
So when they asked me what I knew of their product, I said that from what I understood, the whole world was going one way (dedupe and less tape) and they were going the other (more tape and no dedupe. It was blunt, but very truthful. The result? The techy guy said “well, I guess there’s no point in us talking to you!” and stormed out of the room! The marketing guy convinced him to come back, but you could cut the tension with a knife for the rest of the meeting. I called his baby ugly and he did NOT like it. Hey, dude. I calls em as I sees em. I may be wrong, but you’ll get what I think one way or another.
So fast forward two years and the product was acquired for $1.4M dollars. Wow. That’s even less than the cheapest one I know about when NetApp acquired their VTL from Alacritus for something like $12M. What’s even weirder is that they get half now and half later. There’s no performance stuff attached to the deal, but they don’t get all their money now. They got $300K in October, another $300K new year’s eve, then $600K in June ’10, and $200K more new year’s eve 2010. Call me crazy, but that sounds like a loan to me. So Tributary wanted a VTL but they couldn’t scrape together even $1M for it? Or was it that Gresham was just so desperate that Tributary struck a deal that limited their cash outlay even though they had the money. Who knows, but either way it’s almost a non-deal that was about .05% of the Data Domain deal.
They functionality offered by the VTL reminds me of another failed VTL company – Neartek. They were also an HSM-for-tape VTL that also knew how to talk to mainframes and open systems. They also weren’t doing dedupe, and they got sold for an undisclosed amount to EMC and basically disappeared.
How do you sell a VTL in today’s world without dedupe? Their shiny sheet talks about doing remote site backups with their VTL. How do you do that without dedupe? Seriously! They talk about this VTL having more functionality than any other product out there. Really? Have you looked at any of the other products?
Update: Some sent me private messages suggesting that I am saying this VTL has no value. I’m not saying that. I am saying that it’s far from being the best and it’s missing the single biggest feature that people are currently talking about (dedupe), so I don’t see how the CEO could say what he said.
it reminds me of the time I was in the Javits center at Unix Expo many years ago. A sales guy from a disk company was showing me hot-swappable disk drives and at that time they were pretty slick and new. He showed how easy it was to put them in and take them out and said, “it’s so easy a blind man could do it.” (He was blind.) We were impressed and asked him if they were the only ones doing it. He said yes. Then we walked around the show floor and saw nothing short of 6-7 vendors doing exactly the same thing. We laughed and said, “In all fairness, he is blind. Maybe he didn’t see the other vendors.”
Now before I get emails about making fun of a blind guy, I actually really respect this guy — and I make fun of everybody. Let me tell the rest of the story. The blind sales guy was (and is) named Michael Hingson. He and his guide dog, Roselle, survived the 9/11 attack of the WTC! Roselle lead Michael down from the 78th floor after the first plane hit! Who needs eyes when you have a dog like that? Michael now does keynote speeches and is now the national sales director for the National Federation of the Blind. Read more about him on his website. If you’re still mad at me, go ahead and click the Contact Curtis button and tell me what you think.
Maybe the Tributary CEO that said that this was the most advanced VTL is “blind.” He wouldn’t be the first “blind” CEO I’ve met. Go ahead, guys. Prove me wrong. I love it when I’m wrong about this sort of thing. But I think you just blew $1.4M dollars. You probably would have gotten a better ROI buying a house in San Francisco.
(Now I’m betting that core architect guy will never talk to me again.)
Written by W. Curtis Preston (@wcpreston), four-time O'Reilly author, and host of The Backup Wrap-up podcast. I am now the Technology Evangelist at Sullivan Strickler, which helps companies manage their legacy data
Thanks for the reminder about Mike Hingson. I used to work with him at Quantum. He was working at Quantum when 9/11 happened. And it’s true, Roselle (whom I met a few times as well. Great dog) led him out. God bless both of them….we need to hear more stories like that.
*Discalimer* I know nothing about either of these companies and have never heard of them either until reading this post.
Many times there is more than meets the eye to M&A activity. For example, did Gresham have some hot sauce engineers that Tributary wanted so that was the main driver for the deal. Or was there some product that Tributary is working on that there was some code for that Gresham had and it was either cheaper and/or quicker to just buy it rather than develop it themselves. Not saying either of these is the case, but I’d like to think one of these is the case and not the fact Tributary just blew a cool 1+ million 😉
Usually when something like what you describe happens, the acquisition comes and goes with NO fanfare — even less than this one. For example, when NearTek was acquired by EMC most felt this was just to get their people and a little experience in dedupe — they made no product announcement. In this case, they’re yelling to the winds that they bought it to get the product — and it’s the best product in the world.
Curtis,
Sounds like you talked to the wrong people (not unusual for Gresham).
Stacking wasn’t the primary focus of Gresham’s product. From day one, the core of the technology was fundamentally a zero active management, physical tape cache/library sharing appliance. The recommended configuration was a mode called real backed volumes. The virtual volumes were 1:1 with the physical tapes in the library (ask some other vendors what percentage of physical tape they fill in this mode). In this mode, the on tape format matches the backup application, while still providing a completely virtualized view of the physical resources with significant configuration flexibility (*1). It was a product designed to enhance physical tape, rather than replace it.
Plug the vtl in, between a physical tape library and a set of backup applications, and it could either significantly shorten backup windows, or it could reduce the amount of back-end tape hardware required. Think of it as an impedance matching product, matching the performance of the backup servers to the performance of the tape library.
While it had a number of industry firsts (never publicized), it remains the _ONLY_ VTL with a worst case performance curve roughly equal to the physical back-end that’s attached (*2). It continues to have, what may be the fastest single stream ingest and restore rate, with competitive aggregate performance. Fundamentally, the idea was to use the disk, to cache data that was likely to be accessed. This means that it could provide extremely high backup _AND_ restore performance, often with very little actual disk. CPU caches are the perfect analogy.
Since all the data in the cache was write-back flushed to physical, taking data off-site, tape re-importation and other tape behaviors were not impacted. All this was possible without extensive VTL retention policy configurations, or often even interacting with the product. For example, almost from day one, it was possible to configure the system so that virtual tape exports done by a backup application would result in automatic physical exports of the matching 1:1 volume.
So, as you know, physical tape continues to have a strengths compared to VTLs. Areas like power usage, $/TB, regulatory compliance, data off-siteing, or other application specifics reasons mean that tape is still a valid choice for many environments. Gresham’s product was designed to leverage the advantages of disk into these environments, or to broaden them by lowering the total cost of tape.
For example, today there are environments where even assuming a 50:1 dedupe ratio the cost of buying sufficient bandwidth for remote replication out-weights the cost of simply buying tapes and sending them to an offsite location. Plus, it turned out that Gresham’s product coexists, and even adds advantages to many dedupe environments whether they were backup applications with dedupe capability, or back-end dedupe VTLs with slow ingest/restore rates.
(*2) For cache hits, the mount time is effectively 0, the seek time is basically disk seek time, and reads are a few hundred MB/sec per stream. If the cache is missed (tapes can be partially in cache, depending on usage pattern) the worse case is roughly the physical library mount time, physical drive seek time, and physical drive read rate. The tape blocks can be directly read back from physical and returned to the backup application without intermediate storage to disk. This completely avoids extended prefetching delays common on may of the competing products. Writes (appends), even to tapes that don’t 100% exist on disk run at the disk ingestion rate.
(*1) It could drive any combination of physical libraries, while exporting any number of virtuals, even going so far as being able to “consolidate” multiple physicals into a single virtual. The tape polices were equally flexible, allowing any combination of compressed/encrypted/pure virtual/stacked/real backed/native format/bypass/etc to exist in a single virtual library.
If talking to the core architect of the project is "talking to the wrong people," then I don’t know who the right people would be.
As to "primary focus," I almost am not sure what to say. It had tape stacking as a feature, and it was pushed by every — and I mean EVER Gresham person I ever talked to.
But, whatever. Bygones.
Tape stacking or not, the focus of the product is to act as a cache for tape. Disk caching is SO five years ago. We’ve figured out that — if you have dedupe — you can buy roughly the same amount of disk as you would for tape caching (OK, maybe a little bit more), and throw away the tape altogether! So why would anyone want tape caching?
No, not all the dedupe systems out there perform as well as your system, but some of them do, and not everybody needs that performance either.
Curtis,
“We’ve figured out that — if you have dedupe — you can buy roughly the same amount of disk as you would for tape caching (OK, maybe a little bit more), and throw away the tape altogether! So why would anyone want tape caching?”
The easiest way is simply to have an environment that doesn’t get a good dedupe ratio. It really doesn’t take much to drive the ratios far below 10:1. Often times a significant portion of the remaining ratio ends up being the standard LZxx/Huffman/etc pass. Administrators running some form of incremental/differential backup are fairly common, as are systems that simply don’t have any significant redundancy. When the numbers get run, and the dedupe system has a marginal advantage in capacity, the cached tape solution starts to look really good on a $/TB basis. Especially with LTO4 tapes at $30, and dedupe capacity often being just fractionally cheaper than stock RAID storage.
I do advise people to investigate their dedupe ratio before buying, and to make sure that it’s worth the premium they’re paying, so I actually agree there. Generally, though, most people I find that are getting a sub-10:1 dedupe ratio are doing something BAD to make that happen:
1. Compressing data BEFORE the system, rather than at the system
2. Encrypting some data before the dedupe system sees it
3. Having a VERY short retention time (e.g. less than a month)
There are exceptions to that, but it’s what I usually see. Of course, there are data types that don’t dedupe very well at all (medical imaging, heck, any kind of imaging), which is why I like having a dedupe system where I can turn off dedupe for certain backups.
But I’ll agree with the fact that not everyone fits into dedupe land nicely. Having said that, you’re then competing in a market with a few well established players that have very good speed and a much bigger footprint — and they offer dedupe as an option and you don’t. It’s got to be a tough sale. That’s all I’m saying.