Over a million developers have joined DZone.

How Docker Containers Relate to Cloud Foundry in IBM Bluemix

DZone's Guide to

How Docker Containers Relate to Cloud Foundry in IBM Bluemix

· Cloud Zone ·
Free Resource

Insight into the right steps to take for migrating workloads to public cloud and successfully reducing cost as a result. Read the Guide.

IBM Bluemix is based on Cloud Foundry, an open PaaS (platform as a service) to provide customers a choice of clouds. This PaaS model allows developers to focus almost exclusively on writing code since all infrastructure including the application servers are provided. This enables developers to build applications rapidly in local IDEs and push the applications to the cloud. This ease of use however comes at the expense of having less control over the infrastructure (obviously) which is desirable in certain scenarios.

At the end of last year IBM launched IBM Containers Beta. The IBM containers are based on the popular Docker containers. On a high level containers are similar to virtual machines (VMs) and have similar advantages like the fast creation of new instances. As my colleague Carl Osipov describes in his blog there is a significant difference though: "Instead of virtualizing the hardware (as the case with traditional virtual machines) containers virtualize the operating system" and are more lightweight than VMs.

In difference to the Cloud Foundry model developers don't only have to provide the applications, but essentially also the application servers/runtimes which are both included in the containers. This comes with the benefit that you can port your applications much better. Everyone in our business has probably heard the response of developers when something doesn't work: "but it works on my machine". This is exactly the issue containers address. As the name alludes to, containers can be 'shipped' very easily between different environments. For example developers can run these containers locally, other developers or quality engineers can run them on other on-premises environments, or the same containers can be run in the cloud.

The downside of the container approach is a little more work for developers who also need to take care about building these container images. Fortunately there are many images already available provided by the community which can be used or extended. As part of Bluemix IBM provides images for Liberty and Node.

So with these different approaches the question is when to use what. The containers are basically a new option between Softlayer's IaaS (infrastructure as a service) and Cloud Foundry's PaaS as described in this deck.

Here is how the redbook describes the pros and cons of the different approaches.

"Containers seemed like an optimal approach that would allow us more flexibility of what we were deploying, with the cost of a small increase in management overhead." and "Existing applications are more likely to adopt the container model; new applications are more likely to build from scratch, using the power of the Cloud Foundry model."

Carl Osipov adds that containers have advantages "especially for I/O heavy workloads like databases and analytics". (Update 02/20 10:45 AM: This statement was done in the context of comparing VMs vs containers, not containers vs CF. See discussion below)

So a typical scenario where someone might want to use containers is for example when you need lots of write access to a database from an application. Or you might want to have your own database engine on your container to use features of databases that don't exist in the cloud (e.g. full text search in relational databases).

In order to get started check out the redbook, Carl's blog and the documentation.

Here is the screenshot of the list of containers deployed onto Bluemix.

TrueSight Cloud Cost Control provides visibility and control over multi-cloud costs including AWS, Azure, Google Cloud, and others.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}