Opinion by Steve Duplessie

Lessons learned from a cloud evaporation

Cloud provider Nirvanix went belly up. Even if you weren't one of its clients, you can learn things from that mess.

Cloud capacity provider Nirvanix croaked recently, giving clients two weeks to get their data out of there. I estimate that most clients would require two months or more to accomplish this. Some need two years. There is physics involved, unfortunately. The "Beam My Data Up" feature turns out to be fictitious. Go figure.

If you never contracted with Nirvanix, it's easy for you to think, "Well, serves them right for using a little startup. I would never do that!" Think again. IBM and HP resold Nirvanix. They put a lot of customers on that cloud.

Fortunately for many Nirvanix customers, it may not be catastrophic if they can't get their data out. The cloud provider mostly handled fixed file content, and 99% of the data was non-transactional -- and not the only copy. It was mostly cold storage. Nonetheless, some customers are screwed. And all will suffer in one way or another.

If anyone had to fail, though, it's best that it was Nirvanix. That's small consolation to Nirvanix' customers, I realize, but it definitely could have been worse. It could have been Amazon. (That's not crazy talk. I mean, it's not like Amazon makes money. A money-losing business model is ultimately not sustainable, fyi. I read that in Harvard Business Review, I think.)

In a rush to save (perceived or real) money, while eliminating the nasty management burden of dealing with bulk storage themselves, IT organizations and lines of businesses have flocked to the cloud to store their stuff. Amazon's S3 is booming. Box and Dropbox have a zillion petabytes of stuff on the floor. (That's my own rough estimate.) We all know in the back of our minds that there is some risk, but the heck with it. What's the worst that could happen?

Lesson 1: Define your actual requirements

Don't guess. Don't think that the cloud is just a "tier" like any other -- a cheap, slower tier. It is and it isn't. It is cheap (done right), and it is slower, but putting stuff into cheap and slower is much different from getting stuff out of cheap and slower. Cloud storage is the IT version of the "roach motel."

If you never actually need to access the data you put into the cloud directly or if you can tolerate long latencies when you need stuff back (i.e., days, weeks, months), then go for it. If not, don't.

Design for the worst access case. Anticipate the most expensive use case. Don't be surprised.

Lesson 2: Where is your volume manager?

Remember when you used to use your disk volume manager to mirror two disks in case one crapped out? Are you doing that to your cloud tier? I bet you are not. Never ever ever put your stuff in only one place. Ever. Never. Use the cloud all day long, but keep a copy locally, or on another cloud (not on the same network provider or network!). Capacity is cheap. Have your cake and eat it too -- use the cloud, but not only the cloud (or at least only one cloud).

Lesson 3: The cloud isn't as cheap as you thought

It's stunningly cheap to put stuff into the cloud. But if you use a cloud vendor, it becomes enormously expensive very quickly. And by the time you figure that out, you realize how hard it is to get stuff out. That's what cloud vendors bet on.

It's amazingly easy to use S3 or AWS -- and they are absolutely brilliant services -- but if you don't watch what you are doing, you'll end up paying through the nose. The key is to leverage cloud IaaS as transient services, because then it really is cheap. You rent what you need while you need it, then you stop paying for it. It's when you decide that the cloud is going to replace your PMO (present mode of operation) that it get's expensive and risky.

People put stuff on Nirvanix to replace their existing archive methodologies. No problem if it's not the only place the data lives -- and if you don't need it back in a hurry. Big problem if it is the only place the data lives. Big, expensive, ugly problem.

Lesson 4: It's not the cloud's fault, it's yours

We tend to be lemmings in the IT world. Lines of business have been running around us and setting up their own services on Amazon, etc., without even telling us. Because we in IT are too slow and too expensive. So we rush in. We try to embrace ITaaS concepts in order to keep our relevance (and hence, our jobs). And we take shortcuts too. Then, when something nasty hits the fan, it ends up blowing all over us, regardless of whose brilliant idea it was in the first place.

The cloud is not nirvana, any more than Nirvanix was. It's just another thing. A thing we have to understand inside and out: what it can do, and what it can't; what it's good for, and what it isn't. We need to stop treating this year's model (yes, this is an Elvis Costello reference) like it's the only way to go. Don't jump in with both feet. Stick your toe in the water first. Make sure you understand where the alligators are before you go swimming.

The cloud is a consumption model more than a set of technologies. Understanding why and when you would like to utilize this consumption model is a good idea -- to which I suggest you ask one simple question of yourself: What problem am I trying to solve?

If you can be honest with yourself and divest yourself from the hype of the gold rush, the more you ask yourself "what" and "why" questions, the better off you'll be. Once you are clear on what you are trying to accomplish and why you need to accomplish it, you can then model out the risk/reward of all of your options -- including the cloud.

Don't let one failure spoil your appetite. The cloud is here to stay. The first airplanes crashed and burned, and the first automobiles were slower than horses. We don't fly in balloons these days when we take a trip, and we don't ride a horse to work anymore. Eventually, we figure this stuff out.

Steve Duplessie is the founder of Enterprise Strategy Group, where he is a senior analyst. You can contact him at steved@esg-global.com, and read his blog at thebiggertruth.com.

The march toward exascale computers
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies