Cisco Blogs

Cloud Computing and Package Mobilty

- February 20, 2009 - 0 Comments

So, I am a big picture kinda guy, for better or for worse, and, while there are a number of really smart folks working on the plumbing behind cloud computing, from a go-to-market perspective, I have been wondering about what needs to happen to cross that tipping point.To that end, lets compare workload mobility to something we all understand: package mobility. Say, you need to get a package from Philadelphia to Chicago. You could jump in your company plane and fly it from Philadelphia to Chicago. Now, odds are, unless you transport transplant organs (and you need a high degree of control and can charge a premium) or run an air freight company (and can run with very high utilization) this is not a very cost-effective model in the long run–sound familiar?So, you could get a bit smarter and engage other companies to complete the individual steps. You could hire a courier to take your package to the airport, book transport with a freight hauler, and then book another courier to pick it up from the airport and take it to its final destination. So, odds are, this is a lot less expensive, but it is a lot more work. You have to engage three companies, coordinate schedules and track paperwork. Moreover, you have to monitor each vendor and make the adjustments, so, if the plane will be delayed, you need to understand that happened and then call the courier in Chicago and make the adjustment. This is where I think virtualization currently runs the risk of stalling out–you can reduce capex up front (VM vs new server, VDC vs new switch) but get crushed by management complexity on the back-end. If shipping packages is part of your job, but not your whole job, you will hit a point where managing the packages you do ship will cap the amount of actual work you can do. To pull this back into the IT world, the amount of overhead you incur to manually reconfigure network, storage and security in support of, say, Vmotion will effectively cap how much you can take advantage of Vmotion or derivative technologies such as DRS.The final option is the FedEx model, where you ultimately buy a service from FedEx. You now decouple yourself from all the back-end nastiness. You now have a single point to manage to get your package to Chicago tomorrow morning by 10am–you don’t care whether they use jet planes or donkeys to get it there. Coordinating drivers, sorting packaged, tracking flights and herding donkeys becomes someone else’s task. Ease of use FTW!Now, I believe there are two key decisions that FedEx made that accelerated success and I think cloud providers would do well to take heed.The first choice is a simple to understand pricing model. For most folks, the decision comes down to two variables: how big the package is and when do I want it there. Its simple to understand and simple to use, so folks are willing to use service because it had a predictable cost. Apple figured this out for the iPhone: its web capabilities truly differentiated the iPhone, but folks were not going to use the web capabilities if they were worried about getting hit with a $500 data usage charge on their next cell phone bill, so they wisely pushed AT&T for a reasonably priced unlimited data plan. Sadly, other companies still have not figured out the value of this, which is why you never really know now much you are paying for a plane ticket until you get to the final checkout screen. Back in IT land, this predicability is key–if you have to multi-variable calculus to figure out the cost of shipping a workload into the cloud, you are going to be less likely to partake. I don’t think an all-you-can-eat plan makes sense right now, because I think they would be cost-prohibitive, but some pricing model that can be figured out with only a couple of levers is critical.The second choice was investing in the IT infrastructure to instill trust in the customer. With those wonderful tracking numbers, you can have complete transparency into the disposition of you package–when it was picked up, where it is in transit, when it was delivered and who signed for it. This, I think, is a bigger challenge for cloud providers on a couple of levels. The first is providing the same sort of management transparency (what’s happening with my workload? where is it running? am I hitting my service level SLA?), although I have seen some pretty cool looking web-based management apps out there. The second challenge is around security and policy compliance–being able to demonstrate, in an auditable manner, that a workload is being run within the constraints of a customer’s security and compliance policy. There is not a lot of forgiveness from customers on this front and I think cloud providers should tread cautiously.So, while this is hardly exhaustive, I think at least three of the critical factors to watch for are understandable pricing, simplified management, and a verifiable trust model.For additional reading, check out this post by my cohort, James Urquhart, on cost comparisons for using cloud infrastructure. SInce James is our “cloud guy”, you can read about more of his musing on his blog for the latest thinking. For more on the trust and security side of things, check out Christofer Hoff’s most excellent Rational Survivability blog. These would be two of the aforementioned smart folks.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.