PaaS (platform as a service) cloud platforms are becoming more and more predominant. I don’t have a perfect crystal ball, but I will bet 80 percent of Web apps will run on PaaS within five years.
Hosting an application at a PaaS provider offers pros and cons. Instead of discussing them, I decided to migrate a running app to a PaaS provider. For the test I used IBM BlueMix Cloud Foundry environment base.
First, the choice of the Application. As we are doing more and more projects around GLPI at Sogeti Basel (Switzerland), I thought this application would be a good option. It’s an open source LAMP stack for IT asset management and configuration management. It also offers tracking and ticketing capabilities. If you want to know more, you can check it out here.
And I didn’t start from a fresh install. Instead, I took an already running and customized environment. I picked a PHP application, also because PHP is supposed to be easier.
Getting Started with PaaS
My initial approach was very basic:
- Create an app on BlueMix
- Via cf push command, upload the full code on BlueMix
- Try to access the app
Result: Doesn’t work. Blank page and a 500 http code.
Not too surprising, as I didn’t set-up the database on BlueMix. But just to check the difference in behavior, I shutdown my local DB and ran the code locally. In that case I got a clear DB connection error, so let’s see if the error handling is different on a PaaS provider than with a local LAMP.
So my second step was to check the log of my application on BlueMix to see the issue and try to debug. Surprise, by default there are not that many logs. The only thing I could see, is one line in the log file, telling me that the server answered back a code 500 on the request. That’s it!
To get more logs, I needed to tweak the buildpack. For that you just need to create a folder /.bp-config/ under your application folder and then add your specific configuration file. Sadly, even after doing that I didn’t get a lot of log. So Plan B was to add a logging instruction at the beginning of each file and class file in order to know where the issue was.
When the bug was found, I just needed to tweak again the buildpack and added some required extension that were not included by default, and Shazam, the application worked perfectly fine.
PaaS Cloud Lessons Learned
Some lessons learned from the workload migration:
- Cloud Foundry push command doesn’t allow you to only push one file, so debugging requires a lot of time as you have to push the full app each time you make a change. So for the next one, I will probably setup a local Vagrant with Cloud Foundry on it to do the debug locally instead of pushing directly to the cloud.
- It would be better if the app you have to migrate has actually unit test script in place; that would facilitate the debugging.
- I needed around six hours to do the migration, and I spent a lot of time pushing the app, so the effort is acceptable as most of the code running on LAMP server works fine directly on the PaaS environment.
Now the big question is: Is it worth the effort to migrate an application on a PaaS environment?
For a pure run question I actually don’t have an answer yet. I am going to do a lot of testing and stress the app to see the behavior and also the cost of running it in PaaS mode. There is a theoretical advantage to go with PaaS, like no need to monitor servers and services, but let’s see the reality during heavy usage.
In terms of process, mixing Vagrant and BlueMix (or another PaaS provider) for the different phases of the application development lifecycle will bring a huge advantage. Would you like to try it out? Don’t forget to share your experiences after the test!
Flavien Boucher is responsible for all the Sogeti's global collaboration offerings with IBM technologies. Sogeti is a subsidiary of Capgemini. Read more Capgemini blogs here.
