Community

Bluemix OpenWhisk, Cloud Foundry, Containers or Virtual Servers?

Share this post:

As of May 23rd IBM Bluemix Container Service now provides a native Kubernetes operations experience while removing the burden of maintaining master nodes. Kubernetes itself is based on the Docker engine for managing software images and instantiating containers. Get the details.

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

 

span>

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

What are Cloud Foundry apps?

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

 

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.

Add Comment
14 Comments

Leave a Reply

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


KiranShashi

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

Reply

Rich Naszcyniec

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.

Reply

    Ram Vennam

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

    Reply

GauravMehrotra

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 ?

Reply

Adnan

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

Reply

Fred

Thanks. Fred

Reply

Jeff Chi

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

Reply

    Dan Kehn

    Yes, thanks for the correction.

    Reply

csantanapr

URl has 2015 in the path instead of 2016

Reply

    RalphEarle

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

    Reply
More Community stories

IBM Cloud Foundry Enterprise Environment (Experimental)

We're delighted to be working on a new offering in the IBM Cloud Foundry compute, called the Cloud Foundry Enterprise Environment. This offering provides a version of Cloud Foundry deployed into a customer's IBM Cloud account in any of our worldwide regions.

Continue reading

IBM Cloud App ID Technical White Paper – Now Available

We are happy to share that we have just published a technical white paper about building user authentication into your apps using IBM Cloud App ID. If you are deciding how to secure your applications with user authentication, this white paper provides a guide to the App ID service, and how to leverage it's capabilities.

Continue reading

Is it bad to be boring? Why it’s good news for developers that Kubernetes is going mainstream

Like most developers, the team at The New Builders are always susceptible to the shiniest new technologies. There’s never a shortage of hot solutions on the horizon, and all of them promise a better way of solving both technical challenges and business problems.

Continue reading