Workload Migration to a PaaS provider: Is it worth the effort?

Jan 25, 2016

Sogeti Labs

PaaS platforms are becoming more and more predominant, I don’t have a crystal ball so I can’t say the percentage of Web Apps that will run at a PaaS provider in 5 years, but I will bet on 80%.

Hosting an application at a PaaS provider has it’s pros and cons, like most of the other things we do. Instead of discussing them , I decided to migrate a running app to a PaaS provider, and for the test I used IBM BlueMix Cloud Foundry environment base.

Firstly, 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 IT Asset Management and Configuration management, support people oriented, with 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, I took an already running and customized environment. I picked a PHP application, also because PHP is supposed to be easier.

My initial approach was very basic:

1. Create an app on BlueMix
2. Via cf push command, upload the full code on BlueMix
3. 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 run the code locally. In that case I get 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 bug was found, just needed to tweak again the buildpack and add some required extension that were not included by default, and Shazam, the application worked perfectly fine.
Some lessons learnt 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, it would facilitate the debugging.
• I needed around 6 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 for sure 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!

About the author

Sogeti Labs

SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Comments