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.

IBM Cloud Technical Offering Manager

More stories
September 12, 2018

Transitioning Your Service Mesh From IBM Cloud Kubernetes Service Ingress to Istio Ingress

Istio is ready for production! This tutorial will provide steps for migrating a service mesh from Kubernetes Ingress resources to Istio's ingress gateway in an IBM Cloud Kubernetes Service environment.

Continue reading

September 11, 2018

IBM Key Protect Now Available in U.S. East Region on IBM Public Cloud

We're excited to announce that we are adding to our U.S. geographical coverage, and IBM’s key management service, IBM Key Protect, is now available in the U.S. East region based out of Washington D.C.

Continue reading

August 10, 2018

Recapping IBM Think Digital – IBM Cloud for VMware Solutions

Did you miss IBM's Think Digital event with executives from IBM and VMware? We're giving you the highlights from the first-of-a-kind live digital event.

Continue reading