IBM Bluemix is a very flexible platform that allows you to pick the right infrastructure for deploying your applications, but how do you know what is right for you? Bluemix offers four ways for you to run your code. These environments, which are referred to as compute options, are:
  1. IBM Bluemix OpenWhisk (OpenWhisk)
  2. Instant Runtimes (Cloud Foundry)
  3. IBM Containers (Docker)
  4. Virtual Servers (OpenStack).
compute options With these multiple compute options you can run a variety of both new and old applications in the cloud, in one platform. These can be back-end processing applications or modern cloud-ready web applications.  Lets start off by talking about what it means to be a cloud-ready application. There are many ways to define cloud readiness, but one standard is the 12 factor app. The 12 factor app is a software methodology for building modern, scalable applications. Essentially, they are best practices that you should follow to take the most advantage of the cloud, especially in a Platform as a Service (PaaS). For a simpler explanation, check out 12-Factor Apps in Plain English by Will Koffel.  Bluemix understands that not all applications follow the 12-factor methodology, and that refactoring non-cloud-ready applications to follow these principles might not be worth the investment. With the Bluemix platform, these applications can still run in the cloud and can take advantage of all the additional services the cloud has to offer. Sign up for IBM Bluemix Depending on the cloud readiness of your application, you will decide between the four compute options in Bluemix.

What is IBM Bluemix OpenWhisk?

IBM Bluemix OpenWhisk is an event-driven compute platform, which executes application logic in milliseconds in response to events or direct invocations from web/mobile apps or other endpoints. Events can be provided from Bluemix services or external sources. Developers only need to focus on writing the application logic (“actions”), which are executed on demand — the rate of executing actions always matches the event rate, resulting in inherent scaling & resiliency and optimal utilization.

An action is a piece of code written in Javascript, Swift (more languages going forward) or custom binaries embedded in a docker container. A developer creates actions in OpenWhisk and the associated code is instantly deployed and executed whenever a trigger fires. The more triggers fire, the more actions get invoked. If no trigger fires, no action code is running, so no cost is generated. Since your code is not running as a traditional application your actions need to be stateless and short lived (this is a great time to start following the 12 factor app ). As your actions execute on demand, there is no starting or stopping of an application or thoughts of blue/green deploys.  OpenWhisk is the right choice when you want to focus on code and core logic and never have to worry about if your app is online (or not).

Some examples of when to consider OpenWhisk are:
  • You want to easily build and run a microservice and not have to worry about any infrastructure concerns. i.e. just write code and upload it
  • Logic that¬†experiences spikes in usage for a finite amount of time and don’t want to over-provision servers i.e. a weather app during a hurricane
  • You need a mobile backend that scales with low latency for a global user base i.e. you only care about code/logic and don’t want to deal with scaling, high availability, geo-zones etc
  • You need to respond to real time streaming of data that varies in velocity and volume i.e. data cleaning, log analysis, etc

If you just want to focus on running code, implementing the strangler pattern, without worrying about application or server administration or lifecycle, this is a great place to start! If you want to build a traditional web application, explore Instant Runtimes.

What are Instant Runtimes?

Runtimes on Bluemix are based on Cloud Foundry. Cloud Foundry is an open source cloud Platform as a Service¬†on which developers can build, deploy, run, and scale applications. It’s great for web applications (Java EE, Node.js, PHP, Ruby on Rails, etc..) With this infrastructure, you develop and manage only your application, and Bluemix takes care of the management and maintenance of the infrastructure that powers those apps.¬† Cloud Foundry is the right choice if you want to develop an application where:
  • You want to focus on your application and let the platform handle the rest (runtime, scaling, networking, operating system).
  • You are willing to follow some simple rules. (the 12 factor app)
  • Your application only needs to listen on standard http/https ports.
  • You do not need ssh access and you do not need to issue commands to the environment.
One of the most important 12 factor rules that you need to follow when developing Cloud Foundry applications is avoiding writing to the file system. (See VI. Processes Execute the app as one or more stateless processes.) When your application instance gets restarted, updated, scaled, or recreated, the file system it sits on changes. You get a new isolated chunk of disk each time. Your application will need to use a database or blob store service to save any files or session information it needs to persist. This environment is focused towards the developers. There are many starter applications to get you up and running in seconds. The Bluemix Catalog offers around a hundred services for you to quickly consume and build your application.

If you are writing a new application, you will likely want to start here. If in the future you decide that you need more control into the environment (portable), you can move to IBM Containers.

What are IBM Containers?

IBM Containers are Docker-based containers. Think of Docker Containers as a lightweight virtual machine complete with everything your application needs: code, runtime, and any dependencies. 

To get started with Docker, you have to first build a Docker image. An image is a read-only template that will contain your application and its dependencies. Start with a base image, which you can choose from the Docker Hub, which is a public registry, or choose the Liberty and Node.js images that IBM provides in your private registry. From there, you layer your changes on top of it to customize your own image. One or more Containers are then created from these images. This is where your application runs. Docker Containers are guaranteed to run the same way regardless of what environment you deploy them in.  Docker Containers are designed to be immutable instances created from images. To update a container, you need to create another container from an updated image. For this reason, as with Cloud Foundry applications, applications that store data to the disk is considered an anti-pattern. Use an external database service to store any information. This allows you to maintain consistent behavior with your application whether you are running it on your local developer laptop, test hardware, Bluemix cloud, or any Docker-supported operating system.  If you are looking to create a complete portable environment and have it be able to run in Bluemix or another supporting cloud environment, or if local infrastructure is important for you, then choose IBM Containers.

What are IBM Virtual Servers?

Most developers are familiar with virtual servers. IBM Virtual Servers gives you a virtual machine (VM) with an operating system pre-installed. You can run applications inside these virtual servers. You can configure your VM infrastructure to auto-scale dynamically and to load-balance automatically within a group. This infrastructure supports OpenStack project deployments, and scales both horizontally and vertically.

Choose this option if you just want to ssh into a VM and manage most of the environment yourself. Other than the base operating system, you are responsible for installing everything your application needs. This gives you the most control and does not require you to develop your application in a certain way. This can be ideal for running batch processes or running legacy applications. Sign up for IBM Bluemix and start building

Stay tuned…

I hope this post provided an introduction to the Bluemix compute options. Stay tuned for more articles, where we will explore different use cases for each of these compute options.

If you have any questions, check out the IBM Bluemix documentation, post a question below as a comment, or feel free to ask your question directly.

14 comments on"Bluemix OpenWhisk, Instant Runtimes, Containers or Virtual Servers?"

  1. KiranShashi August 06, 2015

    Nice article – but how does one get started on CF ?
    S,

  2. Rich Naszcyniec August 13, 2015

    I like to call this IBM split container disorder. You can try to spin it as choice, but the reality appears to be that IBM isn’t going to commit to a container strategy.

    • Rich, I find that our customers need the different levels of abstraction depending on the development phase and requirements of the application.

  3. GauravMehrotra October 05, 2015

    Thanks Ram for explaining well the three options .This certainly helps gain better understanding .

    Have few questions though , If I go for container , will I be able to install additional softwares or applications as needed for a complete solution to be bundled under a container . Could these containers be deployed on any os , Can I deploy apache spark as well on these containers ?

  4. Thanks for the informative article .. anything regarding Openshift 3?

  5. Thanks. Fred

  6. Shall the “Virtual Machine” on this page be updated to the official name “Virtual Servers”?

  7. csantanapr July 26, 2016

    URl has 2015 in the path instead of 2016

    • RalphEarle July 27, 2016

      @csantana23, if you are referring to the URI for the blog post, that is because it was originally published in 2015, and we don’t like to change the link once it’s out there.

Join The Discussion

Your email address will not be published. Required fields are marked *