peat dot org

For the last couple of months I’ve spent a little time each week with the OpenSolaris team at Sun, putting together an Amazon EC2 image that makes it easy to deploy and experiment with Ruby on Rails.

They released the AMI last Friday, but I’ve been too crazy busy to make an announcement. Here’s the official word, and here’s my take on it …

My goal with this project was to help people get a Rails app running as quickly as possible. We set up this AMI so that you can get your hands dirty with Rails if you don’t want to spend the time installing everything on your home system or server, and it’s an inexpensive and easy introduction to OpenSolaris if you’re curious.

All the requisite goodies are pre-installed: Rails 2.1, Mongrel, PostgreSQL and MySQL, Subversion, Git, Capistrano, and a few others choice gems. You also get DTrace built into Ruby, if you’re keen on that sort of thing.

There’s also a sample Rails app in your home directory, and a pre-configured SMF file that serves as a handy introduction to the very handy Service Management Framework — the OpenSolaris system for managing daemons and other server processes.

Working with the OpenSolaris AMI team was a lot of fun, and in particular I’d like to give a thanks to Prashant who did most of the hard work getting everything set up.

Do you have suggestions for what to include in a kick ass OpenSolaris AMI, geared towards deploying Ruby on Rails apps?

I’m working with the folks at Sun to build an Amazon EC2 AMI for Rails developers. The plan is to put together an environment that makes deploying production Rails apps relatively easy. My inclination is towards a Rails stack that includes Nginx, Mongrel cluster, Capistrano, MySQL and some common gems and services — maybe RMagick, and/or ImageScience? Memcached?

Let me know what you want, and I’ll see what I can do about it!

A few days ago I wrote about my initial impressions of the OpenSolaris on Amazon EC2 beta. It was a little frustrating, however, the people who are running the program at Sun got in touch with me, and we spent some time talking on Friday morning about the experience.

The upshot of the conversation is that I think they’re headed in the right direction. We worked through some of the IPS and documentation issues I was having, and chatted about what they’re working on over the next few weeks. Specifically, they’re in the process of building and releasing a set of AMIs built on OpenSolaris that target specific application environments — for example, GlassFish for the Java EE folks, or Ruby on Rails.

The first AMI they provided (ami-0c41a465) is just a blank slate, a trimmed down OpenSolaris 2008.05 installation. Those who are interested in the Apache/MySQL/PHP stack can tinker away by installing the ‘amp-dev’ package.

I finished the call feeling good about where the project is headed, and impressed by the people I spoke with. In fact, I’ve volunteered a little time to help put together the Rails AMI next week. If anyone has any favorite gems or other Rails goodies they’d like to see installed, let me know!

For more announcements about the OpenSolaris on EC2 program, head over to their blog at http://blogs.sun.com/ec2.

I spent some time playing with OpenSolaris on EC2 this weekend, and I’m a bit disappointed — partially because of OpenSolaris, and partially because of how the beta program was set up.

But, good news first. I’m glad to see Project Indiana released, and EC2 is an easy way to take it for a test drive. All of the packages I tinkered with could be DTraced to my heart’s content, and it’s definitely a great improvement for debugging and monitoring of apps in the EC2 environment.

Bad news? First, all of the beta instances I booted were very slow. I’m sure this has to do with the provisioning of hardware for the beta program, and not with OpenSolaris itself. The beta servers are separate from the main Amazon servers, and I expect the speed will be on par with Linux when the beta period ends. Regardless, it does make the experience pretty frustrating.

Second, OpenSolaris openly touts their great package manager, but the selection of packages downright sucks compared to the Linux distros available on EC2. If you’re deploying anything more than a basic web stack on OpenSolaris, you’re going to be building a lot of software by hand, and that can be a frustrating experience on any Solaris.

Regardless, I could get PHP and Rails apps humming along just fine (although I’ve had a lot of practice). While OpenSolaris feels stable and DTrace is great, I spent way more time getting a system up to speed than I would have with Ubuntu or CentOS. The over-utilized servers didn’t help much either.

I do have hope for the future, tough. None of the issues demonstrated fundamental flaws in OpenSolaris or EC2, and I expect all of these problems to be fixed in time. The OpenSolaris team has obviously put a lot of work into this release, and I’m looking forward to seeing how the platform evolves.

One thing I haven’t been able to play with is ZFS. I’m interested in benchmarking ZFS on the persistent storage service, and a little excited to see what happens when several storage reservations are ganged up into a single ZFS pool … although I’m not going to go anywhere near that situation until the basic performance issues are resolved!

Update: I just wanted to clarify the package situation — the shortage of packages is only on the basic EC2 image for OpenSolaris 2008.05, not on the standard distribution you download from the OpenSolaris site.

Update: I had a follow up call with the OpenSolaris on EC2 team.  More thoughts here.

I ran across this error message when I made a slight mistake when booting an OpenSolaris image on EC2:

Client.InvalidParameterValue: Invalid value 'solaris.indiana' for kernel profile.
Supported values are [default, solaris, freebsd].

I’ve been waiting for this since EC2 was announced. Anyone have more information on the status of FreeBSD on EC2?

Interesting news this week — along with the release of Project Indiana, Sun is also providing limited access to OpenSolaris images running on Amazon’s Elastic Compute Cloud. I’m keen to try it out, but at the same time I’m a little skeptical about the whole thing.

I have high hopes for Project Indiana. After working with Joyent Accelerators, there are a lot of things I like about Solaris (the service manager, ZFS, DTrace, etc.) and a lot of things I don’t like (awkward package management, very DIY for relatively simple things).

Indiana running on EC2 instances is a good way to introduce people to the platform, but it’s a bummer you have to register with Sun and get their permission before jumping in the pool. I hope the waiting list isn’t too long. I’m itching to play.

Hopefully Indiana on EC2 is lean, mean, and easy to get started with … but I have my doubts that it will be a replacement for my current Ubuntu AMIs. I don’t have any super custom configurations, I just don’t think EC2 isn’t the kind of environment where Solaris really shines — EC2 is lots of little servers, not a big box with a bunch of cores and spindles. Regardless, I’m an optimist, and I look forward to being proven wrong.

I’m waiting on access to the Project Indiana AMIs. I’ll report back as soon as I get my feet wet.

Update: I’ve been accepted to the beta program, but I don’t think I can do a test drive until this weekend. More information then!

I received a friendly e-mail this morning from Amazon, announcing persistent storage for EC2 instances. From the looks of it, the storage behaves like NAS — it exists independent of the instances you’re using, and can be mounted whenever you like. Not bad. I’m interested to see what the IO performance is like.

Other features include:

* Snapshots, to back up the storage to S3.
* Multiple volumes per instance.
* Shows up as a block device on the instance, so any filesystem can be used.

Persistent storage is in limited private beta right now, but according to the announcement it should be publicly available “later this year.”

Amazon announced Elastic IP Addresses for their Elastic Cloud Computing (EC2) service this morning, which removes one of the biggest hurdles for deploying web sites on the service. Previously, customers had no control over the IP addresses assigned to their EC2 instances, a frustrating situation for anyone wanting to reliably point a domain into the cloud.

Elastic IP Addresses solve this issue in a rather elegant way, by assigning a static IP address to your EC2 account, and providing a mechanism for routing that address to any of your EC2 instances. This system provides a reliable address for DNS, and enables failover and takeover features for applications with high availability requirements.

Kudos to Amazon!

Werner Vogels, the CTO at Amazon, has a great post about the contentious idea of “eventual consistency” for the new SimpleDB service. The idea that a database could be inconsistent is a little disconcerting to a lot of people — after all, inconsistent means unpredictable, and that just doesn’t fly for us deterministic computer people. Right?

Well, “eventual consistency” isn’t entirely unpredictable. And, it has it’s benefits — especially when it means avoiding locking on highly concurrent read and write operations. That’s exactly what SimpleDB was designed to do. To quote Vogels:

“Inconsistency can be tolerated for two reasons: for improving read and write performance under highly concurrent conditions and for handling partition cases where a majority model would render part of the system unavailable even though the nodes are up and running.

“Whether or not inconsistencies are acceptable depends on the client application. A specific popular case is a website scenario in which we can have the notion of user-perceived consistency; the inconsistency window needs to be smaller than the time expected for the customer to return for the next page load. This allows for updates to propagate through the system, before the next read is expected.”

(from “Eventually Consistent“)

SimpleDB was intentionally designed to behave this way, which means it certainly wasn’t built to replace traditional ACID relational databases for all scenarios. If you think about how often you require immediate consistency in your web applications, you’ll likely find that a very significant portion of your database interactions don’t.

My biggest concern about SimpleDB isn’t consistency or relationships, it’s latency. SimpleDB queries from outside of the Amazon cloud won’t be fast enough to feed sites that require more than a couple of queries per page — unless those queries can be executed in parallel, which isn’t an easy option in single-threaded web environments (PHP, Rails, etc.).

I’m excited to see how it operates with parallel queries, though. If an application is built to make dozens of queries simultaneously, rather than sequentially, the performance could be excellent.

I have a little Java toolkit for querying web services in parallel, and I’m itching to unleash it on SimpleDB. All this hot air blowing isn’t worth much without real numbers, right?