I’ve been looking at various ways to host a "cloud app," including setting up a server instance in the Amazon Elastic Compute Cloud (“EC2″) or signing up with a cloud management service such as RightScale or Ylastic.

To set it up myself or use a service such as RightScale or Ylastic, I am going to burn up hours configuring a server instance and doing system administration.

Yesterday Ezra Zygmuntowicz announced a new service from Engine Yard, called Solo, that’s going to make things a lot easier for me. It’s a service that creates and manages a host for a Rails or Merb app in the Amazon compute cloud.

This means I can sign up for the service from Engine Yard and get a control panel that lets me specify how much computing power and storage I need, specify or install any Ruby Gems I need, clone my app from a Git repository such as GitHub, set an IP address, and launch the app.

It eliminates a whole lot of system administration and gives me exactly what most Ruby web apps developers need.

Three instances of the app can run at once, for development, staging, and production servers. It’s configured for persistent storage, so you can shut down the server instance and bring it back up with all your data still accessible. The service will automatically back up databases, too. You get a choice of Nginx/Mongrel or Apache/Passenger for your web server. You can run the Rails or Merb application frameworks.

Basically this means I can write an app, host it in the cloud, and I don’t have to screw around with hosting and system administration.

The cost for Solo is a minimum of $129/month, which is a bit more than what I’d pay if I set it up myself with Amazon ($74/month is about the minimum cost of a month of running a server in the Amazon cloud).

The trade-off here is the internal cost of system administration.

Some people like to spend the time to be competent, knowledgeable system administrators. For cloud computing, I could tinker around with my own Amazon EC2 instance and pay only $74/month for the privilege. Just like I could sign up with SliceHost or some other Rails-friendly VPS provider and configure my own server for $20/month. That’s not for me. There are other things I’d rather be doing, like building a business. For my most recent startup client, we paid $1000/month for hosting from Engine Yard and I considered it a near-bargain compared to the cost of hiring or developing inhouse system administration expertise. For $1000/month, we got the equivalent of one $129 Solo account plus access to Engine Yard’s superb system support staff. With Solo, we’ll be getting Engine Yard’s hosting and system administration expertise packaged up as a utility service. We won’t be getting access to Engine Yard support via phone, email, or their ticketing system (support is only offered through an online forum). But I think this will work for me. It’ll cost a bit more than typical VPS hosting, but it’ll be in the cloud, it’ll be configured with all of Engine Yard’s know-how, and I won’t have to become a system administrator to run it.

Ezra says the service will be available on January 28th, 2008.

Here’s a tutorial on setting up Amazon SimpleDB for storing user authentication data.

You’ll need to sign up for an Amazon Web Services account: Create an Amazon Web Services Account.

You’ll get an email message that gives you the link to the page where you get your Amazon Web Services Access Key ID.

You’ll need to look for the button that signs you up for the Amazon SimpleDB Service on the Amazon SimpleDB Introduction page.

The SimpleDB sign-up page will give you pricing information. You get considerable use of the SimpleDB service for free (enough for development needs). But you’ll have to provide a credit card and billing address to sign up for the service. You’ll receive a confirmation email.

At this point you may want to install a desktop management tool for accessing Amazon SimpleDB. You might try SimpleDBExplorer or Bolso. See my blog entry User Interface Applications for Amazon SimpleDB about others. You’ll need your Amazon Web Services Access Key ID and secret key to access Amazon SimpleDB with these tools.

Next you’ll need to create a “domain” within SimpleDB. Domains within Amazon SimpleDB are similar to tables in relational databases. Or a domain can be thought of as a workbook in a spreadsheet that contains rows and columns that intersect to create cells. If you are using a front-end tool to manage Amazon SimpleDB you’ll have a button to “add” or “create” a domain. Try adding “mytestdomain”.

That’s all you need to do if you’re going to try out the Merb example app using DataMapper and SimpleDB that I describe in my blog entry Storing User Authentication Data in the Cloud.

I’m looking for desktop apps I can use to manage Amazon SimpleDB.

So far, I’ve found:

• SimpleDBExplorer (multi-platform)
• Bolso (multi-platform Adobe AIR)
• Ylastic (web-based)
• Mindscape SimpleDB Management Tools Windows

Got any others to recommend?

Today Amazon announced a Web-based AWS Management Console but the initial release is only for Amazon EC2 (their servers).

I’m exploring building a web app with a “shared-nothing” architecture. (Are we calling these “cloud apps” yet?)

I was looking at user authentication in Merb using merb-auth and started wondering if user authentication data could be saved in the cloud. It seems to fit the limitations of cloud data storage, especially Amazon SimpleDB. User authentication data is typically only written once (when a user registers) and only read once per session (when a user logs in). It’s also schema-less, which is intriguing, because one could add user attributes over time as needs develop.

I found a recent project on GitHub where Dan Mayer built a Merb example app using DataMapper and SimpleDB.

As a first step, it needs the Ruby aws-sdb gem. Then I grabbed Dan Mayer’s example from the GitHub repository.

sudo gem install aws-sdb
git clone git://github.com/danmayer/merb-simpledb-dm_example.git

I changed the file /config/dependencies.rb to update to “merb_gems_version” from “1.0.4″ to “1.0.7.1″ (the Merb version on my machine). It ran successfully:

cd merb-simpledb-dm_example/
merb

I generated a default “Hello World” Merb app and compared it to merb-simpledb-dm_example to see what Dan Mayer had done (thanks Mac OS X FileMerge). Here’s what he added:

lib/simpledb_adapter.rb

with a require 'lib/simpledb_adapter.rb' in the config/init.rb file.

The code for simpledb_adapter.rb is pretty much the same as a project on GitHub by Jeremy Boles named dm-adapter-simpledb combined with a Migration module from a project by Edward Ocampo-Gooding named dm-simpledb.

You’ll need to have an Amazon Web Services account set up for Amazon SimpleDB. You can read my blog entry Setting Up Amazon SimpleDB for User Authentication for details.

You set up access to Amazon SimpleDB in the config/database.yml file:

  adapter: simpledb
  database: 'default'
  access_key_id: '1_your_access_key_1'
  secret_access_key: 'b_your_secret_key_b'
  domain: 'your_app_development'
  base_url: 'http://sdb.amazon.com'

There’s nothing to do beyond that. Just fire it up and it runs.

The conventional approach to building a web app is to pick a web application framework (PHP, Java/Struts, Python/Django, Ruby on Rails), pick a database server (MySQL), sign up with a hosting service, and write your app. You’ll get one or more instances of your app running against a single instance of a database. You’ll deploy your application from a repository (using svn or git) and backup your database every ten minutes or once a night (unless you don’t backup at all). As your traffic grows, you’ll figure out how to scale by load balancing between instances of your app and sharding your database. That’s the monolithic approach to building and deploying a web app. Been there, done that.

Web apps with shared nothing architecture are becoming easier to implement as cloud computing services become available. I don’t know if it’s possible to build a web app without a single point of contention or single point of failure but it’s now possible to distribute many pieces of a web app more practically than before.

Application business logic can be moved to the web browser with JavaScript platforms such as Sproutcore. Databases can be moved into the cloud where replication and redundancy are included within the utility (Amazon’s Simple Storage Service). What’s left is routing and controller logic. I’d like to see how much of that can be distributed.

Since the early days of the web, I’ve been frustrated with the difficulties of web publishing. Creating material for the web, and making it accessible, has never been as easy as reading. One problem is the complexity of authoring tools and the other problem is the necessity of using web servers.

The big innovation of the web was the ability to read documents anywhere. If you were on a computer at home or at the office, you could read the same documents and follow the same links. There were some initial limitations (the only available web browser was on the NeXT Computer and you had to know a netgod to get an Internet connection) but the Mosaic web browser (and others that followed) and an explosion of commercial Internet service providers made web access nearly universal.

Creating documents for the web never has been as easy as reading documents on the web. But why not? Almost anyone who can read words on paper can write words on paper. Literacy should be a read/write activity, with writing as easy as reading, online or off.

There were some initial efforts to offer hosted web pages with easy-to-use web authoring interfaces but most were quite clumsy and limited (for example, GeoCities in 1995). Web publishing got easier when content management systems developed and evolved into blogs. As the web has evolved to become more functional, blogs have evolved to include embedded video from YouTube. Now MySpace and FaceBook allow anyone to create a web presence with widgets that provide more functionality than just text and graphics and video. But this is still only a 21st century version of GeoCities; yes, more functional, but still clumsy and limited to what sophisticated developers make available to unsophisticated users. Ease of creation, and access to the full range of possibility, is still limited. Ordinary users are given only a box of twelve crayons when some kids (hardcore developers) get the big box of 96 crayons. It’d be nice to find ways to share the crayons.

The other problem with publishing is the notion of the web server. Yes, you can read documents from anywhere, but you can only store them in one place, on a web server. Why do we have to have web servers? Web servers are expensive and difficult to configure and maintain. For the most part, we pay experts to maintain web servers to host our web sites. Or we lock ourselves into services like MySpace or WordPress that maintain servers that run turnkey publishing systems. When we read documents (or visit web sites) the web operates like a utility originating from a cloud. I’d like to see more exploration of the idea of creating and storing web sites in the cloud, free of dependencies on individual servers or hosting companies.

The Internet underpinnings of the web are durable, robust and ubiquitous. DNS (the Domain Name System) is always there and always reliable and shared universally. The Web was built on that foundation to make documents (and then functional applications) accessible everywhere. Web servers were a necessary inconvenience in the early days of the web but it is time they were superseded by web services.

I’m not quite sure what that will look like, but it’s time to engage the unknown and see what takes shape.

Every application has users, and typically, one wants to restrict access to registered users. That means writing code for user authentication. Or does it? Merb comes with the merb-auth gem baked in. When you generate an application with the default merb stack, merb-auth is already set up for typical usage.

Here’s information about using merb-auth:

• Merb::Authentication Documentation
• A chapter from the Merb Open Source Book on Authentication

As an alternative to merb-auth, there’s the Ruby Authlogic gem from Ben Johnson which is an interesting implementation that works with Rails or Merb. For now, I’m just going to look at merb-auth.

I’m using DreamHost as an initial hosting platform for yax.com development.

DreamHost is one of the least expensive web hosting services available. I’ve used EngineYard for production sites but given their pricing, it’s not an option for early stage development, so I’m trying DreamHost for this project. At DreamHost, one account gives me as many domains and sites as I need for any projects in development. DreamHost has an extensive wiki and active user forums for support. And despite what one might expect from the bargain price, I’ve been very happy with the quality of service from the DreamHost support staff. Since it’s shared hosting, I don’t have to wear the hat of a system administrator. And, for shared hosting, the service is fairly sophisticated. For example, I can run Merb, which I’m going to use for the yax.com project.

I’ve completed installing Merb 1.0 at DreamHost and confirmed, yes, Merb can be installed to run on a DreamHost shared server.

Did Merb run “out of the box” at DreamHost? With a “zero-configuration” install? No. First of all, there was some typical UNIX configuration overhead in creating a ~/.gem directory and modifying my ~/.bashrc file. Second, Merb is configured by default for Mongrel, not Passenger. Perhaps future versions of Merb will accommodate Passenger by default (see the currently open ticket) and installation may become a bit easier.

For me, the biggest challenge was sorting through several dozen blog entries that provided tips of varying usefulness.

To sort out the confusion, I created a wiki entry on the DreamHost support wiki that provides definitive and up-to-date instructions.

Here are some blog entries that were helpful (though dated):
PunNeng on Installing Merb on DreamHost
Merb, Passenger and DreamHost

My desktop development machine is a Mac (like most UNIX-bred developers these days). I’ll be using Merb as a web application framework for the yax.com project.

Merb needs Ruby 1.8.6, which is already available on Mac OS X 10.5.

Here’s how to check your Ruby version:

1. In iTerm, type ruby -v.
2. You should see “ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]“.

Check your version of RubyGems:

• gem -v

You’ll need RubyGems version 1.3.0 (or newer):

1. sudo gem install rubygems-update
2. sudo update_rubygems

Here’s how to install Merb:

• sudo gem install merb

And, since Merb is getting updated often, here’s how to update:

• sudo gem update merb

Here’s the collection of Merb resources I’ve found most useful. Suitable for Merb 1.0 (released November 7, 2008).

• Merb Resources from Ruby Inside

Right now, I’m not going to detail why I’m using Merb for development of yax.com (maybe later).