Switching from Classic ASP to PHP

This is a cross post from the Wayfair Engineering Blog

One of the big changes at Wayfair recently was moving all of our storefront code (well, almost all…we’re still working on our sessioned code) from Classic ASP (VBScript) to PHP.  The company was started in 2002 and at that time ASP was a common technology on the web, and one that our founders were familiar with.  After 8 years of working with it, we had pushed it to the limits and decided we’d get more benefit out of moving to a new technology.

Motivation for Switching

While ASP is still in extended support, as a language it hasn’t been actively developed for a number of years (I tried to find out exactly how many years, but my Google searches were fruitless, which might tell you something).  It’s also a proprietary Microsoft language, so we were unable to make modifications ourselves, so any bugs we found were not getting fixed.  ASP’s age also means that there are very few companies using it, so the community is small and there are basically no open source projects written in it that we can use.  It was also getting harder and harder to hire developers with Classic ASP experience. While training people isn’t hard to do, we would rather hire experts who are going to help us squeeze every ounce of performance and functionality out of a language.

Once we decided to switch, we obviously had a huge number of technologies to choose from, so why did we end up with PHP?  We had a few goals in mind when selecting a language:
  • Open source language that runs on an open source stack
  • Actively developed and widely used with a strong community
  • Longevity – we wanted some indication that it would be around for a while
  • Procedural and easy to learn if you have an ASP background (we do have 50+ engineers who know Classic ASP, after all)
  • Not a framework (perhaps I’ll blog about the logic behind this at some point…)
  • Good performance and good memcached integration
Given these requirements and the experience of the people making the decision, PHP seemed like an obvious choice.  With Facebook and Yahoo! using PHP extensively, we think it will be around for a while, and the community is obviously awesome.  Writing PHP is also a fairly easy switch for people who are used to ASP (or any procedural language for that matter).
We also wanted to use this as an opportunity to revamp our entire software stack on our webservers and switch from VSS to SVN for source control.  Finally, the opportunity to refactor 8 years of ASP and clean up the codebase was a strong draw.  Our code had accumulated a fair amount of cruft over the life of the company, and a complete rewrite sounded like a fun way to fix that problem.

How We Did It

We lumped this rewrite in with a project to redesign our primary site from a UI perspective and move to a flexible, full-width layout.  Since we were overhauling a lot of the HTML anyway it seemed like a good time to rewrite all of the server side code.  The whole process took about 11 months – the first planning meeting for the project was on 9/1/2010 and the site went live to customers on 6/21/2011.  I led a team of five engineers that wrote 99% of the PHP during that time span (a couple of small projects were done by other engineers).  In general we divided up the code by site section, and as people finished their work on a specific page they just grabbed another one off the list.

We wrote some really basic translation scripts to do some of the grunt work and used online references to help in the beginning.  Overall, the translation portion didn’t take too long — added features and altered functionality took up most of the time (keep in mind the fact that we had a number of marketing goals with this project, as well).  It was a fun project to do, because every day we were making our code easier to read, more maintainable, and faster to develop.

Immediate Benefits

Aside from moving to PHP, we also moved to SVN (as I mentioned above) and our webservers went from running IIS on Windows Server to running Lighttpd on FreeBSD, with memcached between the databases and the webservers.  When you consider all of these changes, we got a huge number of immediate benefits:
  • Cleaner code
  • Much easier and faster code deployments
  • PHP syntax checking as an SVN commit hook
  • PHP standards checking as a commit hook (we use a slightly modified version of the PEAR standards).
  • Adding memcached to the stack improved performance dramatically
  • Much better documentation and a better community around our core technologies
  • Access to all of the open source PHP software that exists
  • Free web tier software
  • Better job postings
  • Improved code performance with the APC Opcode Cache
  • Ability to preload all of our constants into memory and keep them updated via a cronjob
  • Arrays (yeah, it’s silly, but go try to use arrays in ASP and you will see what I mean)
  • Better scalability – we can serve many more requests with our current stack than we could with the windows stack we were running on.
The transition has gone very smoothly so far, and everyone seems really happy with our decision to switch.  I talk to engineers at Wayfair every day who write some ASP and some PHP, and they all agree that working in our PHP environment is significantly easier and more enjoyable.

Next Steps

We still have a lot of code in ASP, anything sessioned on our sites (like your basket and checkout), as well as almost all of our admin forms.  We are already in the process of converting the rest of the storefront code to PHP, but admin will take a lot longer.  Luckily it’s less important for us to switch that code over since it isn’t customer-facing.  Still, the goal is to eventually have no Classic ASP at Wayfair.

We also have a few things we want to implement or try out on the PHP side.  If HipHop starts supporting PHP 5.3 we might try that out, and we still have a lot of checks we want to automate when engineers commit code to SVN to avoid problems.  We have even played with the idea of going the Continuous Integration route with a full blown CI server that runs automated tests before code gets deployed.  We are wary of slowing down the deployment process though, so we still have some thinking to do on that front.

Whew!  Thanks for reading, and if you have had your own experience with large codebase rewrites I’d love to hear about it in the comments!


Popular posts from this blog

14 Day Challenge - Information Diet

Trust, but verify

Business Books for Technical Leaders