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.
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.