Bluemix Compute Options: Cloud Foundry + OpenWhisk

5 min read

Bluemix Compute Options: Cloud Foundry + OpenWhisk

The IBM Bluemix cloud platform has the flexibility and power of a number of compute delivery options. Whether you need to tune an application with specific OS access requirements, provide a stateless API that services high request volumes and delivers special services, or implement microservices that quickly and automatically adapt to use, Bluemix application Compute flexibly drives the end user experiences you and your customers want.


Two of these Computes, Cloud Foundry and OpenWhisk, are low-time-to-provision models that a developer can use to power their application’s workload and reduce time to market.

Before we dive into the differences between the two, let’s discuss the full range of Bluemix Compute options, what Cloud Foundry and OpenWhisk are and what problems they can solve — particularly from a mobile perspective.


Cloud Foundry:

  • Bluemix is based on Cloud Foundry’s open technology for delivering cloud applications easily.

  • Is a cloud computing Platform-as-a-Service (PaaS), which supports the full cloud lifecycle, from initial development, through all testing stages, to deployment.

  • Has a CLI program called cf which is the primary tool to interact with Bluemix (And Bluemix expands this function with a web GUI).

  • Has Organizations that contain Spaces which you can think of as workspaces. Different spaces typically correspond to different lifecycle stages for an application.

  • Has Services and Applications. A Cloud Foundry service usually performs a particular function (like a database service); an application usually has services (and service keys) bound to it.


  • Is a IBM Cloud developed distributed event-driven compute model or Function-as-a-Service (FaaS).

  • Has an automatically scaling serverless architecture, which executes application logic on events.

  • Has a command-line program called wsk, which can be used to run your code snippets and actions.

  • Introduces the concepts of TriggersActions, and Rules.

    • Triggers are a class of events emitted by event sources.

    • Actions encapsulate the actual code to be executed, which support multiple language bindings including Node.js, Swift, and arbitrary binary programs encapsulated in Docker Containers. Actions invoke any part of an open ecosystem including existing Bluemix services for analytics, data, cognitive, or any other 3rd party service.

    • Rules are an association between a trigger and an action.

Cloud Foundry vs. OpenWhisk

So what is the difference between Cloud Foundry and OpenWhisk, and are there cases where it makes sense to use one versus the other, or even both?

Platform-as-a-Service means you are running a server-process. You’ll have a long-running process, which listens to events and executes your logic once an event happens. At all other times, the process is idle, still requiring CPU cycles and memory to actually listen for events.

In a Function-as-a-Service, the platform takes the burden of “listening for events.” Once an event happens, your code is instantiated and executed. That code is shut down afterward, thus not requiring any further resources.

Cloud Foundry may be the right choice if you:

  • Are a backend & application developer

  • Have experience creating and connecting services together

  • Need longer-running actions or functionality that may not be possible using OpenWhisk

OpenWhisk may be better suited for the task if you:

  • Are an application developer

  • Desire an autoscaling, rapid development environment

  • Want to focus on developing an application or “simple function”

But why not use both?

Cloud Foundry + OpenWhisk

In some cases, it may be beneficial to use Cloud Foundry OpenWhisk together.

You may choose both Compute models if there is short-running application logic that is more advantageous with the OpenWhisk model and longer-running logic that makes more sense with Cloud Foundry. Let’s take a look at a real-world example that highlights both Compute models.

BluePic is a sample built by the IBM Swift team, which demonstrates Cloud Foundry and OpenWhisk working together:


BluePic is an iOS application and a Kitura backend written completely in Swift. The sample is a photo sharing application that shows you how to connect your mobile application with Kitura, Bluemix services, and OpenWhisk actions.

BluePic Architecture

BluePic Architecture

BluePic uses the Cloud Foundry buildpack for Swift to push the Kitura backend to Bluemix. The Kitura-based server acts as a communication layer, uploads data to Cloudant and image binaries to Object Storage, and much more. After the backend is deployed using Cloud Foundry, an OpenWhisk component analyzes images and extracts text tags based on the contents of each image. In addition, an OpenWhisk action invokes a sequence gathering weather data like temperature and current condition (e.g. sunny, cloudy, etc.) from where the images were uploaded from.

Next Steps

So we’ve shown you the power of Cloud Foundry, the power of OpenWhisk, and the capability of using them together. Both Compute models have strengths in different circumstances, and together they are even more powerful.

Now that you have a high-level view of what Cloud Foundry and OpenWhisk are, the easiest way to learn how to use them is to practice! Here are a few resources to get started:

Good luck, have fun, and enjoy the Bluemix Cloud platform!

Sign up for Bluemix. It’s free!

Be the first to hear about news, product updates, and innovation from IBM Cloud