SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for April, 2011

People Using Amazon Cloud: Get Some Cheap Insurance At Least

Posted by Bob Warfield on April 23, 2011

I’m reading through Twitter streams, Amazon Forums, and other news sources trying to get a sense of how users are responding and what their problems are.  It’s pretty appalling out there.  B2B companies admitting they have no recent backups and just have to wait for it to come back online.  A company that claims patient’s lives are at stake as they do cardiac monitoring based in the Amazon Cloud and are desperately seeking assistance.  The list goes on.

There’s some basic insurance any company using the Amazon Cloud needs to take out first chance they get.  It’s not hard, it’s not expensive, it’s not push a button and get hot failover to multiple Clouds, and it won’t fix your problems if you’re caught in the current outage.  But it will at least give you a little more maneuvering room.  Many of the acounts I’m reading boil down to a lack of options other than waiting because they have no accessible backup data.  In other words, they’d love to bring up their sites again on another Amazon Region, but they can’t because they’re missing access to a reasonably current data backup, or the Amazon Machine Instances are all in the affected region or issues along those lines.

Companies need the Cloud equivalent of offsite backup.  At a minimum, you need to be sure you can get access to a backup of your infrastructure–all the AMI’s and Data needed to restart.  Storage is cheap.  Heck, if you’re totally paranoid, turn the tables and backup the Cloud to your own datacenter which consists of just the backup infrastructure.  At least that way you’ve always got the data.  Yes, there will be latency issues and that data will not be up to the minute.  But look at all that’s happened.  Suppose you could’ve spun up in another region having lost 2 hours of data.  Not good, not good at all.  But is it really worse than waiting over 24 hours or would you be feeling blessed about now if you could’ve done it 2 hours into the emergency?  These are the kind of trade offs to be thinking about for disaster recovery.  It’s chewing gum and bailing wire until you get an architecture that’s more resilient, but it sure beats not having any choices and waiting.

Another thing: make sure you test your backups.  Do they restore?  Can you go through the exercise of spinning up in another region to see that it works?  Don’t just test once and forget about it.  Pick an interval and retest.  Make it routine so you know it works.

Staging all the data to other locations is not that expensive compared to continuously running dual failover infrastructure.  That’s one of the beauties of elasticity.

There’s a lot of grumbling about how hard it is to failover to other regions and how expensive.  Nothing is harder than explaining to your customers why your site is down.  But at least get some cheap insurance in place so you have options the next time this happens.  And there will be a next time, no matter whether it is Amazon, some other Cloud provider, or your own datacenter.  There is always a next time.

While you’re at it, consider some other cheap insurance:

– Do you have a way to communicate with your customers when your site is down?  An ops blog that you’re sure is hosted in a different cloud is cheap and cheerful.

– Can you at least get your web site home page showing?  Think about how to get DNS access and a place to host that don’t rely 100% on one Cloud provider.

– Is there something about your app that would make partial access in an outage valuable?  For example, on a customer service app, being able to log trouble tickets as email during an outage or scheduled downtime would be extremely helpful.  Mail is cheap and easy to offer as alternate infrastructure, and it is also easy to imagine piping the email messages through a converter that would file them as tickets when the site came back up.  It’s not hard to imagine being able to queue many kinds of transaction this way in an emergency.  What are the key limited-functionality areas your users will want to have access to in an emergency?

– For some apps, it is easier to provide high availability for reading than for writing.  Can you arrange that in an emergency, reading is still possible, just not writing or creating new objects?  Customers are a lot more tractable if they know they still have access to their data, but just can’t create new data for a while.  For example, a bookmarking site that lets me access my bookmarks but not create new ones during an outage is much less threatening than one that just brings up its Fail Whale equivalent on me.

Welcome to the world of Disaster Recovery.  Disasters have a User Experience too.  Have you planned your customer’s Disaster UX yet?

Posted in amazon, cloud | 12 Comments »

What to Do When Your Cloud is Down

Posted by Bob Warfield on April 21, 2011

Heroku status is down

This post is on  behalf of the Enterprise CIO Forum and HP.  

As I write this, Amazon is having a major East Coast outage that has affected Heroku, Foursquare, Quora, Reddit and others.  Heroku’s status page is just the sound of a lost sheep bleating repeatedly for its mother in heavy fog.  What’s a poor sheep to do about this problem anyway?  After all, isn’t a Cloud-based service dead once it’s Cloud is dead?

Rather than wringing our hands and shaking our heads about “That Darned Cloud, I knew this would happen”, let’s talk about it a bit, because there are some things that can and should be done.  Enterprises wanting to adopt the Cloud will want to have thought through these issues and not just avoided them by avoiding the Cloud.  In the end, they’re issues every IT group faces with their own infrastructure and there are strategies that can be used to minimize the damage.

I remember a conversation with a customer when I was a young Vice President of R&D at Borland, then a half a billion dollar a year software company (I miss it).  This particular customer was waxing eloquent about our Quattro Pro spreadsheet, but they just had one problem they wanted us to solve: they wanted Quattro Pro not to lose any data if the user was editing and there was a power outage.

I was flabbergasted.  “It’s a darned computer, it dies when you shut off the power!” I sputtered in only slightly more professional terms.  Of course I was wrong and hadn’t really thought the problem through.  With suitable checkpoints and logging, this is actually a fairly straightforward problem to solve and most of the software I use today deals with it just fine, thank you very much.

So it is with the Cloud.  Your first reaction may be, “We’re a Cloud Service, of course we go down if our Cloud goes down!”  But, it isn’t that black and white.  I like John Dodge’s thought that the Cloud should be treated just like rubber, sugar, and steel.  When Goodyear first started buying rubber from others, when Ford bought steel, and when Hershey’s bought sugar, do you think they didn’t take steps to ensure their suppliers wouldn’t control them?  Or take Apple.  Reports are that Japan’s recent tragedies aren’t impacting them much at all and that they’re absolutely sticking with their Japanese suppliers.  This has to come down to Apple and their suppliers having had a plan in place that was robust enough to weather even a disaster of these proportions.

What can be done?

First, this particular Amazon outage is apparently a regional outage, limited to the Virginia datacenter.   A look at Amazon’s status as I write this shows the West Coast infrastructure is doing okay:

Amazon: one up one downMost SaaS companies have to get huge before they can afford multiple physical data centers if they own the data centers.  But if you’re using a Cloud that offers multiple physical locations, you have the ability to have the extra security of multiple physical data centers very cheaply.  The trick is, you have to make use of it, but it’s just software.   A service like Heroku could’ve decided to spread the applications it’s hosting evenly over the two regions or gone even further afield to offshore regions.

This is one of the dark sides of multitenancy, and an unnecessary one at that.  Architects should be designing not for one single super apartment for all tenants, but for a relatively few apartments, and the operational flexibility to make it easy via dashboard to automatically allocate their tenants to whatever apartments they like, and then change their minds and seamlessly migrate them to new accommodations as needed.  This is a powerful tool that ultimately will make it easier to scale the software too, assuming its usage is decomposable to minimize communication between the apartments.  Some apps (Twitter!) are not so easily decomposed.

This then, is a pretty basic question to ask of your infrastructure provider: “How easy do you make it for me to access multiple physical data centers with attendant failover and backups?”  In this case, Amazon offers the capability, but Heroku took it back away for those who added it in their stack.  I suspect they’ll address this issue pretty shortly, but it would’ve been a good question to explore earlier, no?  Meanwhile, what about the other vendors you may be using that build on top of Amazon.  Do they make it easy to spread things around and not get taken out if one Amazon region goes down?  If not, why not?

Here’s the answer you’d like to hear:

We take full advantage of Amazon’s multiple regions.  We’ll make it easy if one goes down for your app to be up and running on the other within an SLA of X.

Note that they may charge you extra for that service and it may therefore be optional, but at least you’ve made an informed choice.  Certainly all the necessary underpinnings are available from Amazon to support it.  Note that there are some operational niceties I won’t get into too deeply here, but I do want to mention in passing that it is also possible to offer a continuum of answers to the above question that have to do with the SLA.  For example, at my last startup, we were in the Cloud as a Customer Service app and decided we wanted to be able to bring back the service in another region if the one we were in totally failed within 20 minutes and with no more than 5 minutes of data loss.  That pretty much dictated how we needed to use S3 (which is slow, but automatically ships your data to multiple physical data centers), EBS, and EC2 to deliver those SLA’s.  Smart users and PaaS vendors will look into packaging several options because you should be backed up to S3 regardless, so what you’re basically arguing about and paying extra for is how “warm” the alternate site is and how much has to be spun up from scratch via S3.

Another observation about this outage:  it is largely focused on EBS latency, though there is also talk of difficulty connecting to some EC2 instances.  This is the second time in recent history we’ve heard of some major EBS issues.  We read that Reddit had gone down over EBS latency issues less than a month ago.  Clearly anyone using EBS needs to be thinking about failure as a likely possibility.  In fact, the ReadWriteWeb article I linked to implies Reddit had been seeing EBS problems for quite some time.  One wonders if Heroku has too.

What will you do if you’re using EBS and it fails?  Reddits says they’re rearchitecting to avoid EBS.  That’s certainly one approach, but there may be others.  Amazon provides considerable flexibility in the combination of local disk, EBS, and S3 to fashion alternatives.  The trick is in making your infrastructure sufficiently metadata driven, and having thought throught the scenarios and tried them, sufficiently well-tested, that you can adapt in real-time when problems develop.  In this respect, I have seem Netflix admonish that the only way to test is to keep taking down aspects of your production infrastructure and making sure the system adapts properly.  That’s likely another good question to ask your PaaS and Cloud vendors–“Do you take down production infrastructure to test your failover?”  Of course you’d like to see that and not just take their word for it too.

I haven’t even touched on the possibilities of utilizing multiple Cloud vendors to ensure further redundancy and failover options.  It would be fascinating to see a PaaS service like S3 that is redundant across multiple data centers and multiple cloud vendors.  That seems like a real winner for building the kind of services that will be resilient to these kinds of outages.  It’s early days yet for the Cloud, even though some days it seems like Amazon has won.  There’s plenty of opportunity for innovators to create new solutions that avoid the problems we see today.  Even the experts like Heroku aren’t utilizing the Cloud as well as they should be.

Now is your chance!

This post is on  behalf of the Enterprise CIO Forum and HP.

Related Articles

James Cohen has some good thoughts on how to work around Amazon outages.

I tweeted: “The beauty of Cloud: We can blame Amazon instead of our IT when we’re down. Except we really can’t: http://tinyurl.com/3hjhzr5”

Excellent discussion here about how Netflix has a ton of assets on AWS and was unaffected.  In their words, they run on 3 regions and architected so that losing 1 would leave them running.  As Netflix says, “It’s cheaper than the cost of being down.”  Amen.  I’m seeing some anonymous posts whining about the exact definition of zones versus regions, what’s a poor EU service to do, etc., etc..  Study Netflix.  They’re up.  These other services are down.  Oh, and forget the anonymous comments.  Give your name like a real person and don’t be a lightweight.

Lots of comments here and there also that multi-cloud redundancy is hard.  Aside from the fact that this particular incident today didn’t require multiple clouds, consider that it is fantastically easier to go multi-cloud than it is to build multiple physical data centers.  Salesforce.com was almost a billion dollar a year company before they built a second data center.  Speaking of which, I bet they want to chat with the folks at Heroku now that they own them.

Clay Loveless gets failover in the Cloud.  JustinB, not so much.  Too ready to take Amazon’s word about their features.  Makes me wonder if folks early to AWS who saw it buggy and got used to dealing with that are better able to deal with problems like today’s?  When you run a service, it’s your problem, even when your Cloud vendor fails.  Gotta figure it out.

Lydia Leong (Gartner) and I don’t always agree, but she’s spot on with her analysis of the Amazon “failure” and what customers should have been doing about it.

EngineYard apparently was set to offer multiple AWS regions in Beta, and accelerated it to mitigate AWS problems for their customers.  Read their Twitter log on it.  Would love to hear from some of their customers that tried it how well it worked.

Posted in amazon, apple, business, cloud, strategy | 10 Comments »

Apple’s Crazy Ecosystem and the Prospects for an Amazon Pad

Posted by Bob Warfield on April 18, 2011

I read with interest Marco Arment’s speculation about an iPad competitor potentially being in the relatively near-term offing by Amazon:

I’d bet on Amazon releasing a true tablet, competing more directly with the iPad than the Kindle currently does, in the possibly near future.

While I don’t doubt Amazon could launch a tablet and very well might, I didn’t find Marco’s logic particularly compelling.  In his view, Amazon needs to launch a tablet to deal with the vagaries of Apple’s iOS ecosystem which may soon be hostile to Kindle and very favorable to iBooks.  I note my new iPhone (had to replace one) was immediately pushing the “assumptive close” on me to take iBooks.  No interest Apple: I’ve got Kindle and love it.

I’m also not in the camp of Robin Sloan who has a Kindle and an iPad and claims to use the Kindle 100x more than the iPad.  I used my Kindle well past the point of paying for it based on savings from my book purchases (I read a LOT of books), got an iPad, and I don’t think I have fired up the Kindle or missed it since.  Other than visibility in direct sunlight, I much prefer the iPad in every way.  And visibility in direct sunlight has not been an issue.  I see so little of it, being decamped in front of this darned LCD screen, that my iPad activity is largely before bed at night and any exposure to direct sunlight I will spend enjoying the direct sunlight and not with my nose stuck in my ‘pad.  After catching myself neglecting family by playing with the iPad or iPhone when we were out, I decided that was a bad idea that needed to stop and basically quit bringing them along unless I was off somewhere by myself.  Trust me, it’s a better way to be social.

The logic I got from Marco’s post was that this is largely about Apple’s 30% share of any sales connected with an app like Kindle together with their requirements of same pricing on their platform and their competitive position vis-a-vis iBooks.  He muses about what Apple’s customers will think if Apple boots Kindle.  I confess, I wonder what it would mean to boot Kindle?  Can Apple retroactively zap a happy healthy Kindle reader off my iOS device when I already paid for it?  Can they simply prevent it from being updated and strike it from the App Store?  Remembering how people reacted to Amazon’s retroactively redacting books from people’s Kindles I can well imagine that customers will not be enchanted to put it mildly.  Watching the actual process of giving the boot to the Kindle app will be fascinating.

I think Marco sees the timing of this event as a golden opportunity to persuade people to switch to a Kindle-Pad.  After all, if your cherished app is being zapped at precisely the time Amazon offers an alternative, why not?

But this all neglects the possibility that Amazon has both strong designs on their own aPad and no alternative but to go to war.  I’m not sure either makes compelling sense.

Let’s start with the “no alternative” question.  I will grant that Apple’s terms probably make little sense for the Kindle app.  By the time we slice another 30% off the top for Apple’s treasury, there’s little left for Amazon to share with book publishers.  But have we forgotten that Amazon has a browser-based solution in the wings?  It’s in Beta test today and is called Kindle for the Web.  It shouldn’t be difficult for Amazon to finish that up and redirect any iOS Kindle users to their browsers to access Kindle for the Web.  It isn’t like the user experience on the Kindle apps is so hard to recreate that they even need to be apps.  HTML5 should be more than up to the task, and no Flash in the iOS browser is needed, thank you very much.   It’s not clear to me why a tablet is even remotely needed to save the Kindle business on iOS unless Kindle for the Web is somehow tragically flawed or late.  That shouldn’t be a problem, or if it is, it’s hard to understand why the same organization wouldn’t fumble the much more complex prospect of building a decent tablet and getting customers to switch there.

What about owning a tablet of their own?  While it isn’t entirely clear, it sure looks like Amazon builds hardware as a necessary evil, not as a goal.  Think of their motivation as being somewhat like Google.  They fear hardware creating walled gardens that prevent access to their money makers, but beyond that, they are agnostic.  In fact, they have Google and their Android empire to keep Apple honest.  So what’s the strategic motivation for them to get involved in a messy ecosystem war?  So far, they been more interested in slashing the prices on Kindles than driving them up market into the tablet world.  It could be they just aren’t ready yet, or it could be they’re very deliberate and haven’t moved for strong strategic reasons.

Look at it this way–if they launch a full on tablet, aren’t they going to war with all the other tablets out there?  Do they really want to be they can get big with their tablet faster than the others can shut them down and off the competing platforms?  That doesn’t seem like a great bet to me, though they have a lot better information on which to make a decision.  I’d summarize the strategic arguments for both sides as follows:

Pro: Amazon should build a killer Android tablet ASAP and jump in swinging for the fence.

–  It’s gutsy and would garner a ton of press.

–  It would let them get their other offerings front and center in their owner’s faces and potentially increase sales.

–  They are gatekeepers for some pretty significant functions that a great tablet needs.  Books and music to name two.  It could be this lets them create a profoundly better user experience that wins quickly, at least to the #2 place, and becomes the predominant Android tablet.

–  They can quit worrying about the crazy strategic niceties and just fight a good clean up front fight.  It’s very focused.

–  The days of specialized readers like Kindle are numbered.  If Amazon doesn’t produce a tablet, it will be out of the reader business in a year or two, just like smart phones killed the Flip video camera.

Con:  Amazon wins biggest by nurturing the best ecosystem and not focusing on a device.

–  Amazon should stick to their knitting and core business.  Maximize its success on all platforms instead of on their own platform.

–  Amazon can ill-afford to polarize everyone against them.  What with telcos wanting to control the billing of everything on their platforms and Apple tightly controlling its ecosystem, Amazon has to move nimbly among the feet of these dancing elephants.

–  Amazon is already flirting with the envelope with respect to the content providers–book publishers and the record labels.  The book publishers got off a solid shot across the bow that forced Amazon to back off discounting their books so much on Kindle.  The record labels are not thrilled with Amazon’s new locker service.  They need to mind their strategic P’s and Q’s very carefully lest those players choose to make an Amazon Tablet a nasty little skirmish to demonstrate they’re still in control.

–  Isn’t the open non-denominational way really the more modern way?  Shouldn’t Amazon stick to making its money in the Cloud, where the maximum leverage and margins exist?  Let the rest of the rabble duke it out in the streets over these client devices.  So long as there are good open platforms available, Amazon need only rattle the occasional saber by making sure everyone knows they could field a tablet in short order.  It’s really better to be perceived as capable of moving in that direction than to actually have to pay the price of doing so.

– Smartphones didn’t kill Flip.  Cisco had no business being in Consumer, they blew their numbers, and Flip was the sacrificial lamb.  Kindle is being priced down where no general purpose tablet can go, and even if specialized readers go by the way side, Amazon owns so much of the book market the tablets will have to deal with it even if only via Kindle for the Web.  eBooks have lock-in due to network effects (I don’t want to lose access to my library by switching from Kindle to iBooks), so Amazon’s early win ensures their continued dominance.

Conclusion

I tried to be even-handed with the arguments so you can decide for yourself.  Which way should Amazon go?

I think it’s too early for them to go tablet, so I’ll stay on record as being in the “Con” camp, strategy-wise.   But, I’ll be interested to see which way Amazon goes.  If Amazon does go the full tablet route, I will be interested to see what moves they make to ameliorate some of the “Con” issues.  I suspect they will have some clever solutions to those problems that could very well shift the strategic balance of my pros and cons list.

Related Articles

eBooks have passed print books in terms of popularity.  Amazon has to control the lion’s share of that.  One more reason Apple had better tread carefully.

Rumor says Amazon tablet a done deal and Samsung will build it.

Posted in amazon, strategy | Leave a Comment »

Twitter’s Biggest Problem: Tweets are Ads

Posted by Bob Warfield on April 14, 2011

Today seems to be bash on Twitter day:

–   Trouble at Twitter is a Fortune article talking about how Boardroom antics, CEO switches, and other distractions are keeping Twitter from progressing.

–  Twitter turned down a $10 Billion offer from Google, and the Business Insider claims that although they have 200 million registered users, only 20 million are active.  If Larry Page comes back again, they admonish Twitter to take the money and run.

There is a tiny dose of positivity (hey, sometimes you have to make up a word) in the form of people loving new Twitter mobile client Tweetbot, but it is tinged with almost totally offsetting negativity by fretting over whether Twitter’s Draconian “Write no Twitter clients policy” will let it survive.

Twitter has always been a love hate sort of service.  Some people can’t imagine what good it serves and some can’t imagine ever being without it.  I guess I’m somewhere in the middle, but I do think Twitter has one huge problem on its road to significant monetization:

Tweets are ads

There, I’ve laid the grenade on the table, sans pin.  Before we get started analyzing the premise of whether Tweets are ads, I’m sure we ought to spend a little discussion on why this is a problem.  The answer to that one is pretty simple–would you want to pay for advertising in the middle of a sea of free ads?  For the most part, don’t you capture most of the value by just firing off a salvo of your own free ads, er tweets?  The problem is diminishing returns and inventory.  To want to pay to run an ad among ads, you’ve got to want to be seen pretty badly and you need to run an ad that really sticks out.  Like the Dickbar, for example.  Unfortunately, there isn’t a lot of inventory available for big noticeable ads and Twitter’s users hate them.  Other than that, it’s a pretty good idea, but not one that will deliver $10B valuations.  Still, all sarcasm aside, you can see why they had to try something like that if you think Tweets are Ads.   How else to be seen in a see of other ads?

Go through the classified advertising sections in what few print periodicals are left.  There are very few ads there.  It’s not a happy place for ads, curiously enough, even though you have an audience spending time there because they presumably want to buy.  It’s not happy because of the inventory and cost problem.  Simply put, there is a hole in the middle of the continuum between cheap (just run a classified or type the darned Tweet) and getting seen (run a big ad that is much noisier than the classifieds or tweets).  That’s not to say you can’t run effective ads there, as I say, people reading classifieds presumably are looking to buy something.  But there is not enough inventory to sell there to make it all that lucrative and what inventory you do have must be pretty high-priced.  Contrast that with something like Facebook.  There you are running ads in the middle of a water cooler / friends chit-chatting conversation more so than amid other ads.  It’s still not really ideal, but it is much better, hence Facebook is making a lot more money relative to their participation.

Okay, if you assume Tweets are Ads, you can see Twitter’s problem pretty clearly.   But are Tweets really ads, for Heaven’s sake?

The short answer is, most but not all Tweets are ads.  You have to admit that every bot-generated Tweet is essentially an ad.  “Come read my new blog post!”  That’s an ad, let’s be real.  Or, perhaps to be more precise, it isn’t an ad to the industry because you didn’t pay for it.  It’s more like PR or a press release.  Nevertheless, functionally, it’s an ad.  It’s a message you put out there to drive traffic.  Heck, with only 140 characters, you can’t hope to do much more than drive traffic.  There aren’t enough characters there to actually inform anyone of anything momentous.  There’s certainly not enough there to convince.  Your only hope is to create enough shock value to get people to click a link and look further.  Isn’t that starting to sound an awful lot like what an ad does?

Are Retweets ads?  Well, depends on the Retweet.  It’s sure hard to argue that when you RT every darned Tweet that mentions you, your products, your company, or anything you ever Tweeted, Blogged, or said in a private inner dialog that you aren’t advertising.  I mean come on, we’re back to doing what those darned bots do.  Where’s the creative insight in that?  Twitter doesn’t even let you comment on the RT when you use their button, you’re just rebroadcasting someone else’s message to your flock because you happen to like or agree with it.

Try this experiment.  Stop what you’re doing right now (i.e. quit reading this blog post), go to your Twitter account, and scan the first screen.  Be really dispassionate.  How many of the Tweets there could be called ads in the sense I’m using it?

As I write this, my first page has 15 Tweets focused on just a few subjects:

– I got 5 repeats that are identical.  They say “Twitter’s Troubles” and link to one of the articles I gave above.

– I got 5 that are identical and say, “Tweetbot enters the IOS Twitter client fray” with a link to that article.

– I got 5 that talk about ‘Microsoft flexing IE9 muscle”

These are all bloggers and follower-seekers of one kind or another.  They’re all saying exactly the same thing.  They’re probably automated they are so darned similar, although I’m not personally familiar with the tools that do that.  Disclaimer:  I was shocked to see so little variety.  There are times when I do see long runs like that, but subjectively, I’d say it is more like 80% ads, 20% valuable insights than this sample would imply.  Nevertheless, since it is bash on Twitter day, I was happy to be able to make my point.

These are all ads.  Twitter’s problem is that when the vast majority of your content is advertising you give away for free to get participation, it’s going to be very very hard for you to sell additional ads on top of that for revenue.

Postscript

I was tempted to call this post “The Trouble with Twitters” but there probably aren’t enough Trekkies left in the world to have any idea about Tribbles and Twitter, so I contented myself with the photo.

Zoli Erdos points to a bit of Twitter Schadenfreud I missed.

Posted in Web 2.0 | 7 Comments »

Give Me a Layer to Stand On, And I’ll Move You to the Cloud

Posted by Bob Warfield on April 14, 2011

This post is on  behalf of the Enterprise CIO Forum and HP.  This is my first in a series of posts sponsored by Enterprise CIO Forum and HP, thanks for the sponsorship!

Apologies to Archimedes, who is supposed to have said:

“Give me a place to stand and I’ll move the Earth.”

He was speaking of leverage and the idea that a great weight can be moved with very little force given the right amount of leverage.  Leverage is what IT needs to make an orderly progression to the Cloud without having to expend too much force.

Where software is concerned, leverage often comes in the form of finding the right infrastructure layer from which to effect the desired transformation.  A good layer may come in the form of some standard that becomes the Rosetta stone whereby lots of different implementations are made equal and customers have more choices.  It may come from a particular abstraction that is powerful enough to sit on top of formerly quite different paradigms and make them all work alike. Leverage may come in the form of a new box of some kind that insulates one set of connections from the other, once again making the implementations on the other side of the box equal.

In order to move to the Cloud in an orderly and proficient manner, IT still needs the right layers to stand on.  Cloud providers like Amazon have done a little bit of this work, but there is a lot more still to be done.  You can see the difference in a service like Amazon’s, that looks very familiar to someone with at least a background in virtualization, versus a service like Google App Engine that forces you to more radically change how you think about infrastructure.  A good Cloud layer will minimize that disruptive thinking, perhaps at some cost of performance, in order to achieve greater agility.

Ideally, the right Layers meet IT halfway to the Cloud, forcing them to change much less than a direct jump into the Cloud, and facilitating the process of making different infrastructure variations look the same.  HP’s Hybrid Delivery is all about creating the right methodology and services to enable IT to think about their own data centers, private clouds, and public clouds as similarly as possible, as John Dodge points out over on the Enterprise CIO Forum.  Dodge views the right layers as facilitating agility, and that’s exactly what a good layer ought to do.

The next step beyond methodology and services will be technologies that act as layers.  IT will be able to refactor their infrastructure into components that are best left in the corporate data center, components that need a private cloud, and components that can thrive in public clouds.  The test of the best technologies will be how agile and transparent this refactoring can be, as well as the completeness of the new layer in terms of solving the key problems:

–  Security and Authentication across the different infrastructures.

–  Latency issues that will arise when some data and API’s are leaving the data center and picking up a much more expensive round trip cost due to the latency of the Cloud.

–  Management and Monitoring:  How do we make it easy to do these jobs in the same way no matter which infrastructure is involved?

There are many more dimensions such Cloud Refactoring Layers will need to address, but those serve as a reasonable framework to start a discussion.  As mentioned before, an appropriate Layer could take many different formats.  Imagine, for example, a Cloud Appliance.  Instead of installing a rack of blade servers, suppose you could insert a device in your rack that talked to servers in the Cloud and made managing and using them look very similar to having the physical blade servers right in your data center.  What an interesting device this would be.  Imagine a virtual Cloud “server” that acts as if it has 128 cores (or however many its appropriate to share per network connection in your rack based on the latency and bandwidth capacity of your Cloud access), terrabytes of data, compatibility with the management tools you know and love, a secure bulletproof connection to its Cloud backend that couldn’t “leak” into your network, and so on.  Yet the device would sit there in your rack taking very little space and power.  Consider it a Cloud “Force Multiplier” for your data center.

You wouldn’t have to entrust anything too sensitive to your Cloud Appliance.  Perhaps it simply allows you to offload some capacity from your Data Center to make room for more mission critical apps.  You could envision application dedicated versions of such an appliance aimed at apps like Mail Servers, Web Servers, or Sharepoint and other Social Apps.  Or, perhaps the appliance would be tasked with doing backups for PC’s and the non-critical servers.  Why mess with tape and other physical media when you can get multiple physical location redundant backups very easily from the Cloud?  Such an appliance would be exactly the kind of leveraged Layer I’m talking about.  It would make it easy for IT to start shifting apps to the Cloud without undue strain.

Such appliances already exist and are referred to as “Virtual Cluster Appliances.”  Expect a lot more to develop along these lines.

This post is on  behalf of the Enterprise CIO Forum and HP.

Posted in cloud | Leave a Comment »

Any Hardware Company Not Investing Big in Cloud is Nuts

Posted by Bob Warfield on April 7, 2011

If the Cloud is here to stay, and the trend to move apps into the Cloud is only going to get stronger, then any hardware or infrastructure company that doesn’t invest big in the Cloud is nuts.

The problem these vendors face is “Cloud as disintermediator”.  Companies that buy into the Cloud are letting the Cloud purveyor make the datacenter decisions.  And Clouds aggregate a lot of those decisions under one roof to gain their economies of scale.  It’s like waking up one morning as a hardware vendor and discovering your best customers had switched to another hardware vendor.  The difference, is you can see it coming and you have a chance to do something about it.

In fact, hardware and infrastructure vendors have quite a lot they can do about it:

– Make it a point not to lose Cloud deals.  When Cloud vendors come knocking, lock them up.  There can’t be as many Clouds as there are traditional vendors, and each one will have a lot of inertia to stay with their original infrastructure choices.  Make sure they choose you.

– Start your own Cloud.  This one may be pretty risky if it locks you out of being the basic nuts and bolts of other popular Clouds, but you have to at least consider it.  At the same time, Cloud vendors will need to decide how they feel about using say IBM hardware with IBM pushing their own Cloud.  It muddies the waters.

– Invest in building products that are uniquely suited to the Cloud.  There’ve been some fascinating glimpses of what large scale Cloud data centers need.  There is a ton of intellectual property opportunity in the world of the Cloud.  Now is the time to start staking your claims to it.  Get out your blank sheets of paper, sign up with some big Clouds to work on their needs, and you will wind up with some good ideas.  That’s only the start.  In the commodity world of the Cloud, execution will be everything.

– While we’re on the subject of execution, think what the razor thin margins demanded by the Cloud mean to your business model of today.  Think what they mean to the needs of the Cloud vendors.  Skate as fast as you can to where that puck is going to be.

I liken the Cloud a bit to what CNC machinery did to the manufacturing world.  We went from a situation where each and every machine required a skilled manual machinist to run it, to a world where computer-controlled machine tools can be run 4 or 5 to an operator and the operator can be far less skilled than a master machinist.  The same could be said for servers.  We’re moving from a world where every app had its own servers and lots of wasted capacity, to a world where we share that capacity internally via virtualization, and then finally to a world where we’re sharing capacity that is time sliced across many customers in huge data centers to wring every last drop of utilization.  Yes, there are drivers like Big Data that offset some of that, but it is hard to escape the possibility that in the long run, the world may not need as many servers as it once did.

(This article motivated by a Tweet by Jeff Kaplan about Dell investing $1B to expand its Cloud solutions.)

Related Articles

To get an idea just how different hardware purpose-built for the Cloud can be, check out Facebook’s servers.  They’ve just open-sourced the designs for their server hardware, which is quite a bit more energy-efficient that their leased data center hardware.  The difference in efficiency shows how much of an advantage can be had by specifically targeting the Cloud.  Facebook was smart to open source, if only because it makes it more likely the design will be commoditized and hence easier for them to buy even more cheaply.

Posted in cloud | 3 Comments »

 
%d bloggers like this: