IBM joins a number of vendors making a play in the emerging paradigm of serverless computing with a new event-driven programming service for their Bluemix platform called OpenWhisk. The service, designed to execute user code in response to an external event such as some sensor data arriving, was announced at the company’s InterConnect 2016 conference in Las Vegas last month.
InfoQ caught up with Michael M Behrendt, one of the architects for Bluemix regarding the conference, OpenWhisk and Bluemix in general.
InfoQ: Let's jump right in. Can you talk about the compute models on the Bluemix platform, with the event driven application on one side and VMs on other end?
Michael M Behrendt: In Bluemix, we offer a spectrum of compute models. At the lowest level of abstraction are VMs, then Containers and Cloud Foundry apps and finally event-driven apps implemented via OpenWhisk as the highest level of abstraction. It’s important to note tat there are no ‘good’ or ‘bad’ models, as in my mind, each of them has their fit-for-purpose spot. On the spectrum from VMs to event-driven apps, the degree of built-in management increases — which frees the developer from onerous tasks, while the degree of granular control decreases, taking away flexibility to control how processes are executed.
On the next level, the container service in Bluemix allows the developer to provision Docker containers, without having to worry about the underlying OS. The limitation is that the developer is constrained to the OS of the container host.
Cloud Foundry apps represent the next higher level of abstraction. Here, the developer only focuses on the app code as the unit of currency, pushes that into Cloud Foundry, which then takes care of the provisioning of the app instances into containers, the automated configuration of the load balancing layer, health management, etc. Similar to the container service, the developer is limited to the OS used by Cloud Foundry and specific assumptions about the application characteristics.
The final abstraction, OpenWhisk also lets the developer focus on the app code only, but tends to make more assumptions about how the app code is architected. The benefits of OpenWhisk is a very granular execution model, inherent scaling & built-in redundancy. There is no code running in memory if there is no event/request that needs to be served, the more events are coming in, the more actions are executed and given that model, there is no need to worry running multiple processes for redundancy purposes.
InfoQ: Bluemix was based primarily around Cloud Foundry but that model is changing. Does this mean you lose vendor neutrality?
Michael M Behrendt: Not at all. As just mentioned, our objective is to offer users freedom of choice, in a fit-for-purpose fashion. That means, they can use OpenWhisk, Cloud Foundry, Docker containers and VMs as peers, while one doesn't influence the other. However, we deliver consistency across the models for some foundational aspects, such as common ID, a common routing layer and common service consumption.
InfoQ: Can you talk in more technical detail about IBM Bluemix Openwhisk?
Michael M Behrendt: There are essentially three key concepts in OpenWhisk: Triggers, rules and actions. Triggers represent any kind of situation you’d like to react to — for example a new record in a database, a commit in github or a mobile device entering a geofence.
Actions are snippets of code — small or large — which you register with OpenWhisk. Actions can be written in Node, Swift or Java or defined in docker containers containing arbitrary binaries. When an action gets invoked, the corresponding code artifact gets deployed in a container instantaneously, executed and goes away again. The more action invocations are happening, the more action deployments are happening, resulting in inherent scalability. OpenWhisk takes care of managing the artifacts, caching containers intelligently (which is critical for minimizing the deployment time), etc. An action can either be invoked directly via an http call, or by OpenWhisk, as a result of a trigger being associated with an action via a rule. When the trigger fires, the corresponding action gets invoked directly. For implementing the OpenWhisk engine, we’re using Scala, Kafka, Docker and various other technologies and libraries. Scala is used for implementing the core engine of OpenWhisk itself. We're using Kafka for OpenWhisk-internal messaging in the context of executing actions and Docker is used as the underlying container mechanism for executing actions in an isolated fashion.
InfoQ: Is OpenWhisk open source? As a Java developer can you use OpenWhisk?
Michael M Behrendt: Yes, OpenWhisk is entirely open source. It’s available on github under the Apache 2 license, and we already received external pull requests (everyone is welcome to join :-) ). Today we’re supporting Node & Swift natively, with Java support being in the works (Editor Note: Java support for OpenWhisk is now available) and more languages to be supported in the future. Additionally, we support running Docker containers as actions in OpenWhisk, which gives developers a great degree of flexibility, since they can essentially run any binary they can run in a Docker container as an action.
InfoQ: Who is the ideal audience for Bluemix? Is it startups or enterprises?
Michael M Behrendt: Bluemix essentially addresses everyone who wants to build, run & operate both existing workloads and new innovative workloads on the cloud. I’m seeing this is a common requirements across startups and enterprises. Looking at how developers in both places behave, how they work, the technologies they use or want to use — that is all pretty common across the board.
I think enterprises have some specific needs beyond that. For example, for compliance or data location reasons, they need flexibility on where their application resides, which is something we’re addressing via our alternative deployment models — Bluemix dedicated and Bluemix local. Additionally, enterprises usually have a specific need for being able to access their existing applications & data, which is why we included a broad set of integration capabilities into Bluemix.
InfoQ:Let's talk about Docker or containers versus Plaform as a Service (PaaS). Is it mutually exclusive or complementary?
Michael M Behrendt: On the lowest level, containers are very general purpose as they allow you to package essentially whatever you want into then and run them. That applies to a huge set of existing and huge set of software out there, talking all sorts of protocols — both internally, eg when run in a cluster, or externally. In my mind, PaaS builds on top of containers as a core element, but adding additional, pre-integrated functionality such as load balancing and health management around it, with a certain application architecture in mind, such as the 12-factor principles. So as you go from using raw containers to a PaaS, you can get the benefit of all the pre-integrated functionality, so you can focus on your code only, but you’re giving up some of the detailed control knobs. It comes down to a trade-off between built-in management vs. control, and in my mind, there is no universally right or wrong answer, it depends on the type of workload you’re running.
From a technology perspective, i think we as the broader industry need to make sure that spectrum from ‘raw’ containers to PaaS to event-driven computing is as seamless as possible for the user. Today, i think there are still too many technology silos in each of these areas, which makes us as a community less efficient than we could be and also makes choice and adoption for users difficult.
InfoQ: Finally, let's talk a bit about IBM Interconnect? What is the main takeaway from an architect, developer or devops perspective? Also, can you talk about the future of Bluemix?
Michael M Behrendt: In my mind, the main takeaway is that IBM focuses both on bringing existing workloads to the cloud and also on innovations supporting the creation of new applications. For example, the VMware partnership and the Connect announcements are in support of existing workloads, while announcements like OpenWhisk and the work we’re doing with Apple around server-side swift are more focused on new applications.
Going forward, we’ll continue to drive Bluemix in line with the technology strategy we’ve been pursuing over the last years. We’ll continue to focus on offering the broadest and most consistent choice of compute models and data, analytics, integration, cognitive, mobile, etc. services. Additionally, we're delivering that in an open fashion and give customers the options of getting that in three integrated delivery models — public, dedicated and local.
Michael M Behrendt's presentations and other presentations can be downloaded from the Interconnect website.