By now, I've had to explain COS (cloud optimized storage) and Atmos many, many times.
On this one, though, it's important to come up with a pretty clear and insightful explanation. When it comes to COS, you either really need it (and have very few alternatives!), or you wonder what the fuss is all about.
And I've come up with an explanation that's working pretty well -- let me know what you think?
Analogies Rule
If you find yourself continually explaining the same concepts over and over, you quickly go searching for a useful analogy that everyone understands and illustrates a few key concepts.
Now, analogies have their limits, and there always seems to be someone in the crowd who enjoys finding those (somewhat obvious) limits and pointing them out, but -- all in all -- I'm still a big fan.
So, let me share with you my analogy for what Atmos (and COS) really does.
Spare Parts Logistics
If you're in the IT hardware business, or, if you're responsible for deploying IT hardware on a global basis, you're familiar with this topic.
No surprise, IT hardware breaks, and it often needs to have a part replaced. From a support provider's point of view, it's important to have the right part in the right place at the right time.
Put too much inventory out in the field, and you'll run up incredible costs. And, if the parts themselves change or need to be updated, you've got another expensive headache.
Put too much inventory in a centralized location, and -- well -- you'll have people waiting far too long for a replacement part. Definitely not good.
Most IT vendors (and customers) have realized that the tradeoffs between the two are a complex and intricate dance. How important are the parts? How often do they fail? What's the delay time to get a part from A to B via truck or air? What's the cost of the part, and how likely is it to be upgraded or updated over time?
Long ago, much of this analysis was reduced to a handful of manageable yet comprehendable equations that created a model.
At the top level, there was a set of outcomes you'd want in terms of service level and cost -- call this "policy". You'd answer a bunch of questions about a specific part, and -- presto! -- a relatively optimized answer would pop out about what parts needed to be where. Perhaps call this "placement".
And Then It Gets Interesting
People quickly found out that this parts logistics model wasn't static -- it was constantly changing.
Maybe a given part started to break more (or less!) than orginally predicted. Or there was a sharp shift of demand to different products and configurations. Or perhaps the cost of part went up or down. Or all the parts need to be up-revved.
The logistics network can change as well. Maybe you need to open up a new spare parts depot somewhere. Or there's a new air service you can leverage. Or someone's offering a deal to store or move something more cheaply.
The best of these models had to be extended to reflect real-time changes in underlying assumptions, and spit out new answers on a day-to-day (or sometimes hour-to-hour) basis. Each time, there's a new list of instructions of which parts need to go where to keep the service policy in line.
Note: I learned about all this stuff by talking to the EMC people who do this for a living. As usual, I'm dramatically oversimplifying.
In an ideal world, though, you'd still have a policy that drove placement -- even if things change. For example, if a new part comes into the mix, you simply put it in a pre-existing category, and the policy engine does the rest.
From "Parts Logistics" to "Information Logistics"
Now, when you consider what COS (cloud optimized storage) attempts to do, maybe you can see why this is a useful analogy.
You've got an inventory of useful stuff -- in this case, it's information. You'd like to think in terms of a policy -- what kind of service, and at what cost?
To make that policy work, you'll need to dynamically position information in various locations around the globe. The more copies you push out into the cloud, the better the service level. Also, storage costs go up -- but network costs may go down, so the answer of "what's best" can vary.
If you have only one or two copies in a central location, maybe deduped and spun down, that's really cost effective, but someone trying to access it halfway around the world won't be pleased.
Things will change, often quickly. A certain set of information may get really, really popular. Or, what was once popular, is now no longer in such demand.
Storage prices go down. Network costs go down. New demand may appear from unexpected geographies. A new point of presence might go online. At any given time, the "best way" to exactly place information in the cloud changes.
Trying to optimize all of this using static tools would drive someone nuts, as it would in the spare parts world. You'd always get it wrong -- either too expensive, too slow or a mix of both at the same time.
The Magic Of Policy Engines
In one sense, Atmos (and other potential COS approaches) are nothing more than "information logistics engines". They're continually answering three questions:
Pretty simple concepts, when you frame it that way ...
COS Acceptance In The Market
When EMC introduced COS as a category, and Atmos as a product in that category, we were very clear to point out "this isn't for everyone".
Not everyone needs a global parts logistics network; and not everyone needs to a global information logistics network.
But for the people who do, this is turning out to be a very big deal. With all of our current projects, there's a surprising amount of information involved -- just for early phase adoption, let alone full-blown production. Anticipated network savings can easily run into the tens (or hundreds) of millions of dollars annually in some cases.
Not to mention the ability to serve up information that's from anywhere, to anywhere without the need for a big, honkin' centralized repository.
And keep all those hungry information consumers happy ...
The Network Guys Get It
I recently had an astute network architect at a customer point out the blindingly obvious to me: COS (and Atmos) networks look a lot like how the internet is designed: mesh architecture, no hub-and-spoke, dynamic optimization, re-route around congestion, multi-tenancy, secure, etc.
He also said that -- over time -- he thought this sort of approach to managing content clouds might become as pervasive as the internet itself.
I can't speak for the Atmos team, but -- yeah -- that would be kind of cool, wouldn't it?
:-)
Dear Chuck, I am totally agree with your comments on Information Logistics. With this IL look new concepts can and will be developed to reduce Information overload while providing information faster and better for the information customer.
Plse feel free to read more about Information Logistics in the article From Having to Using (ISSN 1872-3934)
Jan Willems
Information Logistics Experience Center
Nyenrode University
The Netherlands
Posted by: ing Jan Willems MBA | February 20, 2009 at 04:35 AM
Dear Chuck,I am totally agree with your analogy system of explaining to people things they not understand.I'm using it for years now working as a chief logistics,and it is really fastest way to get to the bottom line.
Radomir
www.bestlogistika.blogspot.com/
Posted by: Radomir Radomir | March 01, 2009 at 08:11 AM
I am totally agree with your comments on Information Logistics. Great analogies ! Simon
Posted by: Simon | December 01, 2009 at 04:58 AM