Phusion Passenger has come a long way since its first public release, significantly simplifying the deployment of Ruby web applications on Apache servers, especially since the addition of support for Rack.

You can use this example Capile if you’d like to get started quickly with trying out Passenger deployments on Amazon EC2.

It is assumed that your environment has been previously configured for launching EC2 AMIs. If not, you might want to read the EC2 Getting Started Guide, or refer to the first bits of this article.

By completing the following steps, we will end up with a running Debian AMI, with Ruby 1.8.7, Rubygems 1.2.0, Apache2 and Passenger installed.

First, find the section about AWS credentials in the Capfile and replace the values with yours. These are :keypair, :account_id, :access_key_id, :secret_access_key, :pk and :cert. Once this is done, invoke:

cap instance:start

Copy the instance id from the output of this command and use it as the value for the :instance_id field in the Capfile. Call ec2-describe-instances until the AMI has been started. Use the instance URL that comes for the :instance_url field in the Capfile. Next invoke:

cap instance:bootstrap

This will install Apache2 and Passenger on the instance. Once this step is complete, you can navigate to the instance URL from a browser and see the default page served by the newly installed, Passenger enabled Apache. At this point - optionally and for demonstration purposes - you can invoke:

cap instance:example_app

This will install the Merb gems, create a flat Merb application in the instance’s /var/www/example directory, set it up for use with Passenger (create public, log and tmp directories and add a config.ru Rack configuration file as required by Passenger) and setup an Apache virtual host in order for Passenger to serve the application. Once this step is complete, navigate to the instance’s URL and you should see a page served by Merb.

There’s another couple of convenient commands in the Capfile, cap instance:ssh and cap instance:stop.

Danilo and I will be talking about REST (or maybe not…) at the Rails Summit Latin America, October 15, 2008. Many thanks to everyone who’s given me the opportunity to participate.

Is the free lunch really over? It surely is a question that troubles many software developers. Constrained by the laws of physics, processor manufacturing has definitely changed its rules of play the last few years. It steadily and increasingly becomes near impossible to extract more juice out of a CPUs single core.

Since I started thinking about the implications of the multi-core evolution, I always kept an open eye for situations where taking advantage of multi-core CPUs would profit my work. It is almost certain that the reason has to do with my work being primarily around server side applications, but I’m still to come against many situations where adopting a multi-core influenced approach would have provided additional benefit which could have been achieved by exclusively following this paradigm.

The problem is undeniably evident if we approach it from the side of computational units restricted by the laws of physics. It seems like we will always have a healthy appetite for increased performance, and given we can’t get much more out of one core, we must start thinking and programming in a multi-core context. We could do with OpenOffice being more feature rich and faster, thus our desktop needs to be more potent.

At the same time, the web, and networking in general, is increasingly influencing the way we think about, use and create software. Considering the OpenOffice example, there is already a myriad of applications moving similar functionality over to the web. Networking brings distributed solutions to the table, which, alongside other applications, are widely employed for improving software performance.

Next to physics, the software world is governed by the laws economics. The creation of software must result in some form of social, or financial, or other profit, part of which is achieved by minimizing associated costs. It is almost certain that vendors will claim that a data center of quad-core equipped slices is the next answer to our software woes, but it pays to remember that a cloud of commodity hardware might, in some situations, improve rate of return. The lunch was never free, but today, just like 10 years ago, it’s really about how cheap the lunch is.

The need for concurrency remains an undeniable must, but whether its mainstream representation will be that of multi-core friendly programming or distributed over a network architectures remains to be seen.