I plan to write a series of posts about how we develop, deploy, and support our affiliate software and digital downloads applications. And why, after 5 years of Ruby on Rails development we switched back to PHP. One of the reasons is what I refer to as the shelf life of a web application. Let’s talk about what happens to a web application if you just let it sit.
Ruby on Rails – Rotted on the vine
First of all, I want to start by saying that even though we’ve made the decision to switch from Rails back to PHP, I’m not bashing Rails. We still love and develop our WordPress e-commerce platform which is a huge Rails application. I’m just pointing out some of the hurdles we’ve had to overcome – especially with the consulting side of our business – and how switching back to PHP has helped us both with consulting projects and with our own new apps.
Back in 2008 we built a web app for consulting client. Being a consulting project, the plan was to implement the application then hand it over to the client. After handing over the finished project we were not going to be involved with the app – at least not on a day-to-day basis.
The app was built using the current version of Ruby on Rails which, at the time, was version 1.1. We built, tested, and deployed the app – complete with a cluster of mongrels – and handed it over to the client. Everyone was happy, we got paid, and started working on other consulting projects. From time to time we were contacted about minor updates, but when Rails 2.0 was released the client chose not to upgrade. No new end users features or benefits were going to be realized by the upgrade and the client didn’t want to pay the costs to rework a bunch of stuff under the hood. The problem was exacerbated even further when Rails 3.0 was released.
Jumping forward to today, they still have a Rails 1.x app and their hosting company contacted them saying that the version of their operating system was no longer supported and that they needed to update their server. This created a variety of technical problems with the version of ruby, and trying to get a Rails app that’s over 5 years old to run on a current server OS. In addition to the technical hurdles with the server, trying to find a developer willing to maintain a Rails 1.x app is virtually impossible. The application sort of just rotted on the vine.
Framework upgrades cost money
You can say that the client should have kept their app up to date, but that was not an expense they considered when developing the app and it’s very hard to sell a project to migrate a large app from over version of a development framework to the next. Even when upgrades and enhancements were requested, the extra cost to upgrade the version of the framework was not in their budget. Whether or not it should have been part of their budget is not really the point. The point is it takes time and costs money to keep a development framework, especially one as huge as Rails, up to date.
More than just languages and frameworks
What would have happened if we had built their application in PHP instead of Ruby on Rails? Well first of all PHP is a language and Ruby on Rails is a web development framework. So it’s not a fair comparison at face value. If we had built the application with PHP we would have probably looked at PHP frameworks like the Zend Framework and, perhaps to some degree, would have had a similar problem with keeping the framework up to date.
There’s more to deploying a web application than picking a development language and framework. For example, back in 2008 the popular way to deploy a Rails app was running an Apache server for static content and passing dynamic requests through to a cluster of mongrel processes handling all the Rails stuff. Today, nobody deploys Rails apps like that. So if our client wanted to upgrade their app, it’s more than just keeping the framework fresh but you have to implement an entirely new way of hosting and deploying the application.
PHP applications have pretty much always been hosted and deployed the same way. We’re currently hosting our PHP apps with Engine Yard keeping the source code on GitHub. Engine Yard has a really nice setup for deploying all sorts of apps including PHP applications. I’ll describe our setup for how we do all of this later if you are interested, but the bottom line is, the entire app, complete with database migrations is deployed with a single click. We could have used the exact same setup in 2008 as we are using today in terms of the hosting stack – PHP, MySQL, Apache (or nginx).
Reducing exposure to app rot
To put it all together, the aspects of web application development that contribute to the life span include:
- Keeping the development language current
- Keeping the framework (if you use one) up to date
- Keeping the server operating system up to date
- Keeping the development stack (how you host and deploy) consistent
- Finding developers who can work on your application
Using PHP, you can dramatically reduce your exposure to things that rot your app. One of the reasons we have switched back to PHP after over 5 years of Rails development is that PHP apps don’t rot nearly as fast.
I plan to follow this post up with a discussion of development frameworks and where we’ve landed in our attempt to optimize developer productivity with application life span. Even for our own internal applications, we don’t want to spend time (and money) migrating from one version of a framework to another. It would be better to spend that time adding end user polish and marketing the businesses.
Advice for start ups and freelancers
If you are thinking about starting up a web based company or if you are a freelancer or consultant building apps that you intend to hand off to your client, you should pay very close attention to what you need to do to keep the app running after initial development is complete.
If you are building a web application for your self or you have a dedicated team that will always be developing and maintaining your application then a Rails application may have it’s merits. But if you are handing the application off to your client, a PHP application will last longer and will be easier to find developers to maintain.
I think everyone understands, but it is worth mention this in a quick disclaimer. Developers in the Ruby on Rails community tend to be more seasoned and more highly skilled. The PHP community is gigantic and includes seasoned, highly skilled developers also. But, the PHP community also includes a large number of entry level developers. The languages is so pervasive and easy to pickup and run with that it attracts people who aren’t very experienced. Since PHP is so easy to run, host, install, and learn there are a lot of applications written by folks new to the idea of application development writing code that lacks the elegance and organization of more experienced developers. You have to start somewhere and I applaud anyone who is interested in getting into the world of coding no matter what language you pick.
Coming up next
We touched briefly on the concept of web development frameworks. I’d like to go a bit deeper into that topic soon and discuss the merits of frameworks and how we landed on the framework we’ve been using for our more recent web applications.
If there’s anything you’d like to see covered in more detail, just let me know. Until then, happy coding and peace my friends!