Sachin Rekhi

Why I Abandoned the Rackspace Cloud

As many of you know, I'm a huge proponent of on-demand computing as I believe it's the best starting point for most early stage web startups. Cloud computing allows a venture to substitute high initial capital expenditures for operating expenses that grow proportional to your traction. Equally important is its ability to flexibility scale and retract with the ebb and flow of your business. While it may make sense at a later stage to move to your own data center as you look to optimize costs, it rarely should be a priority in the tumultuous early days when you are still searching for product/market fit.

At my previous startup Anywhere.FM, we were an early adopter of Amazon Web Services in 2007. I've continued to be an early adopter of next generation cloud platforms as I'm always interested in understanding the bleeding edge innovations. Last year I initially saw a lot of promise in Google App Engine, but ultimately chose to abandon it due to its shortcomings. Just recently I tried the Rackspace Cloud, which is shaping up to be the fiercest competitor against AWS. I thought I'd share my experience with you.

What Attracted Me
Rackspace is not shy about looking to compete aggressively against AWS. They offer on their website a detailed head-to-head comparison with Amazon's EC2. While they suggest a variety of reasons why you might choose Rackspace over EC2, there was one specific advantage that caught my eye and ultimately led me to run a full-scale test on Rackspace. It was the fact that Rackspace offers cheaper low-end server instances that may be all you need for certain tasks. While Amazon's cheapest instance starts at $63.24/mo (1.7GB RAM) for continuous running, Rackspace's cheapest instance starts at $10.95/mo (256MB RAM). For certain tasks that are not CPU or memory-bound but instead network bound, the low-end Rackspace instances may be sufficient and cost effective. Given this fit the characteristics of my workload, I decided to shift some of my resources to Rackspace. I ultimately expanded to a farm of 8 low-end Rackspace instances for a full month.

Why I Abandoned
Given that I've been on Amazon Web Services for years now, my expectations for a cloud platform are high. And unfortunately the Rackspace Cloud ended up falling short for my needs.

One drawback that completely surprised me was the lack of reliability of the servers. This shocked me given Rackspace's long history of being the underpinnings of some of the internet's largest sites even before they launched their cloud offering. But I regularly would receive e-mails like the following:


I received 13 such required reboot notifications during the 33 days that I had instances live on Rackspace! Talk about a maintenance nightmare!

Rackspace also has some pretty restrictive limitations on backups and images created on instances. First, a backup of an instance is always tied to a particular instance. So say for example you setup and installed all the appropriate software like I did on one instance. Then you took a backup of that instance so that you could deploy additional servers based on the backup. Today you cannot delete the instance from which the backup was created because if you were to do so, you'll lose the backup! So as long as you want to create future instances based on that image, that instance has to live on. This is due to the strong coupling of servers and backups.

Related to this issue is the fact that you cannot share images with others. This means that any software you want on the box you have to install yourself instead of potentially taking advantage of someone else's work.

This is in contract to Amazon's strong Amazon Machine Image ecosystem. I personally use the great CentOS images from RightScale. This is just not possible on Rackspace.

While Rackspace does plan on addressing both of these issues, they have a ways to go to catch up with Amazon.

The amount of disk that you can have associated with a given Rackspace server instance is based on the server instance package. So if you require more disk space, you'll have to upgrade to a larger instance size and resize your server. While this does mirror most hosting providers, it falls short of the compelling offering of Elastic Block Storage that Amazon provides. Elastic Block Storage is completely resizable persistent storage that can be attached to any Amazon instance, with easy backup, redundancy, and re-attachment to\from different instances. It's great for storing the data files for a database server, for example, and allowing it to grow as necessary. I definitely missed this when I was on the Rackspace cloud.

Much of my workload involves making requests to third party APIs or scraping web pages. This results in significant network bandwidth both into the box and out of the box.

Currently Amazon is more price competitive on this front. AWS is currently offering completely free data transfer into EC2 instances for the first half of 2010. Compare that to Rackspace's $0.08/GB. In addition, EC2 charges $0.15/GB transferred out, versus Rackspace's higher $0.22/GB transferred out.

For these reasons I have ultimately decided to abandon the Rackspace Cloud. While none of them were deal breakers themselves, there wasn't enough compelling reason to move my infrastructure away from AWS.

What I'll Miss
Despite abandoning the Rackspace Cloud, there are definitely some aspects I will miss.

Rackspace doesn't lie when they say they have fanatical support. Because they really do. I signed up for Rakcspace at midnight on the weekend and I still received a friendly call from a Rackspace agent to confirm my identity and ask me if I had any questions about the service. And this wasn't an offshore calling center either. It was a very knowledgeable American representative.

Similarly, they have always available Live Chat that I have taken advantage of on multiple occasions. Why waste time digging through forums to try to find an answer to your question when you can ask extremely helpful and expert chat support staff immediately? Compare this to AWS, which charges significant additional fees for that level of support.

While the server backup system does have its limitation, it was refreshingly easy to setup. Just tell it in the control panel to backup daily and you are all set! Compare it to the details in this article for getting reliable backups on AWS.

Something so basic that was again very refreshing was the ability to provide easy to remember names for your server instances. AWS can be frustrating at times to look at the Control Panel and simply see instance IDs like i-462e3b1e, leaving you wondering what exactly is running on the instance.

While I have decided to abandon the Rackspace Cloud and stick with AWS, I'm sure I'll be re-evaluating Rackspace as it matures. Nonetheless I'm excited to see strong competition in the marketplace since it forces all cloud providers to continue to innovate. I expect to continue to see significant advancements in the space from all the major vendors as they evolve.

Related Posts

• Shortcomings of Google App Engine
• Google App Engine Task Queues, Push vs. Pull Paradigm, and Web Hooks
• Is Google App Engine Ready for Prime Time?

The Next Chapter in Online Content Discovery

Over the past two decades we have seen an evolution in the way we discover the content we consume online. I wanted to chronicle this evolution as well as offer a better way to take advantage of the next chapter in content consumption.

Mega Portals Dominate
Many of us only faintly remember a world before the world wide web and the Internet. A world dominated by online services Prodigy (1990) and AOL (1991). While today these services look like walled gardens, in their day they provided the first national access to online media when compared to the local BBSs that came before them. Both Prodigy and AOL built huge newsroom staffs as well as partnerships with existing offline content providers to bring news, reviews, weather, and sports online in mass for the first time. While these services eventually went on to provide internet access, these mega portals maintained a strong editorial voice over the content they made available to their users.

With the internet boom came the growth of the other large mega portals that are still hallmarks of many user's internet experience today, including Yahoo (1995) and MSN (1995). These services fully embraced the open web, yet still provided a strong editorial voice over the content they featured prominently across their sites, which continued to significantly direct online consumption.

As is often the case in technology adoption, the incumbents in offline content were late to the game. But eventually the big news brands, including NYTimes (1996) and CNN (1995), found their way online. With their popular web presences they continued to exercise the strong journalistic voice which has always been hallmarks of their brands.

Rise of Blogs, RSS, and Content Producers
Yet then something profound happened. We began to realize that the Internet as a medium had unique properties that we could leverage beyond simply redistributing offline content more broadly and cheaply. We started to realize that the web opened up the possibility of anyone becoming a content publisher. Thus came the beginnings of blogging. Blogger (1999) launched it's widely popular service along with many others to come.

With the rise of blogging came the need to efficiently aggregate and read your favorite content. The eventual popularization of RSS and their associated RSS readers, including Bloglines (2003) and Google Reader (2005), made this all possible. While many continued to rely on portals and major media outlets for their news, the best of us had moved to consuming a wide range of content produced from individual bloggers to the largest media organizations through our readers.

Social Voting and Democratic Content Curation
In the next pivot we found out that the web's value proved to be in not only allowing anyone to become a content publisher, but also to give the power of editorial voice to the masses. Anyone could recommend, curate, and discuss content online and through the laws of large numbers, the very best content could surface at the top.

Thus came the rise of social voting services to allow individual users to contribute to the curation of the best content online. Digg (2004) was the most successful to launch in the category followed by reddit (2005). In addition, Delicious (2003) launched a social bookmarking service which became equally beneficial as a content discovery tool.

The Age of Personalized Social Streams
But then the real social revolution hit us. Despite the many social networks that came before, it was Facebook (2004) that really initiated modern social networking with real identity, mapping the offline social graph, and most importantly, the news feed. While Facebook started as little more than a photo sharing site with a social graph layered on top, it continued to push the envelope and innovate with the news feed, enabling anyone to easily share what they were doing, what they were thinking, what they were reading, or even what they were eating with the rest of the world. Twitter (2006) took the very essence of the social stream and productized it in a simple micro-blogging service. These two services alone laid the groundwork for the rise of social streams, now published by many of the most popular services we use online today.

In terms of content discovery, this took the previous social voting evolution to the next logical frontier: our friends. Now we can easily share and discover what content our friends are writing, reading, watching, and engaging with. It has really empowered anyone to become a content curator with an eager audience of friends and followers. Readers can move past enjoying content discovery based simply on the popular vote to truly personalized recommendations from the people they trusted most.


Yet our understanding and use of social streams is still very much in it's infancy. During the blogging evolution, it wasn't until RSS readers were popularized that we learned to efficiently discover and consume the vast amount of content available on blogs across the web. We now need similar tools to increase our efficiency in discovering the best content from our social streams.

Yet what is unique about this pivot as compared to blogging is the problem is quite the opposite. With blogging the challenge was often finding relevant content to consume that was dispersed across the web, undiscoverable, and of varying quality. In this pivot, the content is right in front of us. It is abundant, real-time, and endless. We have already reached the point of saturation where there is too much content to possibly consume. This time around we need tools to filter, cut down volume, improve the signal-to-noise ratio, and find what is truly relevant in our social streams.

Feedera (2010) is one such attempt to build a tool to help sort through the clutter and allow us to efficiently consume the best content available through ubiquitous social streams.

The initial genesis for creating Feedera came from my own realization that I was now finding much more interesting content to consume on Twitter then I was in Google Reader. The power of Twitter as a content discovery tool lies in its ease of sharing content, ability to follow interesting people who tweet about relevant content, and it's real-time nature to surface content as soon as it's important. Yet Twitter in its raw form is ill-suited for content consumption. If you miss it in the stream, it's hard to consume later. The actual content is hidden behind non-descriptive short urls. The content is displayed as raw text with links when images or videos would be more appropriate. It's hard to discern what is hot or trending from a flat stream. It leaves a lot to be wanted as a content reader. With Feedera I set out to build the content reader that I wanted on top of Twitter.

Feedera takes the form of a personalized daily digest that delivers the best of your Twitter feed to your inbox every morning. It starts by segmenting the content into articles, photos, videos, and music and delivering the appropriate preview format for that content, including titles, description, thumbnails, and more. But more importantly, it applies a ranking algorithm to reduce the noise and surface the very best of your feed. The FeedScore algorithm combines overall popularity metrics for the content with friend relevance to find you content you're sure to enjoy.

I hope you will give Feedera a try as I would love to hear your thoughts.

Try Feedera Now!

5 Social Platform Predictions for 2010

As many of you know, I'm a big proponent of open platforms and have spent much of my career designing, building, or leveraging open platforms and APIs. While we have seen explosive growth in social platforms over the past several years, I believe they are still very early in their history.

I wanted to put out my 5 social platform predictions for 2010, as I think we are poised to see another exciting year of innovation.

Facebook & Twitter become the social and real-time protocols of the web.
There is no doubt that Facebook and Twitter have become the de facto social and real-time platforms of the web. I'm not going to argue which service will win because I strongly believe there is room for both as they serve important and separate functions. But I think both will see the next evolution of their dominance. We've already witnessed the transition of these services from valuable end-user apps to compelling platforms serving thousands of scenarios through a strong platform ecosystem. The next leg of this evolution will be transform to ubiquitous protocols that underlie all major social and real-time scenarios across the web. We will start to think of Twitter as a micro-messaging protocol just as we think of existing communication protocols like SMS and IM. Facebook will become the universal address book protocol for connecting and sharing with everyone in our lives. The unique aspect of this transition if successful is that each of these new protocols will be owned by one dominant player. This is a scary reality that we may soon be faced with.

Facebook taxes the value creation happening on top of its platform.
Facebook has seen incredible growth in 2009, reaching over 350 million users worldwide. In addition to strong user growth, they have seen equally exciting platform growth. App growth specifically in social gaming has been coupled with strong monetization for large and small app makers alike. The platform ecosystem's aggregate revenue is rumored to have exceeded Facebook's own revenue. While Facebook has fully embraced this in order to further its priority of platform growth over platform monetization, I think we'll start to see a shift towards Facebook looking to capture more of the value being created on top of its platform. Facebook already makes a significant portion of it's advertising dollars from app developers promoting their games. And Facebook has spent much of 2009 developing it's own virtual currency platform that would provide an easy and efficient way for Facebook to tax it's app developers. Look for this to launch in 2010.

LinkedIn's professional networking platform sees significant app innovation.
LinkedIn made it's first foray into apps in Oct 2008 when it launched it's on-site InApps platform. This platform allowed third party developers to build applications on LinkedIn. However, it was a completely closed platform that was never made generally available to developers and never grew past 13 available applications. Then a year later in Nov 2009 LinkedIn finally opened up it's platform for third parties to leverage it's data on apps on their own sites. The platform is still in the early days and has many limitations, but does pave the way for real innovation leveraging the valuable professional networking data repository LinkedIn has built. With this true opening I expect to finally see significant app innovation, despite it being plagued with delays until now. But better late than never, since LinkedIn stills holds an incredibly valuable data set with tons of untapped scenarios.

API monetization becomes an important question for emerging platforms.
API monetization remains at it's infancy. While there are APIs that are currently being monetized, what the customer is typically paying for is access to a restricted data set more than anything else. This rings true for Twitter and it's monetization of it's real-time data with Google and Microsoft, with the licensing deals LinkedIn struck with various partners which leverage it's professional resume data, or Compete with it's click-stream aggregate site analytics data. We are starting to see the freemium business model apply to APIs as well, with Compete, Urban Mapping, and Whitepages offering free and paid API offerings. In 2010 we'll start to see the discussion of API business models come to the forefront and I expect to see progress across the various models.

OAuth WRAP gains popularity over the original protocol.
The OAuth protocol has been a very important specification that has resulted in true standardization of API authentication across social, media, and other APIs. This has made the task of integrating third party APIs simpler for the developer, thus allowing a developer to interact with more APIs than ever before. Yet one thing that continues to be an extremely confusing aspect of the OAuth protocol is the signature authentication process. While it is standardized in the spec, we've seen a variety of slightly different implementations that have made it difficult for developers to get started with a new API. Just take a look at the LinkedIn API forum, where much of the discussion is around this authentication process. Twitter has kept around non-OAuth based authentication to make it easy for developers to get started without having to get bogged down with the OAuth details. Yet OAuth WRAP solves this very pain point by leveraging SSL for the authentication and removing the need for the developer to manually implement the authentication step. We'll see OAuth WRAP or a variant gain traction to further ease developer pain in this space.

Related Posts

• Monetize the Twitter API
• Does Facebook Connect Deliver on its Promise?
• Top Underhyped Open Platforms