Appfog from a Frontend Developer's Perspective
Reading time: ~ 2 minutes
When Robby asked me to migrate our app, heybrainstormr.com, over to AppFog, I was surprised. I am a Frontend Developer here at Planet Argon and am not used to doing things that include the words migrating, database or runtimes. He assured me that if I needed help, a developer would be within shouting distance to assist. Confident in the fact that backup was available, I headed into the fog.
We were contacted by AppFog to take a look their service to see if it would fit into our workflow. Depending on the project, we typically deploy our internal and client applications to Blue Box and/or Heroku. We were interested to see how easy it would be for someone with limited experience with Rails to deploy an app and get everything running. Hence, our experiment with Brainstormr commenced.
Appfog, as stated on their website, “provides the infrastructure web developers need to build apps without worrying about IT tasks or having to wait days to get servers ready for writing code.” This sounded great, but the real test would be how much of this I could handle on my own before I needed to request backup.
Well, I needed help pretty quick. This, however, was not a knock on AppFog, I needed help exporting our current database in preparation for migrating it over to AppFog’s servers. Brainstormr was hosted at Heroku. Carl was nice enough to walk me through the steps of backing up the database and exporting it. Once this was done I was able to follow AppFog’s instructions on installing their command line tool and going through the steps to deploy the app to their servers and import the database.
The only show-stopping issue I ran into was the fact that I needed to specify which version of Ruby was required on the server when it was first deployed. Our app was running 1.9.3 where AppFog’s system defaults to 1.8.7. Due to that issue, I was constantly getting errors and failed deploys. AppFog’s support staff was quick to help and pointed out the error.
Once I specified the correct version of Ruby, all was up and running quickly. Initially we only deployed using the AppFog server address as the URL. We wanted to be able to kick the tires a bit before we made a full switch. Good thing because we had some issues with the app producing a 404. I am not sure if this was linked to the amount of RAM we had allocated or not. To be safe, we upped the memory available for the app. This was easily done with some nifty sliders on the AppFog dashboard. Since the app is pretty small, I have brought the memory allocation back down to see what will happen. So far, all is running smooth.
As soon as I was confident in condition of the app running on AppFog, I put the Heroku app in maintenance mode, did a fresh backup and export of the database. AppFog allows you to interact with your provisioned services using the af tunnel command. This allowed us to tunnel into our server and run commands on it to import our database backup. Once this fresh backup was imported into the AppFog app and I ensured all the recent data was in place, I switched the DNS for heybrainstormr.com to point to the AppFog server and, voilà, heybrainstormr.com is now running on AppFog.
My overall experience with AppFog has been positive. It was fun pretending to be a Backend Developer for a while and AppFog’s documentation and support staff made it much easier. It also gave me a glimpse into the backend process of deploying apps and all the related issues. So if a HTML/CSS/JS jockey like myself can get an app up and running, I am confident most people with limited Rails experience can do the same. Although, it does help to have some seasoned Ruby on Rails veterans available for when you get stuck.
We are still assessing the service and using the Brainstormr project to test the waters. So far we have been impressed. Feel free to take a look at heybrainstormr.com to see how I did.