I recently moderated a session at RailsConf 2008 called “Top 10 Ways Rails Annoys IT”. The title was contentious, but the goal was to identify and resolve the operational challenges of Ruby on Rails applications. We focused on ways Development teams can work with IT and Operations groups to manage the new Rails deployment processes.
In our discussion, communication between groups surfaced early as a common culprit. The hand off of a new application to a data center team involves plenty of touch points, with any architecture. A good Ops team will have already provisioned hardware, configured the server OS, secured the systems and made databases accessible. But what about Capistrano? Rake? Puppet? Oh, you were planning on nginx with virtual hosts? Do the folks in IT read Russian? Of course they’ve moved off CVS and are prepped to pull code from your Subversion repository, right? What? You’re using Git now?
Ok, so you get the idea. An agile dev team’s technology adoption rate may be high, but their IT peers are often on a more conservative track. Rails can be something of a moving target in general, especially for Ops teams not involved in the day to day environment changes. Examples were raised in our forum of corporate IT being often bypassed in a pinch, by outsourcing hosting and developers pushing to production directly. This has advantages of expediency and simplicity, but what is also happening is that dev is assuming a larger deployment responsibility. Even specialists within Dev teams are now identified as framework performance, availability or database optimization experts, roles formerly the responsibility of sysadmins and DBAs. They have to consider migrations, server resources, upgrades, etc. Jeremy Kemper mentioned this in the core team’s panel discussion. Planning the mechanics of code updates or deciding an efficient number of Mongrels is likely not the best use of programmer resources.
While dev is becoming more involved in the production realm, the same can be said for IT’s involvement in new languages and frameworks. 37signals announcement of Mark Imbracio as their new IT lead includes his creds as a “talented Ruby programmer”. It doesn’t take long browsing Deploying Rails Applications to note the authors are skilled coders, even creating a new cloud provisioning framework. Ten years ago the sysadmins were Apache gurus, load balancing specialists and maybe experts at helping identify database bottlenecks. They were not as likely to be involved in the programming architecture of a Java app they maintain though.
So could IT functions be absorbed outright into Dev? Or will the folks at Engine Yard and Heroku eliminate the need for server provisioning and production optimization? If we achieve drag and drop Rails deployments will we need IT to serve the applications at all? To borrow a phrase, “IT cycles are neither create nor destroyed, although they may be rearranged”. Someone is always responsible for buying hardware, optimizing server environments, indexing databases and any other classic Operational task. They may shift teams internally or be outsourced, but somewhere these tasks are still an engineer’s responsibility.
Dev and IT teams are working (or becoming) closer to each other than ever before. Perhaps as Ruby and Rails deployment and administration tasks normalize, we’ll see Engineering roles separate again. Currently, the gap still seems to be shrinking.
