Ben Cherian’s blog

I’m a big fan of RackSpace and their Mosso product. The Mosso team has done a great job by continually tweaking their products to add more functionality and value. They have made intelligent purchases (JungleDisk/SliceHost) and are using their considerable resources to make a lasting impact on the cloud computing landscape. I’ve had the pleasure of working with some of their smart, passionate employees (Rackers) and can personally vouch for their fanatical service. My company, ServiceCloud, has been a RackSpace partner for a couple of years and, when the fit makes sense, we proudly recommend RackSpace/Mosso to our clients.

That being said, I’m disappointed in Mosso for putting out a more-hype-than-substance announcement. Mosso recently announced that they’ve enabled one of their clients to be PCI-compliant on the Mosso cloud. When I saw this, I wondered how it was possible, but as I read closer it became clear that it was just a trick! It seems that their “PCI-compliant” solution requires Mosso not to store any information that requires PCI compliance. Instead they offload the burden of compliance to a third-party payment gateway (Authorize.Net). Chris Hoff and Craig Balding have written excellent articles explaining this trickery.

While what they say in the announcement is technically true, it’s misleading at best and does the fine team at Mosso/RackSpace a disservice. There is enough hype in cloud computing. We expect more from a market leader like Mosso. They clearly don’t need to stretch the truth in order to make news…they should just talk about their real accomplishments.

Update: The General Manager of Mosso, Emil Sayegh, pinged me on Twitter and mentioned that Greg Hrncir, Mosso’s Director of Operations, responded to the criticisms on Craig’s site. There also seems to be a healthy back-and-forth at Hoff’s site. It’s great to see that Mosso is interested in having a dialog about this issue and I’m looking forward to see how this unfolds.

This morning, Amazon publically released a new feature called Amazon Block Storage. Previously, there was no persistent storage available on EC2 instances. If you started an instance and then added files or changed the database, all the added files or database changes would be lost upon shutdown of the instance. There were kludgey ways to get around this problem, but nothing quite as nice as standard persistent storage.

With the announcement of Amazon Block Storage, EC2 instance have access to persistent storage which can be formatted in any format you desire. This was announced months ago, but released only to select users. Today is the first day Block Storage is available for everyone to work with. This is also the first time pricing for this service has been announced.

Amazon Elastic Block Store

Amazon EBS Volumes
$0.10 per GB-month of provisioned storage
$0.10 per 1 million I/O requests 

Amazon EBS Snapshots to Amazon S3 (priced the same as Amazon S3)
$0.15 per GB-month of data stored
$0.01 per 1,000 PUT requests (when saving a snapshot)
$0.01 per 10,000 GET requests (when loading a snapshot)(pricing info directly from the Amazon pricing page)

With public availability and ridiculously cheap pricing, Amazon has answered the biggest objection most people had with moving their application onto the Amazon cloud as well as made themselves much more competitive in the space. Go AWS team!

For more info, check out Werner Vogel’s post.

The “cloud” is a wonderful concept and a disruptive, enabling technology, but most people don’t really understand it yet. It can be a platform. It can be a development environment. It can be pay-per-use hosting. It can be confusing! It seems anything nowadays can be called cloud computing.

So, what’s a regular person have to do to learn about the cloud computing space? Conferences like CloudCamp and Structure really help spread the message. CloudCamp just had an appearance in London, so the event is going global! In addition to specialty conferences, there is a track at Interop NYC focused on Cloud Computing. In September, I have the opportunity to be part of a panel at Interop discussing Cloud SLAs. If you’re there, come and find me! I’d love to meet anyone who reads this blog.

Another resource is Alistair Croll’s GigaOm article where he divides the cloud space. If you want a more in-depth resource, Reuven Cohen, a smart Canadian bloke and one of the best cloud evangelists around, is working on a “definitive guide” to cloud computing. CloudCamp was Ruv’s brainchild and he’s been preaching the cloud gospel before anyone heard of it. Hopefully, we’ll see his book in stores soon.

There are also many Amazon Web Services user groups (AWSome) popping up all over the country, including my home base of Atlanta (a hat tip to John Willis).

If you really want to learn about the cloud, there’s a lot of resources out there. Just hold your noise, dive in, and try to swim past all the marketing hype!

In a earlier post, I explained my concerns about lock-in surrounding Google App Engine (GAE). I was told by the Google team responsible for GAE that many external developers have seen this issue and are developing products to solve the problem.

Today, I stumbled across two possible ways to port your GAE code without rewriting the entire app. The first of which is a proof-of-concept called AppDrop. AppDrop allows you to to move your app from GAE to Amazon’s EC2 without rewriting a single line of code. Of course, because the infrastructure model is significantly different, you won’t enjoy the unlimited scalability of GAE database, but it will allow you to do a temporary move while giving you time to figure out which database technology to move to.

The more exciting option is to use Massimo Di Pierro’s web2py framework. In version 1.30, Massimo added GAE support to the ORmapper in web2py. While full web2py functionality won’t be possible due to GAE’s restriction on writing to the filesystem, it still allows developers to move code between completely disparate environments and database technologies (mySQL, PostgreSQL, Oracle, SQLite3, and Google Query Language) with relative ease. All you have to do is add an import line to your python script! Check out this video for more info.

I’d like to see other python frameworks such as django, TurboGears, and Pylons make this functionality a part of their feature set. Since django and TurboGears have reasonably, deep Google connections, I would guess that there has been some internal discussion of this before.

These products only deal with the database layer and not every Google-specific call like mail or authenication. My hope is that there will be some traction on this front as well. In any case, it’s a great sign that many people are working to make code portability a reality for GAE apps…and that’s good for everybody.

Today was the last day for the Google I/O conference and I have seen some amazing products from the Google developer team. They have some very bright people working there. It must be a joy for them to know that their code has the ability to directly impact millions of people.

Checking out the latest advances in technology is like a vacation for me so this conference was a blast. The highlight of my vacation was learning more about the internal workings of Google App Engine. This technology has the potential of completing changing people’s expectations surrounding infrastructure. It’s allows a python programmer to instantly deploy a application without having to worry about infrastructure setup or whether the platform can scale. It has a logging api that publishes details to a straighforward management interface. On top of all that, it comes with authentication, mailing, image, and memcache API’s and a local development environment. In short, it’s a game changer!

While I love the concept and execution of App Engine, I am a bit worried about vendor lock-in. Let’s say you write a django app for App Engine that uses the GQL datastore, the mailing API’s and the authentication API’s, you won’t be able to pick up this app and drop it into a local environment or onto an Amazon’s EC2 instance. There will be many ”proprietary” API calls that need to be re-written to work in another environment. This means that there won’t be easy code portability out of App Engine. All your eggs will be stuck in a Google basket.

Today, Google had a fireside chat session with the App Engine team which allowed common folk to ask the team any questions about their product. I asked them whether or not they planned to release a GQL adapter for databases like mySQL or PostgreSQL which will allow GQL calls to stay the same across disparate environments. They responded that they aren’t building anything like that, but are enthused by reports that external developers are working on SimpleDB and CouchDB adapters. These databases are closer in philosophy to the GQL datastore than traditional relational databases like mySQL or PostgreSQL. The team also mentioned that they are interested in having standard API calls for all similar databases and that they would support such an initiative. Way to go Google! Hopefully, Google, Amazon and CouchDB will make this a reality. I’d like to see mySQL, PostgreSQL, Microsoft, and Oracle involved as well.

With GQL adapters in the works, I’m sure some enterprising developers will build App Engine connectors for the other proprietary API’s. Once this happens, lock-in is no longer a worry and all your eggs won’t be in the Google basket.