How to Use Docker in Cloud Foundry with Colin Humphreys

I am proud to call Colin Humphreys, Founder of CloudCredo a friend of mine. I worked with him while building AppFog and now he has started his own company that does Cloud Foundry consulting and services, including bridging the gaps between Cloud Foundry and Docker.

Because of Colin’s work, a couple weeks ago the Cloud Foundry team announced an official project to make Docker a first-class citizen within Cloud Foundry. This week we talk to Colin about the future PaaS and the intersections of Cloud Foundry and Docker.

Colin is hilarious and if you listen to the whole podcast, I assure you there are a few nuggets you will quite enjoy.

Colin Humphreys

Listen to the Podcast

You can also listen to it on:

Show Notes

What does CloudCredo do?

We help people get value from Cloud Foundry and BOSH. We do managed services, but we are trying to build tools to automate the manual processes involved.

How does Cloud Foundry v2 handle state-full services?

Right now the state problem is a challenging one. Cloud Foundry v2 takes out the database services into an abstract service binding.

You are the major bridge builder between Docker and Cloud Foundry. How did you get in that position?

I am very noisy and exceptionally tall. I turn up at conferences and shout at people. I have a habit of doing whatever I think is right, not really caring about the consequences. People with more fear look at Docker and Cloud Foundry and think they are competitive with each other. I don’t have that fear and I see a huge amount of value in the combination of the two. That’s why I created a prototype called Decker which does just that.

Can you talk to us about Decker?

Docker addresses the micro world of single hosts well, and Cloud Foundry’s Elastic Runtime addresses the macro world of distributed orchestration well – what we needed was the combination of the two. Thus the idea for Decker was born. You can watch a video demo of Decker to see it in action.

Tell us about Warden Linux Container manager and what the design principles behind it are, why Cloud Foundry uses it instead of Docker right now?

It has been a matter of timing. Originally, the Cloud Foundry people tried to use LXC for its containers, but ran into troubles. Since Docker used LXC at the time as well, they decided not to use Docker and built their own library called Warden.

A week ago, it was announced that Decker is now officially in the Cloud Foundry project, what does that mean?

Now Warden is being merged with libcontainer which will enable easier and deep Docker integration with Cloud Foundry. This means you will be able to push Docker containers into your Cloud Foundry application.

When does it make sense to use Cloud Foundry over Docker?

If you are creating stateless 12-factor applications, it is a no-brainer to take those containers, push them into Cloud Foundry, and use Cloud Foundry to scale them and work with them because it is so much easier than trying to run your own distributed system with containers. If you have state in those containers, it becomes far more challenging.

What do you think about the pure Docker Micro-PaaS’es like Deis, Flynn and Dokku?

Flynn is interesting because it is trying to tackle the state-full problem, so I am very interested in the things they are trying to achieve, but it is still early days for Flynn and it is not that mature yet. Deis and Dokku are great projects, and they currently have a more mature ability to host Docker containers than Cloud Foundry, but Cloud Foundry is going to be the way you will want to go to orchestrate those containers.

What do you think about OpenShift?

My take is that OpenShift has an extraneous F in its name. My background is RedHat, but OpenShift is an awful PaaS. I say this because I have tried to put it into production for a large charity client. Cloud Foundry worked and OpenShift didn’t, and it is that straight forward. The scaling potential inside of OpenShift is awful.

Those are harsh words! Don’t you think OpenShift will improve over time like Open Stack did? OpenShift adopted Docker long before Cloud Foundry after all.

I think OpenShift will either go away or change and the focus will go towards Atomic and Geard. RedHat is a great company and great people, but OpenShift is just a poor orchestrator compared to Diego or Mesos.

Why not just use Pivotal’s services instead of CloudCredo?

Pivotal has run.pivotal.io which is a trial environment. But you would not run a production application with it. We’re able to customize your Cloud Foundry experience by adding build-packs and database services.

What do you think the future is for Cloud Foundry?

Great to see big companies come behind Cloud Foundry. It reduces the risk and no one company will go rogue and do crazy things with it. The reduction of that risk might come at the cost of velocity, so innovation might happen slower now within Cloud Foundry. Stability will increase, but the ability to change will decrease.

What do you think of the state of Platform-as-a-Service market as a service provide on the front lines?

Heroku blazed the trail, but only provides a product for developers… not the operations team. No SLA or customizations. The big challenge in PaaS is around state-full PaaS.

What projects are exciting to you right now?

  1. Diego (based on etcd from CoreOS) is the new orchestration scheduler inside of Cloud Foundry.
  2. Flynn is really interesting because it is trying to tackle the state-full problem.
  3. Kubernites an open source implementation of container cluster management.
  4. Flocker a data volume manager and multi-host Docker cluster management tool.
  5. OSv a special purpose minimal operating system built to run inside of containers.

What’s next for CloudCredo?

We took the DEA from Cloud Foundry and Docker to produce Decker. Now we are taking Cloud Foundry and Docker, merging them together on the client-side and produced a tool called YOU HAVE TO WATCH THE VIDEO TO FIND OUT THE SECRET PROJECT NAME that lets you run a micro Cloud Foundry environment on you laptop.

Did you like what you read?

Stay on the bleeding edge with the weekly CenturyLink Labs newsletter featuring Docker tutorials, news, jobs, and much more.

  • Grant

    In response to Colin stating that OpenShift's scaling is a joke I would like to point out the following:

    Colin states "Pivotal has run.pivotal.io which is a trial environment." and that you wouldn't really run production applications on it. Red Hat has publicly stated their public OpenShift service, which is production ready, has over 1.5 million applications deployed on it. I am not sure where one draws the connection between 1.5 million applications running today versus a trail at run.pivotal.com as OpenShift not being able to scale. Seems just the opposite to me when looking at the numbers. What large scale pure* CF environment has every achieved scale to this magnitude?

    Seems more like FUD to me than information based on actual fact.

    *pure meaning not one of the fragmented forks of the CF environment like BlueMix, ActiveState etc. Thinking about it, I have never heard of any CF environment, be it a fork or not, every achieving the scale OpenShift has.

    • DD

      Not sure what you mean by fragmented forks – Bluemix isn't a forked CF.

      • Grant

        Oh cool. I didn't know that about BlueMix. So if I pull down the CF github repo I have everything that is BlueMix minus the fancy logos they added?

      • DD

        No, Bluemix is CF+IBM add-ons (fancy UI, DB2, etc…). But you will get the same core CF features – no fork.

    • I think Colin's summary of OpenShift was a little harsh, but it was based on his real-world evaluation. Here's what he ended up doing with Cloud Foundry…

      http://blog.cloudfoundry.org/2013/04/30/uk-charity-raises-record-donations-powered-by-cloud-foundry/
      "10,000 concurrent call centre operators, and peaks of 500 donations completing per second". Not bad.