BlueMix Virtual Meetup – May 21st

As some of you are aware IBM has been creating a large number of local meetups around BlueMix.  I know that not everyone can attend these for one reason or another so I thought why not try to have a virtual BlueMix Meetup?  Our first virtual meetup will be on May 21st at 10 AM EST.  We will be using Google Hangouts and the recording will be available on YouTube if you can’t make it.  For this first meetup event your presenter will be yours truly and I will be giving an introduction to BlueMix for developers.  That is right, this meetup will be developer focused!  After all, developers are the main users of BlueMix :).  I plan on giving an introduction to the basic topics and concepts every developer will need to know to get their first app deployed on BlueMix, there might even be a demo or two ;).  If you are at all interested in using BlueMix I suggest you join.  Click the image below and respond Yes! on the event page to indicate you are going.  Please feel free to re-share, Tweet, and blog about this event, the more attendees the better the event is for everyone!


Screen Shot 2014-04-22 at 1.10.16 PM

BlueChatter: A Sample App For BlueMix

Yesterday I published a new sample application to our Codename: BlueMix organization on GitHub called BlueChatter.  BlueChatter is a chat / IRC-like application for your browser.  You enter a user name and then you can send messages.  If someone else is also using the app they will instantly see whatever messages you send.  Obviously this is not going to replace Skype or your favorite IRC client, instead it is meant to demonstrate how to scale your application in BlueMix.

BlueChatter uses long polling in order to instantly receive messages as other users send them.  What happens is the client (the browser) sends a request to the server.  The server then holds on to that request until it receives a message.  The client may receive a response immediately or it may be a minute later before it receives a response.  It all depends on when the next message is received.  Once a response is received the client immediately sends another request to the server to wait for the next message.  This is pretty strait forward but what happens when you scale the application in the cloud?  When you scale an application in a PaaS like BlueMix you are essentially starting multiple instances of the same application.  Users will connect to any given instance at random.  So when this is the case how can the architecture BlueChatter is using work?  Users will be sending messages to separate servers!  The answer is to use a shared service, or a common service that all server instances will use.  In the case of BlueChatter we use Redis.  Redis provides a pubsub API that works nicely for our use case.  When one server receives a new message it publishes the message to the Redis service.  All the server instances are also listening to the same topic using the Redis service.  So as soon as one server publishes a message to Redis all other servers will get notified and can then notify their clients of the message!

I have created a short video demonstrating the application.  Feel free to check out the code, I hope you find it useful!

DevOps Services For BlueMix

You may have noticed the JazzHub DevOps service in the BlueMix catalog as you have been poking around.  If you have not played around with it yet I suggest you get to it!

IBM DevOps Services is a place where you can collaborate with others to develop, track, plan and deploy software.

Using the auto-deploy feature in JazzHub you can easily deploy your project to BlueMix on every commit, in other words it allows you to practice continuous integration and delivery.  It takes about 1 minute to enable once you have your project created.  Below is a video demonstrating how to use JazzHub to deploy your app to the cloud using BlueMix.  As I mention in this video, it is very important that you have a manifest.yml file for your project.  More information about how to construct and use manifests can be found in the Cloud Foundry documentation.

Heartbleed And PaaSes

I am sure everyone has heard about the Heartbleed bug by now.  If you haven’t, where have you been?  Even the Today show was talking about it :)

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The bug is pretty nasty if you are using OpenSSL to secure your site, and there is large portion of the internet that is, including this blog.  My blog was created from a prebuilt Bitnami WordPress EC2 image.  I chose the image because it was quick and easy to get up and running.  The downside is that I need to maintain it.  (Yes I could use but I liked the flexibility of hosting it myself.)  This is the second time in a couple years I have had to deal with a security vulnerability.  While coming up with the right steps to fix the vulnerabilities just involved a little bit of Googling and 4 hours total of my life, I am always concerned about whether I am taking the right steps to fix everything.  I am not an admin or an IT guy.  Yes I can fumble my way around and figure out most things, but it is not my speciality.

This got me thinking, if my blog was deployed to a PaaS I wouldn’t have to worry about this.  This is one of the selling points to using a PaaS solution like BlueMix.  Everything below your application code is taken care of for you, this includes the hardware, networking, OS, and yes the libraries used by the OS (like OpenSSL).  While the Heartbleed bug would have still been a concern for you because of the nature of the security threat, it would not be your responsibility to fix it, it is IBMs and IBM has a lot of people who know exactly how to fix it correctly :)  You as the application developer may need to inform your users that their sensitive information may have been compromised, but that is something you can easily handle.

Will I move my blog to a PaaS solution like BlueMix?  I have thought about it and people have deployed WordPress to BlueMix.  I just need to look into it a little more and set aside some time :)

P.S. BlueMix was NOT effected by the Heartbleed bug as it is not using OpenSSL.

You Choose The Runtime On BlueMix!!!

As most of you know, you can deploy an app that uses virtually any runtime to BlueMix.  As long as there is a buildpack for the runtime, your app will run on BlueMix.  Of course knowing the ins and outs of using the buildpack for your runtime can be a little tricky sometimes.  That is why over the past few weeks I have been working on implementing a ToDo application in Java, Node, Sinatra, Python, and PHP.  This idea was inspired by which is dedicated to showing developers how to use various client side JavaScript frameworks by implementing the same ToDo app.  The ToDo apps we have built have the same goal, but instead each app uses the same client side framework (JQuery and Backbone) while implementing the server side code in various languages.  As I am sure you can tell we just took the client side framework right from the Backbone example.  The source code should be open sourced soon, but until then here is a quick demo.

If you can, watch the video in 720p for best quality.

Diving Into PHP and BlueMix

This past week I have been working on writing an app in PHP and getting it deployed on BlueMix.  The first thing I did before I started was take a look at the buildpacks that were available.  Last week I made the mistake of picking one without trying it first and wasted a huge amount of time trying to figure out what was wrong with my app when it ended up being a problem with the buildpack.  This time I decided I would put in a little effort into seeing which ones worked first.  Browsing the Cloud Foundry community builpacks page I found three PHP buildpacks to choose from.  I created a very simple PHP app and tried all three, they all worked with the simple app so I just had to pick one.  I ended up choosing this one for a couple of reasons.

  1. It seemed to be documented fairly well.
  2. It said it had support for different extensions build in, like Mongo DB, and Redis.
  3. It had been tested against and provided a good number of samples that worked with the buildpack.

I decide it was best to first setup a local dev environment to do some local development before deploying to BlueMix.  I had never written a single line of PHP before so I was starting from scratch.  After reading about the best way to setup a PHP dev environment, I eventually decided to use MAMP.  I liked it because it contained an isolated PHP, Apache, and MySQL environment.  By using MAMP I didn’t have to go through all the installation and configuration of PHP and Apache on my local machine.  Just download MAMP, start it up, and your Apache and PHP environment is ready to go.  I didn’t really care about the MySQL part since I wasn’t planning on using it but it was part of the package.

My goal was to build a REST API in PHP and I had decided on using the Slim framework.  The only real reason I chose Slim is because the APIs were simple and easy to understand (I am a big fan of simplicity).  The documentation pointed out that I would need to configure some Apache rewrite rules to make things work.  The ones from the documentation worked perfectly for me locally.  My next question was how do I do this with the PHP buildpack in BlueMix?  I eventually came across this GitHub issue which pointed me in the right direction and to a sample.  Perfect!  Just create a httpd-php.conf file put the same rewrite rules that worked for me locally in that file and I am golden!  Not so fast :(  The rewrite rules I used locally were not working for me on BlueMix.

After trying various combinations of rewrite rules and not getting anywhere I decided I needed to figure out what the rewriten URLs actually looked like on the Apache server.  After Googling for a bit I figured out you could enable logging for the Apache rewrite module and it will tell you what it was doing.  Of course there were various ways of accomplishing this.  I decided to figure out what worked in my local dev environment first.  This took a while, but I eventually figured out that adding

to /Applications/MAMP/conf/apache/httpd.conf would enable the rewrite logging and print it to the logs/rewrite.log file.  Great, worked locally!  Now to the cloud and the buildpack, how do I do the same thing there?  After more trial and error there I figured out I could add

to my httpd-php.conf file and that would print out the rewrite logging to the sysout.log file on BlueMix.  I could finally see how Apache was rewriting my URLs!

After enabling that logging it took me a little while but I eventually came up with the right set of rewrite rules that were somewhat working.  I had the Apache server on BlueMix serving up my static HTML, JS, and CSS resources, but my Slim PHP app still was not working.  I kept getting 400s, and 404s all the time no matter what I did.  I eventually took a step back and went back and looked at the sample pointed to in the issue I mentioned above.  I realized that I did not have this line in my httpd-php.conf file.

This ended up being key.  I don’t completely understand everything about why I need this proxy rule, but the buildpack is using FastCGI and all the PHP code needs to be using that as well.  Basically this Apache proxy rule says to pass everything through FastCGI.  I did not want everything to go through FastCGI so I modified it slightly to only pass PHP files through.

At this point I was finally able to get my Slim PHP app to work.  My REST endpoints were returning data!  It still bothers me that the rewrite rules that I have locally are different than the ones I need to use on BlueMix but at least it worked now.  (I still don’t understand why the local Apache rewrite rules don’t work with Apache on BlueMix, but that is another problem for another day.)

Next I wanted to be able to use Mongo DB from my PHP code.  I found this article about how to install the Mongo PHP extension into MAMP, which was really helpful.  This allowed me to write my code and test it locally.  After I had everything working locally I wanted to try it on BlueMix, but how do I get the Mongo extension installed in the buildpack on BlueMix.  I remembered reading in the documentation for the buildpack that it had support for Mongo, but how do I enable it?  After a little trial and error I eventually figured out that I needed to use the PHP_EXTENSIONS property in the options.json file.  I created my options.json file and added this to it

By default the buildpack include bz2, zlib, curl, and mcrypt, so I kept those there and then just added mongo.  When I pushed the app to BlueMix it now installed the Mongo DB PHP extension!

This all happened over the course of a work week.  It was frustrating at times and I am sure that part of it was because I am a novice at PHP, again this was my first time ever writing any PHP.  However most of my time was not spent trying to understand PHP, it was trying to figure out how to configure Apache.  This was quite frustrating to me because the whole point of using a PaaS like BlueMix was to not have to deal with all this configuration stuff, but I found myself spending 90% of my time figuring out how to configure things properly and only 10% coding.  IMO this isn’t so much a failure of the PaaS as it is the way the PHP runtime is tied to the container (web server).  So much of what I needed to do to get my app to work correctly was tied to making changes in the web server.  I have written the same app in Java, Node, Python, and Ruby, PHP was the only language where I had this experience.

Anyways if you are a PHP developer I hope the information above is useful and saves you time.  The code I wrote should be open sourced sometime in the beginning of April.

Using BlueMix To Find Qualified Candidates

My colleague David Barnes has created a new video demonstrating BlueMix.  In this video he walks through a scenario where an HR departments wants to build an app to help find candidates for a job using LinkedIn.  Check it out below.  If you want to know some of the nitty gritty details about how deploying an app works check out my blog post on how to deploy a Java app to BlueMix.

Pushing A Java App To BlueMix

In my previous video I took you through a tour of the BlueMix UI, but we didn’t actually go through pushing an application up to BlueMix and seeing the results.  Well no fear, I have created videos for that as well.  I actually split this up into two videos.  In the first one we create a Java app in the BlueMix UI, download the code for the app, make some changes, and then push it back to BlueMix.  In part two we learn about scaling our Java app and how to take advantage of the services in BlueMix to deal with the elasticity of the cloud.  Below are the videos AND the code I wrote during the demonstration.

Part 1

Here is the code.


Part 2

Here is the code we wrote in part 2.

Remeber for this code to compile you need to add the Jedis jar and the Apache Commons Pool jar (you must download version 1.6) to WebContent/WEB-INF/libs directory and modify the path element of the build.xml to include these jars.


Deploying A Python App To BlueMix

For the past 2 days I have been trying to get a very simple Python app deployed and running on BlueMix.  This proved to be a little challenging because there were no clear cut instructions or simple examples to go by (that I could find at first), and I had never written any Python before.  After spending most of the day yesterday talking to some expert IBMers I eventually got a simple hello world Python app using Flask deployed to BlueMix.  Later on, I came across this project on GitHub which covers everything I am about to tell you and would have saved me two days of aggravation, but that is software development for you.  Here are the three “gotchas” that I ran into over the past few days, hope this saves others some time.

  1. You need a requirements.txt file in the root of your project.  The requirements.txt file should list all the dependencies that need to be installed in order to run your application.  When your application is staged the platform will read this file and install all the dependencies before trying to run your application.  The details around the requirements.txt file can be found in the pip user guide.  It is useful to know that you can also use local dependencies as long as they are in the root of your application.  When you have local dependencies in the root of your application they will be uploaded, along with your application code, to BlueMix.  In your requirements.txt file you would reference them by path, for example, ./mylocaldep.  This points the platform to the dependency code you uploaded as opposed to looking for it in a repository.
  2. Use the right buildpack!  This one had me baffled for a while.  Actually it would have been easy to figure out if BlueMix was logging a little more information (this feature will be coming soon to BlueMix).  When looking at the community buildpacks I selected the Heroku one (
    figuring it would be fairly stable.  DON’T DO IT!!!  Apparently this buildpack does not work on BlueMix or Cloud Foundry.  I eventually tried this one, and that worked.  I don’t know what the difference is between it and the Heroku one, it appears to be a fork.  (Later on I noticed the simple Python project I liked to on GitHub above also pointed out that the Heroku buildpack was not working.)
  3. Make sure you get the port from the environment variable VCAP_APP_PORT and use it when starting your HTTP server.  If you don’t your app will fail to start.  This might be specific to the library I was using (Flask) although I imagine it would apply to any Python HTTP server.