I rip on Rackspace specifically because I genuinely care for the brand. If I didn’t care, I would leave and find another vendor. I can think of few companies better-poised to take on the challenge of cloud computing better than Rackspace.

In fact, maybe this is where the disconnect is for consumers right now. Not just with Rackspace, but with all vendors claiming to operate their business on cloud architecture. We call it many things, but the common term is “cloud computing”. Are the public’s assumptions in flawless uptime incorrect in that it’s a “distributed processing” model instead.

Cloud technology has already proven itself as a good model for handling larger scale processing for people that need it. Companies like Slicehost (now owned by Rackspace) and Rackspace’s new Cloud Servers platform based on Slicehost’s backend are perfect for this need and you can scale up as needed within minutes. This was only a dream a couple of years ago.

That said, is the public incorrect in equating services like Cloud Sites to Rackspace’s multi-rack load balancing solutions? Such a solution still has a point of failure, although small. The chances of an outage under such a system with two high end servers, each in separate racks with a load balancer in place are incredibly low, in fact, near non-existent. We haven’t seen stability like that on any level with Mosso, Amazon S3 or Media Temple the best of my recollection.

I have serious doubts about the “cloud” computing concept recently and that it’s a failed concept.  We have yet to see a successful execution of the cloud hosting idea to the point where there is a stable solution in place with such a level of redundancy that applications and websites are not down for any reason.  I’ve experienced outages with Mosso lately that I’ve become discontent with.  The reasoning behind choosing a company like Media Temple, Mosso or Amazon EC2 services is so that you are not experiencing downtime…ever.  

I’m stuck in a difficult place, because I realize the outage discovery phase’s necessity in determining a cause of failure, however, it’s been hours and nobody’s found anything…that sorta causes you to wonder if the idea of cloud computing really works (or at least if it’s been implemented correctly at the datacenter layer).  I know that things don’t just break on their own typically, and so I’m curious if someone rolled out an update that went bad, a switch dead (hey, hardware fails – I get it).  My next question would be: “why did they roll it out before testing in a beta environment?”.

I have optimistically waited for stability in the Mosso cloud hosting service that we’re unfortunately realizing is not there.  Maybe someday down the line it will be, but we’re faced with a scenario where I spoke up for Mosso to sell it to us internally since I have long-favored the Rackspace brand.  I figured that with Rackspace’s financial and infrastructure backing, that it might come with the same types of safety nets we’ve become used to with Rackspace in terms of high availability application hosting.

I’m not normally one to pull the plug inadvertently, but this has become somewhat habitual (8 incidents within the past 7-day week).  Those aren’t exactly excellent percentages.  I think instead of the SliceHost purchase and rolling out of the CloudFS service, Rackspace should be focusing on the stability of the current idea/concept of cloud hosting to make it rock solid before presuming to add more services to a foundation that hasn’t proven itself as 100% stable.

I have a lot of love for the Rackspace family and have been working with their teams both directly and indirectly for 7+ years.  I don’t intend to bow out completely, but I’m not sure it’s logical for us to continue to place trust in Mosso with the types of outages this past 3-6 months.

Maybe I have an incorrect view of what cloud hosting actually is supposed to be.  I imagine that if one piece of the equation is unavailable, that the others failover pieces are are able to serve content, justifying that the services are never really offline to the end user requesting the content.  In my opinion, no services can come offline using this method.  The idea that there is an infrastructure so robust in place behind the scenes is one that will execute this properly.

What do you think?