litany against fear

Four Years of Ruby Development Notes

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Ezra Zygmuntowicz from Engine Yard.

He’s going to go over his history working and deploying with Rails.

Started with WEBrick, which rocked for development but obviously not for production. He first tried out Apache with FastCGI. Didn’t work that well either. Had to write scripts to kill zombies.  Lighttpd + FastCGI was bad. Lighttpd + SCGI was bad. Another Apache combination that sucked too.

Then…MONGREL! Pure text, can hit individual mongrels, great platform for sure and still in use. Lighttpd’s proxy module failed. Lightspeed was next and it was nice, but their license sucks. Mongrel + Nginx was next! This combination works really well and is battle-tested. Ebb is actually faster than Mongrel since it’s single threaded and event-driven. Mongrel though is still the best general purpose server.

Passenger has done an awesome job, but it’s geared mostly towards development and shared hosting/small VPS. Nginx + Mongrel or Thin for high volume deployments. Passenger might be there someday, but not yet. Ruby Enterprise Edition helps with memory, but Apache is a hog so it doesn’t matter.

Rack: the great equalizer! Boils down any web server down to an object with a ‘call’ method on it. Makes it a lot easier to write handlers that are server agnostic. Rack is fast becoming a standard and it future-proofs your code/app.

Nanite: builds scalable backends for Ruby apps. Nanite ‘agents’ report back to a broker, which then fan out reports to various Nanite ‘mappers’ on the front end. It’s built around RabbitMQ, which is written in erlang. This means it’s fast, clusterable, and very scalable. Apps just need to appear fast, not actually be fast. This system is crazy useful for building apps on scalable cloud sites like EC2. Basically, it makes it easy to build scalable backends.

Engine Yard As a Service! Going to open it up for other hosting platforms to use their infrastructure with. Other services are very low level, but they want to make it easy and approachable. They’re going to attempt to apply the convention over configuration that Rails provides to deployment. Instead of logging into your server to make changes, you log into their application and describe what your app runs on. It’s the genetic information of your app and allows for greater portability. Allows you to build an entire server from scratch and deploy your app with one click. This is a much different way of thinking about deployment! No manual changes, all done through site’s interface. Ridiculous.