Bluemix OpenWhisk, Cloud Foundry, Containers or Virtual Servers?
By: Ram Vennam
Bluemix OpenWhisk, Cloud Foundry, Containers or Virtual Servers?
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:
IBM Bluemix OpenWhisk (OpenWhisk)
IBM Containers (Docker)
Virtual Servers (OpenStack).
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.
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.
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
sshaccess 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.
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.