SOGETI UK BLOG

Secured Online Cloud Computing Concept with Business Man

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!

badge_infrastructurebadge_cloud

 

 

Flavien Boucher AUTHOR:
Flavien Boucher has 9 years experience in the field of Information Systems, Networks and Telecommunications. Flavien is responsible for all the collaboration offerings with IBM technologies for Sogeti, globally. He started his career with France Telecom (French major telecom supplier) before joining Sogeti in 2003.

Posted in: Application Lifecycle Management, Apps, Cloud, Digital strategy, Infrastructure, IT strategy, project management, Transformation      
Comments: 0
Tags: , , , , , , , , , ,

 

Bigger is better, would probably remind you about a lot of good or bad jokes. During my two last meetings in 2015, I had two interesting discussions, one was about offshore and the other one about Docker.

Modern web network and internet telecommunication technology, big data storage and cloud computing computer service business concept: server room interior in datacenter in blue light

I am not going to spend time on the offshore topic, I already wrote about that few months ago, so I will just complement the previous topic by saying that Bigger is better when it comes to offshore. The initial offset or effort of leveraging offshore is usually hard to explain or show case when you are only working with one or couple of resources offshore, so the bigger you go the better and the faster you will see return on investment. The questions are always:  where is the starting point and is there a limit? There isn’t a unique preformatted answer. It would depend on the type of services, the level of complexity, maturity, industrialization and normalization of your IT.

On the Docker discussion. It all started by a comparison between Virtual Machine and Docker. We went through all the pros and cons of each technology  and it’s approach, spent some time on the security of each solution and the eternal discussion on the shared host kernel between Dockers. You never want technology for its own sake, you want it to deliver value for your own good. All people being part of the discussion had done some testing with Docker, meaning that we at least created a Docker file, and run a piece of our code to see the complexity. The test outcome depended on everyone’s OS and scripting skills.  Some of us had to update their code a bit to make it work. Nothing dramatic.

We all came to the conclusion that Docker is adding a complexity layer compare to a virtual machine approach, and this complexity will be for the deployment, development and build.

Also, We all agree that using Docker for only a small project with few nodes doesn’t make sense, as it will have a lot of complexity for not a lot of benefit, so basically coming to the conclusion that bigger is better.

But let’s park it there. This comment was also true for Virtual machine, probably 10 years ago. And isn’t it the purpose of a cloud provider to be bigger for you in order to bring the volume benefit and manage your infra (Docker, Virtual Machine) with complex, efficient and scalable tools? So yes, bigger is better with Docker if you do it on your own, but if you leverage PaaS provider with their technology and people with correct knowledge, big or small should not make any difference. It is all about bringing value.

If any of your processes using Docker can improve and bring value, go for it. If  it doesn’t, may be you are already very well organized and industrialized, so don’t bother. Bigger value is always better.

Flavien Boucher AUTHOR:
Flavien Boucher has 9 years experience in the field of Information Systems, Networks and Telecommunications. Flavien is responsible for all the collaboration offerings with IBM technologies for Sogeti, globally. He started his career with France Telecom (French major telecom supplier) before joining Sogeti in 2003.

Posted in: Cloud, Infrastructure, IT strategy, Research, Security, Uncategorized, Virtualisation      
Comments: 0
Tags: , , , , , , , ,

 

tomnod1Most of you, to not say everybody, are aware of the Malaysian flight missing.  Probably like a lot of people you are wondering how come we can lose a flight when today NSA is tracking everything about everybody, and that you can follow real time anybody having a cell phone. I wish I could answer that question and solve the mystery, but no. And I am not going to discuss all the crazy theories populating the web.

Some companies have joined the rescue effort. One of them, TomNod, proposes to share satellite pictures of the area (90 000 square kilometers) and give a specific piece to each of the volunteers (2 000 square kilometers). Each user can tag potential traces on each picture and therefore help check this huge area. More than 200 000 people join this effort, an example of Crowdsourcing.

tomnod2Many example of crowdsourcing exist around the world, but only few concern companies and innovation driving business for them. So, why do we see a successful example of crowdsourcing for volunteers without a business-driven initiative and not so much from companies with a business-driven one? I thought this world was driven by money!!!

For sure, the technology is available, if not fully mature, so that’s not the reason.

There are cultural, societal and organizational barriers in companies that don’t help leverage the crowdsourcing. Of course, you can find many authors and researcher giving advice on the way to overcome the barriers and make it happen. If it was simple, everybody would do it. One of the barriers  that seems to be the most difficult is the business model of Crowdsourcing.

Let’s assume a big company decided to use external crowdsourcing to define its next product. Somebody, very smart or very lucky, comes up with an out of the box idea that the company believes in and starts producing. Once on the market the product is a big success, and the company is making billions. How much of the billions should go to the smart, lucky inventor? Was it originally really his idea? What will the company say to the internal researcher that contributed to this idea, who has been on the payroll for the past 3 years? What is the part of the marketing team in this success? What is the part of the supplier producing the product at an attractive price? How can the company be fair with everybody and give credit to everybody (assuming the company’s business mindset is fair !).

If anybody has a good and working example of crowdsourcing business models, please share.

Flavien Boucher AUTHOR:
Flavien Boucher has 9 years experience in the field of Information Systems, Networks and Telecommunications. Flavien is responsible for all the collaboration offerings with IBM technologies for Sogeti, globally. He started his career with France Telecom (French major telecom supplier) before joining Sogeti in 2003.

Posted in: Crowdsourcing, Innovation, Open Innovation, SogetiLabs      
Comments: 0
Tags: , , , , , , , , ,