OK, fair notice here, but much of what follows is only tangentially related to backup, at best. But there is a point, I think, to my rambling.
First, let me start by reacting to Tony Pearson's continued defence of TSM as a backup application that offers economies of scale. And before I really get going, let me emphasize again the definition of economies of scale: economies of scale offer a declining marginal cost per unit. It is what makes many industries go around: automotive (to the degree that it is actually going around these days!) and chip manufacturing to name just two. It is what makes Intel so successful: the 1,000,000 chip of a given architecture costs pennies (although the first chip might have cost them $2bn or so!).
I have a belief that is somebody can figure out how to achieve real economies of scale in backup and recovery, they are going to achieve two things: they are going to get rich, and they are going to get significant (dominant?) market share. Although I think that EMC has gone further than anybody else in achieving economies of scale with backup, I think there is still a great deal more that we can do. We as an industry, or we as EMC, however you wish to read that.
I also wanted to point out that this is different than just making things cheaper. Don't get me wrong, that is a good thing too. And perhaps if cheaper became almost free, that would be enough. But in the absence of almost free, just cheaper is not enough: a solution has to achieve economies of scale. Cheaper is necessary, but not sufficient.
So back to Tony.
Tony is fervently defending the notion that TSM offers economies of scale. Tony tries to say that my critique of TSM is FUD. Nonsense. I know an elephant when I see one.
Not to say that Tony's concern might not be valid. In my experience, it is extraordinarily difficult for somebody like me, an employee of a vendor, to have full, accurate, and relevant knowledge of a competitor's product. But not impossible.
At worst, we can end up in a situation where we are like the blind men describing an elephant by touch. One feels the trunk, and thinks that is the elephant. One feels the tail, and thinks that is the elephant. One feels the ears, and thinks that is the elephant. Each has a perspective, but it is not complete (and each, on their own, would be a pretty lousy description of an elephant).
So when one competitor describes or critiques another's product, I think you have to try extra hard to put the discussion in context (we are only talking about the ears, not the trunk, for example) or try extra hard to make sure you are right. When I criticized NetApp for failing to use RAID6 (or RAID-DP) on their dedup VTL, I did a large amount of research to validate that was, in fact, their approach. And I never claimed anything else about the product--I was talking about ears (only).
So when Tony claims that I am throwing FUD around, I really wish he was specific in that accusation. It is something I go to great lengths to avoid, and something which I didn't feel I was doing in my critique of TSM.
So is Tony's response (found here) correct? Not even remotely. It is, more or less accurate, in its details. And this has never been about the details of TSM functionality. It is about the big picture. So how does Tony miss the target?
He misses it by missing (very thoroughly) the big picture. From a backup point of view, scalability is not interesting if we are only talking about backup for 10 people or 100. Backup at scale is interesting when we start to worry about backup for 100,000 people or petabytes of data. When we worry about how we are going to do backup in the future, we need to worry about the private cloud. We need to worry about how to backup data that is an order of magnitude larger than it is today. These are the problems that need discussion. If you just need to back up the data for 100 people, you can find a solution today and you probably don't care about scalability or economies of scale.
So do you care about this? Are you running (or going to be running) a private cloud? Do you believe that thinking about the problems of tomorrow is something we should be doing today?
But back to backup and TSM. TSM fails to scale in any meaningful (cost effective) way.
In fact, one could build a metric that says for:
- every x TB of data, or
- every y number of clients, or
- every z number of files (objects) protected
You will need another TSM server. Lets say that for x = 50. For every 20 TB of (source) data to be protected, I am going to buy another TSM server. Based on experience, by the way, I think that is a pretty good assumption for the real value of x.
So if I have 42 TB of data, I will need 3 servers. If I add 5 TB of data, I still only need 3 servers. I might then falsely conclude that I have achieved economies of scale. After all, the next 5 TB of data has no marginal cost. The marginal cost of protection has fallen as my scale increased. But what if I am at 59 TB and add 2 TB? Then I need to add another server.
On average then, there are no efficiencies of scale. The cost of the 61 TB is the same as the 161 TB is the same as the cost of the 981 TB. They all require a new server. At a scale of more than 20 TB, on average, the cost of TSM is linear.
Tony tries to get away with looking at a trunk, not an elephant, and as a result, inaccurately describes the problem. The problem, especially for those of us concerned with data protection in a private cloud, is one of scale. And TSM doesn't scale.
Final point: there is actually a really important secondary point here--what is the TCO of your backup infrastructure. In some ways, TSM is one of the most expensive (number of servers and tape drives, for example), relative to other backup applications. However, I think it would be a really interesting exercise to critically examine the TCO of the various backup applications at different scales to evaluate if there is any genuine cost differentiation between them. (After all, in the industry, we talk exhaustively about the technical differentiation between the different backup applications, but we rarely if ever approach the question of whether there is a genuine cost differentiation between them.)
If anybody out there has any thought of whether or not there are significant cost differentiators between the different popular backup applications, I would love to hear them.