To appreciate what has changed, it’s important to understand how cloud services are built. The vast majority of cloud services have two major components: 1) a “control plane” which is comprised of the API, provisioning system, database, etc; and 2) a “data plane” which is the actual resources that get provisioned via the control plane – in this case, cloud servers. (If you have a networking background, control and data planes may sound familiar.)

These components have different availability characteristics. It’s quite possible for the control plane to be down while the data plane is up (e.g. you can’t add servers because the API is down but your hosted web site is still up) as well as the data plane be down and the control plane up (e.g. the host running your web server crashes but you can create a replacement cloud server via the API).

Historically we have only guaranteed the Cloud Servers data plane and the new SLA adds control plane guarantee as well. This is meaningful for a couple of reasons:

1. Apps are increasingly integrating with infrastructure APIs to make dynamic adjustments and thus take on a large dependency on API availability. A control plane guarantee means you can rely on the Cloud Servers API to be there when you need it.
2. OpenStack has proven itself and we are ready to guarantee it.  Since its launch in the fall of 2012, Cloud Servers has handled approximately 650 million API requests with an overall uptime of 99.95%. At this time, we are guaranteeing a 99.9% control plane availability but have every intention of pushing it higher over time. Note also that we don’t cheat. We count all server side HTTP 5xx errors as unavailability, maintenance is not excluded, and we measure availability monthly.
3. Having both control and data plane guarantees means you can build apps the way you want. If you want to build a more traditional static app that doesn’t need to work around data plane failure, you can do that. The data plane guarantee is there. If you want to build an elastic app that integrates with the API to autoscale, you can do that as well. The control plane guarantee is there.  No forced complexity. The choice is yours.

While SLAs are important, they are more than legalese to us. They are promises we make to our customers. It’s part of how we deliver Fanatical Support. We hate downtime and we work hard every day to keep our promises and provide you with a powerful and reliable platform so you can do what you do great. Thanks for being a customer, and we hope the new SLA gives you even more confidence in Cloud Servers and OpenStack.

The purpose of the incubator group is essentially to get the ball rolling – to frame the problem and lay a foundation upon which specific cloud standards can be developed via new or existing DMTF working groups (e.g. OVF) and other SDOs – a new TLA (three letter acronym) I learned this week – which stands for Standards Development Organization.  Specifically, this includes things like defining a cloud taxonomy, laying out use cases, and identifying specific areas ripe for standardization.  The work of open cloud is an arduous one and I appreciate the energy and commitment of the group.  Three full days of debating terms, concepts, technology, use cases, etc. can be exhausting!  Nevertheless, it is necessary and is the means to an end of specific cloud standards that will add real value for customers.

Rackspace has been involved in a number of early conversations and meetings over the past 18 months around cloud standards.  It has been frustrating because there has been little to no progress (albeit the efforts were always well intentioned).  It’s exciting now to see more formality around cloud standards development (from the DMTF and others) as well as a coalescing of various standardization efforts (e.g. http://cloud-standards.org).  We had a number of discussions about the work other groups are doing so there is both awareness and intentionality with regard to collaboration.

Rackspace has never believed in “lock-in.”  We want to earn your business through Fanatical Support. Even in our traditional hosting business, where the single tenant nature and ability to uniquely customize infrastructure necessitates a contract, we have the Fanatical Support Promise which lets you out if you feel we haven’t lived up to our promises.  If you believe you are best served by going elsewhere, you should have the freedom to move.  And the cloud should be no different.  While the cloud doesn’t require a contract, there are APIs, image formats, etc. that, in the absence of standards, will be proprietary and hinder portability.  That shouldn’t be the case and solid, well-received cloud standards are the key to avoiding cloud lock-in.

We can’t predict where cloud standards will go, but we are committed to participating in the process and helping create a world of open clouds.  Without them, we will never realize the full potential of the cloud.

Have a question? Send me an email.

Still, we had to create a proprietary interface which in some ways, makes the cloud world more divergent.  So, in order to share what we’ve designed and to foster a more open cloud, we announced yesterday at OSCON that our Cloud Servers AND Cloud Files API specifications are now open sourced under the Creative Commons 3.0 Attribution license.  This means anybody building private clouds, other public clouds, developing standards, etc. is free to take the specification design work we’ve done and copy it, modify it, or reuse it any way without fear of legal action.  We don’t know if that will happen, but we at least wanted to make it possible.

That deals with openness on the cloud service side – now let’s talk about the client side.  When Cloud Files was built, in addition to a RESTful interface, Rackspace also built Java, Python, Ruby, PHP, and C# language bindings.  One of our overarching design goals at the Rackspace Cloud is to make the cloud easy to use, and we believe a canonical set of bindings, consistent across languages, helps to achieve that.  In an effort to open these to the community, we have now made all Cloud Files bindings, open sourced under the MIT license, available on github at http://github.com/rackspace.  We invite people to pull down a copy and begin making contributions.  We’d love to see the community take ownership of them and eventually have external committers as well.  For more information on how to get involved, hop on the Cloud Files IRC channel at irc.freenode.net #cloudfiles.

With Cloud Servers, we are taking a different approach with language bindings.  We want to engage our developer community and enable them to build and own the bindings, but do it in a manner that still provides cross-language consistency.  To that end, we have created a Cloud Servers technical specification that serves as a blueprint for how to build bindings.  This is also available on github at http://github.com/rackspace/docs-specs-cloud-servers-language-binding/tree/master.  We will soon release a reference implementation in Python, which along with the tech spec, will provide good guidance on building in other languages.  We are just now getting this out and already, after one week of the RESTful API being available, we are aware of Twisted Python, Ruby, Java, and Perl bindings done or on the way.  Now that’s a great response from our developer community!  Thank you.  Our job is to work with you to help bring alignment to the tech spec and minimize competing/redundant bindings.  If you are developing Cloud Servers bindings or are interested in being involved, you can get more info on the Cloud Server IRC channel at irc.freenode.net #cloudservers.

We’re not sure where things will go, but we are committed to openness, being involved in standardization discussions, and taking a proactive role in our developer community to foster an open cloud.

Erik Carlin

Elastic computing. Autoscale. Pay as you go. It all sounds pretty exciting, and it is. But in the cloud, there are many “not so flashy” systems that are required to make it work, and often, those can get overlooked. One of those systems is DNS (domain name system), the telephone directory of the Internet.

DNS is necessary when building solutions in the cloud, but not all cloud providers offer a native DNS service. For forward resolution (e.g. www.yourdomain.com gets resolved to your cloud server IP or FQDN), that typically means using a 3^rd party DNS service – inconvenient and at expense to you, but doable. The bigger problem comes with reverse resolution (e.g. your cloud server IP gets resolved to a FQDN) because the cloud provider is authoritative for the reverse resolution zone (as they own the IP address space). If they don’t offer the ability to modify reverse DNS records, a number of problems can ensue (Wikipedia lists several common uses for reverse DNS here under “Uses”). For example, Amazon does not offer forward or reverse DNS capabilities and if you’ve ever tried to send mail from an EC2 instance, you know just how problematic the lack of good DNS controls can be.

Our goal at Rackspace is to offer you a complete suite of powerful yet simple and cost-effective cloud services. To that end, we are pleased to now offer self-service forward AND reverse DNS services, at no cost, in the Cloud Servers section of the Rackspace Cloud control panel (we’ve always had a tailored DNS interface for Cloud Sites). It’s integrated, easy to use, and just one of the perks you get with The Rackspace Cloud. At present, you can create A, CNAME, and MX records in forward DNS as well as edit reverse DNS records for any of your cloud server public IP addresses. We’ve heard you and we’re working on additional record type support (e.g. NS, TXT, SRV, AAAA) as well as APIs for programmatic access.

To leverage The Rackspace Cloud DNS services, be sure to set the following as the domain name servers with your domain registrar:

dns1.stabletransit.com

dns2.stabletransit.com

If you’ve got any questions about our DNS service or how to use it, don’t hesitate to give us a call at 1-877-934-0409 or hit us up on Live Chat – we’re here 24×7, and we love to talk about this stuff!

A persistent system is one that does not go away when failures occur.  That is, system information is generally recoverable once the system is restored.  Cloud servers are persistent.  Contrast that with an ephemeral or transient system which lives only as long as the system is running.  When failures occur in an ephemeral system, system information is lost.  EC2 instances are ephemeral.  You can think of this like non-volatile and volatile memory.  Non-volatile memory is persistent and doesn’t lose data if powered off.  Volatile memory is ephemeral and can only retain information when the power is on.  Cloud Servers is like the non-volatile SD memory in your digital camera while EC2 is like the volatile RAM in your laptop.

That’s a significant functional difference that has huge implications on how the system is used, how it’s supported, and how it’s designed.  Let’s take a look at each.

Usage
When you launch an EC2 instance, the virtual machine (VM) and included storage are ephemeral.  That means if your instance fails for any reason, you’ve lost your entire VM as well as all data in that VM.  If you use Elastic Block Store (EBS), that helps as it provides persistent storage, but the instance itself is still ephemeral.  That means although EBS data can survive an instance failure, the server, its configuration, log data for troubleshooting, completed work that has not been offloaded, etc. is all lost.  For transitory/batch workloads (e.g. video transcoding), ephemeral system failures generally aren’t too significant because even though data may have been lost, those workloads can just be restarted.  But, for persistent workloads (e.g. a web site) that you want to be available, you need to design and build your application on top of EC2 to expect and respond to underlying system failures.  You need to do things like monitor for instance failure, dynamically rebuild and reconfigure new instances on the fly, ensure data you don’t want to lose is always replicated or on EBS, be able to rollback and recover from lost work when an instance fails, etc.  While these are considered internet-scale design principle (PDF) best practices, they are more complex than traditional design principles and are not how the majority of web applications are built today.

By contrast, when you launch a cloud server, the virtual machine and storage are persistent.  That means if a cloud sever fails, the problem is fixed and your cloud server is brought back online.  Your cloud server and associated data don’t go away.  As such, you don’t have to think about your cloud server any differently than you do a traditional server in how you use it and build apps on top.  While Cloud Servers can support internet-scale applications, we don’t impose those design principles and associated complexity by making virtual machines ephemeral.  Of course, you are free to employ those principles if you’d like, but you don’t have to.  That means you have flexibility with Cloud Servers.  You can start using the standard design constructs you’re familiar with, and only after you become the next Twitter or Facebook (congrats!) do you need to embrace more complex principles.

Support
Ephemeral EC2 instances are easier to support because essentially, there is nothing to support.  When ephemeral instances fail, you are out of luck.  You, as a customer, should expect that kind of failure and the onus for dealing with and responding to failures is on you.  If you had important data on your instance that wasn’t offloaded somewhere, it’s gone.  Amazon has no obligation to get your instance back up or recover your data.

Persistent cloud servers are much more difficult to support.  That’s because when a host fails, the onus is on Rackspace to get your cloud server back up for you.    That’s more work for us, but we’d rather assume the burden so you can sleep better at night.  That’s what Fanatical Support is all about and is but one example of how it’s being translated to the cloud.
There are also significant ramifications on how the persistent vs. ephemeral natures of Cloud Servers and EC2 affect SLAs, but I’ll save that for a future post where we can focus on that specifically.

Design
Amazon purportedly built EC2 for internal use and later opted to expose it as an external service.  It is therefore designed to support systems on the scale of Amazon, eBay, Hotmail, etc., embracing large scale system design best practices.  One such tenet prescribes a commodity hardware approach where applications deal with underlying infrastructure failures rather than trying to make the infrastructure itself more resilient (I call this application-centric availability).  The ephemeral nature of EC2 is likely driven by this commodity approach as a commodity platform itself can make little guarantee of availability.  That is, although overall system availability can be guaranteed at a macro level, individual instances at a micro level cannot.  Practically, that means, for example, that hosts in EC2 do not have underlying RAID protection on local disks, and as a result, a host hard drive failure could take out one or more instances.

We designed Cloud Servers not just to support large scale apps, but also to support small scale ones as well.  Rackspace agrees with and has embraced large scale design principles for systems where the infrastructure is abstracted away and we provide a higher level service.  But, with Cloud Servers, the infrastructure IS the service and we didn’t feel like we could take a full commodity approach.  Instead, we followed a “mostly commodity” approach, being judicious about cost so we could provide a well-valued solution, but investing in infrastructure availability where it made sense.  To continue with the example above, RAID is one such area where we made that investment.  Hard drives are THE most likely component to fail and offering a quality, persistent compute service meant designing in hard drive redundancy (RAID10 specifically) to protect against that type of failure.

We believe persistence is the right approach (although note that ephemeral VMs could fairly easily be offered on a persistent system while the converse is not true – implementing persistence as an option in a system designed to be ephemeral is non-trivial).  It’s the way most people in the world think about servers and we don’t think deriving the benefits of the cloud should mean having to embrace more complex design principles that may not apply.  Persistence is harder to achieve but well worth it for the customer.  It offers simplicity and peace of mind for some but can also be a viable platform for those wanting to build more complex, dynamic applications.  It’s the best of both worlds.

Erik Carlin
Chief Architect, Rackspace Cloud

Here’s our take on things:

· From our perspective, the authors were good intentioned and were not explicitly trying to exclude anyone. They were acting as a catalyst in the development of an initial set of open cloud principles in an effort to move interoperability forward. That is to be commended. But for whatever reason, the roll out and execution were rushed. Things moved forward very quickly (too quickly), certain companies did not have enough time to review, comment, etc., and as a result, the development of the manifesto was not as collaborative and “open” as it should have been.

· The principles of the manifesto itself are what’s important and are what Rackspace supports and is committed to. We have consistently been involved in cloud standards discussions and have maintained a “no lock-in” position.

· The manifesto, as it states, “is meant to begin the conversation, not define it.” No decisions have been made. Nothing has been defined. The manifesto is simply meant to begin a meaningful conversation towards standards.

· To that end (although in an unanticipated fashion), the manifesto has already drawn significant attention to the issue of cloud standardization. That is positive and we hope it will ultimately result in productive conversation with tangible results.

· We believe no one should be excluded, or should exclude themselves, from the conversation and that any interested company, organization, or person should be able to participate, and should participate. We look forward to key organizations that have not joined engaging to help shape and define broad reaching and open cloud standards.

The Open Cloud Manifesto is just the beginning. Real action and collaboration are the keys going forward if we are to achieve anything meaningful. Like a good wine, good Texas steak, or any other standardization effort, cloud standardization will have to take its course. Rackspace is fully committed to providing customers choice, flexibility, interoperability, and portability as we believe it will drive wider cloud adoption, and that will benefit everyone. A rising tide will float all… clouds.

If you have any questions, comments, or concerns, please feel free to e-mail me at erik dot carlin at rackspace.com.

Erik Carlin

Chief Architect

The Rackspace Cloud

Cost

Both Amazon and Rackspace/Mosso offer cloud storage calculators, but they are a bit simplified and a head to head comparison is non-trivial.  To make that simpler, we put together an Excel-based calculator that quantifies the total cost of the two solutions including things like request fees, origin fetch bandwidth, etc.  Below we show the results of several common cloud storage scenarios but the calculator is available here (served up via Cloud Files and Limelight) so you can run your own cost comparison.

Before we dive into the numbers, I’d like to comment on one significant differentiator between Cloud Files and S3 – and that is support.  We think our storage service is more than just a commodity like electricity.  Cloud Files houses YOUR data, YOUR applications, and in some cases, YOUR business.  Rackspace has been hosting customers for ten years now, and we know how valuable support (the fanatical kind, is there any other?) is when considering handing over stewardship of your data.  We take that very, very seriously here and believe you shouldn’t have to pay to talk to a human to find out what’s going on with your data.  That’s why support is INCLUDED with Cloud Files.  We are here 24/7 to answer any of your questions or help you out.

Now don’t get us wrong, price is incredibly important too!  That’s why we’ve worked hard to design and offer a cloud storage solution that is exceedingly affordable.  We also leverage the scale of Rackspace as much as possible to reduce our prices and pass them on to you.

In the below scenarios, I list S3/CloudFront pricing both with and without Gold level support.  In most cases, the Cloud Files/Limelight pricing is the same or better than S3/CloudFront pricing even without support (ranging from -3.7% to 17.4% savings), but in ALL cases, the Cloud Files/Limelight pricing is cheaper with support (ranging from 15.8% to 52.9% savings).  In short, with Rackspace/Mosso, you get more for roughly the same or less money!

Cost Data

Scenario 1 – Backup/Archive with medium-sized files

5TB of cloud storage.  Inbound bandwidth of 1TB.  100GB of outbound bandwidth.  Average file size is 150KB.

___________

Scenario 2 – Backup/Archive with small-sized files

5TB of cloud storage.  Inbound bandwidth of 1TB.  100GB of outbound bandwidth.  Average file size is 75KB.

___________

Scenario 3 -  Lots of data, no CDN

100TB of cloud storage.  Inbound bandwidth of 500GB.  5TB of outbound bandwidth.  Average file size is 150KB.

___________

Scenario 4 – Reasonable amount of small files, CDN-enabled

750GB of cloud storage.  Inbound bandwidth of 50GB.  0GB of pure storage related outbound bandwidth (excluding origin fetch).  CDN bandwidth is 500GB in the US, 300GB in Europe, 200GB in Hong Kong, and 100GB in Japan.  Average file size is 75KB.  80% CDN cache hit.

___________

Scenario 5 – Lots of medium files, heavy read, CDN-enabled

50TB of cloud storage.  Inbound bandwidth of 500GB.  0GB of pure storage related outbound bandwidth (excluding origin fetch).  CDN bandwidth is 10TB in the US, 8TB in Europe, 5TB in Hong Kong, and 3TB in Japan.  Average file size is 150KB.  80% CDN cache hit.

* All Amazon prices have been confirmed via their online calculator (there was a $0.70 discrepancy on Scenario 5 which appears to be related to rounding of AWS published prices or a problem with the AWS calculator for Japan related CloudFront costs) but if you find a bug, please let us know so we can fix it.

CDN Performance

Amazon opted to build their own content delivery network (CDN) while Rackspace chose to partner with Limelight Networks, a leading, global CDN provider.  Limelight serves some of the largest media customers in the world (including Disney, MSNBC, NetFlix, Microsoft Xbox, and Amazon Video on Demand) and has an extensive world-wide network.  Before we take a look at the performance data, let’s examine the network characteristics of each solution.  After all, CDN performance will be driven by these factors.   You can find the Amazon CloudFront edge location and limit information here, but I’ll summarize below in the following comparison table:

At the time of this writing, Limelight has more than four times the number of edge locations compared to CloudFront which means your data served through Limelight will have a higher percentage chance of being closer to those who access it.  In addition, for heavy access to content, CloudFront limits the performance by capping the max transfer speed and number of requests per second.  By contrast, Limelight’s scale is so huge that there are no individual limits.  Max transfer speed and requests per second are only limited by the overall, aggregate egress capacity of Limelight’s network which, at the time of this writing, is 2.2Tbps.  In short, Limelight will get your data closer to your users and will be able to serve popular content faster.  Now, let’s see if the quantitative data confirms this.

CDN Performance Data

To compare CDN performance, we placed identical 8KB files in both Cloud Files and S3 and CDN enabled the content to Limelight and CloudFront, respectively.  We then used Gomez to measure end to end response times (including DNS resolution, etc.) to the content via the CDN URLs, every five minutes, over the course of one week, from various nodes throughout the world.  The results are as follows, broken down by region:

USA

The average response time is 232ms for CloudFront vs. 57ms for Cloud Files which means in the US, Cloud Files is 4.1 times or 307% faster than CloudFront.

Europe

The average response time is 261ms for CloudFront vs. 62ms for Cloud Files which means in Europe, Cloud Files is 4.2 times or 321% faster than CloudFront.

Asia

The average response time is 602ms for CloudFront vs. 323ms for Cloud Files which means in Asia, Cloud Files is 1.9 times or 86% faster than CloudFront.

Global

The average response time is 333ms for CloudFront vs. 107ms for Cloud Files which means globally, Cloud Files is 3.1 times or 211% faster than CloudFront.

In addition to the substantial performance benefits of Limelight over CloudFront in all regions of the world, also note the consistency of content delivery.  Limelight’s massive scale and global presence not only ensure faster delivery, but also more predictable delivery.

Conclusion

Cloud Files enabled with Limelight marries cutting edge storage technology, the lowest price, and the fastest, most consistent content delivery, all backed by Fanatical Support.  Clearly there are more variables than cost and performance, but we wanted to help get you the data you need to make an informed decision.  If there are any flaws in our methodology or calculations, we welcome feedback so we can correct them.  We feel strongly about Cloud Files and how it can benefit you.  Thankfully, others agree.  We are honored to have been voted the Best Cloud Storage Solution at the 1st International Cloud Computing Conference & Expo 2008 West!
You’ve seen the data.  We hope you give Cloud Files a try and experience it for yourself.  If we can be of any assistance serving you or answering any questions, please don’t hesitate to contact us.