How far can one take SimpleDB, OpenID and the Cloud?

Question

I have an ASP.NET MVC app (non-transactional, social) I am workong on. I started using the .NET authorisation provider which does the job, but with the Cloud's lining getting more shiny by the day I was wondering just how much I can push up.

Ultimately I want to do away with my ISP-hosted SQL Server database and to progressively start using S3 as my content increases.

I am considering using OpenID for authentication and SimpleDB for storing user details. Any content added by a user could be keyed on the ClaimedIdentifier, if I understand correctly.

What are the advantages/disadvantages of doing this? What are the showstoppers of this approach?

Does anyone have any examples of pure Cloud architectures that can be used to support arguments for/against?

Answer 1

I think the benefits of using OpenID are pretty well known. The advantages of using SimpleDB for storing user details include:

• The flexible schema allows you to directly support certain types of dynamic user data in ways that can be cumbersome with an RDBMS. For instance user defined profile fields, or arbitrarily long lists if values like email addresses. The data can be stored directly without needing yet another table to join against.
• You don't have setup and configuration options that need to be tweaked, so it's simple. You are basically outsourcing the server maintenance and database maintenance tasks. Which you are also doing, to a lesser degree, if you stay with a hosted SQLServer solution. And I don't know about shared SQLServer hosting, but I have had bad experiences with shared MySQL hosting in terms of consistency of performance and availability problems.
• Which is another thing SimpleDB claims: better availability with all data automatically replication across data centers and all servers in your cluster able to handle both reads and writes independently. If an entire data center goes dark or if a router literally melts, your app may still be humming away. Perhaps with a degraded service level, but fully functional if you planed it well. And when the problems get fixed the data automatically syncs back up in the background.
• Good performance. It's not as fast as a locally hosted SQLServer instance with no load, but out of the box it is easily fast enough for user data (and more) and it scales well.
• If you run your ASP.NET app on an Amazon EC2 Windows server, you get fast free data transfer between your server and SimpleDB. Typical round trip ping times are between 2ms and 7ms.
• The free usage tier covers 1GB bandwidth, 1GB storage and 25 hours box usage per month. Depending on the app, you might be able to go quite far for free.

Disadvantages include:

• There are no relations or constraints or schema so you have to denormalize to a degree. Constraints you want to check must be done in code and joins you want to do will require follow up queries to simulate. Joins with follow up queries and primary keys are not as bad as they sound since SimpleDB has a solid query API and is optimized for concurrent requests. A lot of the time even complex joins can be simulated in (the equivalent time of) 2 round trips to SimpleDB.
• You don't have setup and configuration options to tweak.
• You have to be able to deal with eventual consistency. You can always apply atomic updates and deletes at the item level but updates may not show in read requests up for a full second during normal operations (in my experience, not a guarantee). And of course much longer during failure scenarios. "dealing with it" usually has to happen at the session level. If a user updates her profile (using your app) and nobody else can see the change for a couple seconds it's OK, but if her view reverts back to the old state for a few seconds that would be bad. There are some easy ways to deal with this, but you do have to think about these issues and deal with them.
• You are at the mercy of Amazon. Nothing bad may happen, and it isn't necessarily any worse than being at the mercy of a SQLServer hosting company. But it may cause concern for some people. Worse than the SQLServer case: a SimpleDB app isn't going to work anywhere else if you part company with Amazon (except for a locally run M/DB instance).