Today, The Rackspace Cloud launched our new API for Cloud Servers. The API provides a flexible, programmatic way to Control Cloud Servers. Now, from within your own applications, you can write code that launches or reboots Cloud Server instances, creates custom metadata for your servers, injects files into the servers’ filesystems, creates high availability configurations using shared IP groups, and a variety of other tasks. You can learn more about Cloud Servers and the features of the API on our site.

Last Friday, I was able to sit down with the project’s lead architects, Erik Carlin and Jason Seats, to talk about designing the API, responding to community feedback, and industry standards around the cloud. Below are the answers they provided.

So a couple of the new features in the API allow you to customize your Cloud Server instances as you launch them. How do you envision those features being used?

Erik: Really, the idea is to provide layers of customization. First, you can create custom server images, and then you can further customize the instances you launch with metadata and file injection. Elasticity and the dynamic nature of cloud computing demand these kinds of real-time configuration options.

Jason: With metadata, you can provide arbitrary key/value pairs that are queryable through the API and associated with a running instance, providing a unique fingerprint for each one. With file injection you can put a file directly into the filesystem so that it’s accessible inside the instance. It could be a license file, it could be an SSH key—whatever you need.

What were the tough decisions in designing the API?

Erik: We wanted to adhere as strictly as possible to RESTful practice. We iterated several times on the design to make it more and more RESTful. We actually did an update this week where we made some final changes because we just didn’t feel like it was RESTful enough.

Jason: Another goal was conforming to open, accepted web standards that exist. For example, we worked to make our use of HTTP error codes precise and accurate. We are using headers the way they should be according to our interpretation of those standards. We really tried to not invent anything new but rather to build things on well-defined standards.

I think any developer or architect who’s tried to take a service and map it on to a RESTful interface would understand the pain of doing it. You can spend a lot of time debating how things should be modeled. Turning a real-world, sometimes messy thing into what’s really an idealistic, simple view is hard. It’s a long struggle, but when you come out the other end, it ends up looking very concise and clear and it’s easy to understand.

Erik: We spent a lot of time thinking through the API so that it’s very consistent—consistent with itself and with the Cloud Files API. Across the AWS services, Amazon doesn’t necessarily use the same web service interface types. So EC2 has no purely RESTful interface. They have a SOAP interface and what’s called a Query interface, which is REST-like, but not truly RESTful.

A while ago, a draft version of the API was released for public feedback. Can you give a few examples of the feedback that came back and how it drove the API’s development?

Erik: Feedback from the draft was really important. The metadata option and the server data injection feature were directly born of suggestions from the developer community. The feedback we received also drove the API’s support of XML and JSON—we got lots of requests for JSON. A few developers told us that our first take at JSON wasn’t as efficient or as elegant as it could be, so we went back and reworked that piece.

Jason: One thing we got real strong feedback on from the early viewers of the spec was visibility into the caching mechanism. There are web services out there that involve caching and it’s never entirely clear what the age of the cache is. We thought through those things and tried to use well defined ways to display how the caching layer works.

Request limits are something we actually expose through the API and your application or service can dynamically and programmatically ask about what its limitations are. We also have very clear ways of telling you when your application has exceeded its available requests and is being throttled or served cached results because of that.

There’s been a lot of debate in the cloud space concerning open standards and how they should be defined. What is it that makes developing standards across cloud providers so difficult?

Jason: As a company, we’ve certainly committed to supporting open standards but I think that we’re very realistic about recognizing the difficultly in establishing open standards. And it really is a reflection of different providers who have different underlying technology; different limitations. Those differences are reflected in these APIs. To have one overarching standard would mean the standard would be necessarily more complex than each of the implementations. A more generalized, more complex standard takes a long time to erupt naturally.

Erik: Rackspace is on the leadership board of the DMTF cloud incubator group and we’re working on a number of standards around cloud. We intend to open source the API specification as well so you can distribute, modify, or reuse the API freely. We tried to open it up as much as we can, recognizing that our specific design and the things we need to do are unique. If there was an existing API standard that we could have embraced I think we would have done it.

So this is the first public beta release of the Cloud Servers API. How will it evolve going forward?

Erik: Well first, we tried to think ahead: simple things like versioning the API so that we could introduce new features without breaking the API. You can query the API without the version and see all the versions that are available. You can query an API version and get a link directly to the API docs or WADL for a human readable or computer readable version of the specification.

Jason: In future versions of the API, we’re looking at tightening the link between Cloud Servers and Cloud Files.  Our expectation is that we’ll extend the API and the Cloud Server service so that we’ll have launch-able images on Cloud FIles. That’s probably the main thrust of the next rev that we’re looking at right now.

The best advice I have on changing the name of your company is to think hard before doing it. It’s a challenging project with implications everywhere, from your twitter name to your search rankings to every email account you’ve ever created. Anyone planning to change a company name needs an undeniable, unshakeable reason to do so. At Mosso, we had a reason just like that. For us, rebranding the company actually made sense. Why are we now The Rackspace Cloud? Really, we always were.

Mosso was originally started by former Rackspace employees who had new ideas about how hosting should be done. (The term cloud hadn’t been popularized yet, but we knew we wanted to explore automating and scaling massive infrastructure. Mosso, an italian term that means “with motion or animation,” hinted at that direction.)

In the industry at large, cloud providers have focused primarily on the technology: utility infrastructure and distributed computing are new concepts that reveal both the power and limits of modern hardware and software. There’s a lot to rethink.

We’ve worked hard over the last few years to innovate, but our best cloud idea ever, the idea that’s driven our growth as a business, was blatantly stolen from our parent company, Rackspace. The secret is so simple, so obvious, it may explain why it’s often overlooked: when you build a cloud offering, don’t pour your passion into solving technology problems—pour your passion into solving customer problems. That important distinction makes our hosting uniquely human in the automate-everything world of cloud computing. (“Infrastructure as a service,” Jonathan, a cofounder, says often and emphatically, “should come with service!”)

Our focus on customers drives our technology. Its why Cloud Servers are persistent, why we publish drafts of our APIs, and why our Cloud Sites platform supports familiar technologies like MySQL and WordPress. We want to help customers code for the cloud without having to rewrite everything for the cloud. It’s designed to be easier and entirely backed by Fanatical Support. The online control panel software, where you manage your cloud environment, even has live chat assistance built right in.

So this is who we are and who we’ve always been: Mosso, A Rackspace-backed and Rackpace-inspired company bringing a philosophy of service and customer driven development to the cloud.

That seems to shorten very nicely: The Rackspace Cloud.®

At the show, I’ll be hooking up with one of the local organizers of CloudCamp Austin, Michael Cote for his weekly podcast. I am looking forward to sitting down with him to talk all things cloud. If you are attending, feel free to drop me a line on twitter @toddmorey or come by and say hello.

Recently, we sat down with some of our customers and employees to put a little definition around the cloud: what the technology means to businesses and how it is changing hosting.

The video here is the result, debuting for the first time on our blog. It features Chris Henry from Behance and Andy Meadows from LiveOak360. Both are talented developers and Rackspace Cloud customers doing some very innovative things on the web.

I think the video does a good job of describing why the cloud is generating so much enthusiasm. As Andy puts it, cloud computing means companies can, for the first time ever, have access to “the infrastructure of a large business for the budget of a small business.”

Videographer Luke Korem shot the film and hosts his vlog on Cloud Sites.

• “Amazon.com isn’t the only service provider offering content delivery services from the cloud. By partnering with Limelight Networks Inc. (Nasdaq: LLNW), Rackspace Managed Hosting will offer CDN services through its cloud hosting division Mosso .”
  Soure: Contentinople
• “You can activate the CDN service on any file by accessing it via the Mosso admin control panel. It makes sense for large video and audio files along with large volume sites.”
  Source: Center Networks
• “Rackspace/Mosso’s Cloud Files now has a CDN hook similar to Amazon’s new CloudFront. Basically you store data in Cloud Files and enable the data for Limelight’s CDN. Then Limelight’s network pulls it from the closest Mosso server, caches the content within their geographically distributed network. The pricing model for Cloud Files is 15 cents per GB per month for storage and 22 cent per GB month for bandwidth.”
  Source: John Willis
• “I’m sure that there was a famous telco ad slogan that went something like ‘the price of calling keeps on falling’. This time it is the price of putting files in the cloud that is going down.”
  Source: Network Industry Review
• “Cloud hosting provider Mosso has announced that its scalable online storage service Cloud Files, announced last month, has been successfully integrated with Limelight Networks’ content delivery network, effectively giving Mosso a powerful CDN for rapid content delivery.”
  Source: The Web Host Industry Review

It is great to see our hard work to bring value to our customers resonating.

On behalf of all of Mosso, welcome to the team, Emil! For more details about the announcement, check out this article.

The podcast provides an interesting history around how Mosso got started, and Jonathan takes a swing at an easy-to-understand definition of “cloud.”

We don’t do events like this often, but we’ve got some great stuff in the works and are really excited to share the news with our friends and customers. You can watch the event live from your web browser (in High Definition, no less). For webcast log-in information please visit: www.rackspacecloudevent.com

Finally, if you will be in the Austin area, we’d love to have you attend in person. Please drop an email to attend@rackspacecloudevent.com and let us know you are coming.

Mosso provides the hosted computing power for YouDecide2008.com. Check out the recent story that was published about how Mosso is powering important online dialogue generated by the this year’s US presidential election.