|
Ruby on Rails has taken the web application development world by storm.
Those of us who have been writing web apps for a few years remember the
good ol’ days when the leading contenders for web programming languages
were PHP and Java, with Perl, Smalltalk, and even C++ as fringe choices.
Either PHP or Java could get the job done, but millions of lines of legacy code
attest to the difficulty of using either of those languages to deliver solid web
applications that are easy to evolve.
But Ruby on Rails changed all that. Now thousands of developers around the
world are writing and delivering high-quality web applications on a regular
basis. Lots of people are programming in Ruby. And there are plenty of books,
screencasts, and tutorials for almost every aspect of bringing a Rails application
into being.
We say “almost every aspect” because there’s one crucial area in which Rails
applications are not necessarily a joy; that area is deployment. The most elegant
Rails application can be crippled by runtime environment issues that
make adding new servers an adventure, unexpected downtime a regularity,
scaling a difficult task, and frustration a constant. Good tools do exist for
deploying, running, monitoring, and measuring Rails applications, but pulling
them together into a coherent whole is no small effort.
In a sense, we as Rails developers are spoiled. Since Rails has such excellent
conventions and practices, we expect deploying and running a Rails application
to be a similarly smooth and easy path. And while there are a few standard
components for which most Rails developers will reach when rolling out a
new application, there are still plenty of choices to make and decisions that
can affect an application’s stability.
|
|