Serverless Computing on IBM Bluemix Using OpenWhisk
Serverless Computing on IBM Bluemix Using OpenWhisk
Dive into using OpenWhisk in an IBM Bluemix environment, including how to set up a function and use an API gateway to expose your projects.
Join the DZone community and get the full member experience.Join For Free
The emerging trend of cloud native, event driven workloads or applications has made way for the serverless computing platform on Bluemix, called OpenWhisk. OpenWhisk is an open source cloud platform that executes code in response to certain events. Some features of OpenWhisk:
- Multiple programming languages – JS, Python, Java, Swift
- Asynchronous computing – uses pub/sub-message queues
- Action chaining – create sequence of actions, actions can be in any language
- Integrated container support – actions run in Docker containers
Fundamentals of OpenWhisk
Before we dive into OpenWhisk, we need to first understand some key terminologies that OpenWhisk operates on. The following things are important to understand:
Triggers are events emitted by data sources. An example includes changing to database records, new code commits to your repo, and HTTP requests from web/mobile app. The events from the sources are channeled through a trigger.
Rules associate a trigger with an action. Every time a trigger fires, the rule invokes the associated action.
Sequences are chains of actions. You can chain actions and they will be invoked in order. The output of one action becomes the input of the next.
Getting Started With OpenWhisk
The pre-requisite to getting started with OpenWhisk is to get Bluemix credentials. If you don’t have them, you can sign up for a Bluemix trial here. For the rest of the post, I will assume you have access to your Bluemix console.
Log into your Bluemix console and click on the Catalog link available at the top. Then select OpenWhisk from the Apps section. Click “Start Creating” on “Getting Started with IBM OpenWhisk”. You will then be presented with an OpenWhisk workspace.
When your OpenWhisk workspace is launched, you will be taken to the Manage Actions section. Here you will see a list of Actions that you have created. By default, three actions will be listed in the grid. The default packages are simple Hello World examples and a sequence example. Let’s create an action of our own. Click on the “Create Action” button. Provide a name for your action, select a runtime and click Create. I have selected Node.js as the environment.
Once the action is created, we will be taken to a code editor. Here is where you can code your action or function and save. You can invoke the action right from the editor to see if everything works fine. Here is my code editor screenshot:
I have created a simple action and named it “PingAction” – a function that, when pinged, will respond with a message “Ping Ok”. Save the code changes by clicking the “Save” button. We also have the option to invoke our function right within the editor:
At this point, you can go to the “Additional Details” section and find out the URL for your action. The endpoint URL of the action which we created just now will be specified under the “REST API” section. If we use this to ping the action, we will need to pass the authentication headers. Later, we will create an API gateway and put our action behind the gateway.
Creating Triggers and Rules
As mentioned earlier, triggers are nothing but a channel for events that may occur. Events from internal or external sources will be channeled through a trigger. Rules allow our actions to react to events.
In the code editor of the action we created, click “Triggers”. We should see the option to create a new Trigger. Click on the button “Create Trigger”. Next up, we will need to choose a Trigger type. By default, many Bluemix offerings provide their own events which can be connected – for example, Cloudant database, Message Hub, and Mobile Push. We also have a provision to create a custom trigger. There is also a handy Periodic trigger – to invoke the action at periodic intervals.
For the sake of this blog post, I will be selecting the periodic trigger. Click on the Periodic trigger option. In the Connect Tigger screen, provide a name for the trigger, then select the periodic interval, i.e. day and time. I have selected PingAction to be invoked every hour every day. Click the “Create & Connect” button.
Using the Develop Interface
If you navigate back to your OpenWhisk workspace, you will see a Develop menu option on the sidebar. Click on the Develop menu and you will be presented with an interface where you can see all the actions you have created, the triggers, the rules, and sequence (which we will see next) in one place. Here is a screen shot of how my interface looks like:
Notice the rule and trigger we created earlier are also listed here. We can fire the trigger right from this interface and test that our action is invoked.
One of the powerful features of OpenWhisk is sequencing. You can link actions to create a sequence. The output of one action becomes the input of another action in the sequence. Let’s create a sequence for our PingAction. We will make use of a system utility action called Echo, i.e. echoes whatever comes as an input to the action. From your OpenWhisk workspace, select the Develop option. Select your action from the “My Actions” section. Next, click “Link into a Sequence” at the bottom of the screen.
Next, in the “Configure a New Action Sequence”, scroll down till you see the “UTILS” package and select it.
Next, select the “echo” action, which is available in the package. Leave the defaults as-is and click the button “Add to sequence”.
Confirm the new sequence by clicking “This Looks Good”, then provide a name and save the sequence. This was a simple example of how to sequence actions. The possibilities are left to your imagination. This, from my perspective, is one of the strengths of OpenWhisk.
From your OpenWhisk workspace, you will see an option in the side bar named “API”. This option lets you manage your actions through an API gateway. This API gateway (when created) acts as a proxy to actions and provides additional features like HTTP method routing, client id/secrets, rate limiting, and CORS. From the API interface, click “Create Managed API” to create an API gateway. In “Create API for OpenWhisk”, provide an API name and base path for your API. Use Create Operation” to map OpenWhisk actions to HTTP operations.
Set the security and rate limiting according to your needs and click “Save & expose”. This is another great feature of OpenWhisk and Bluemix combined. The availability of the API gateway intrinsically within OpenWhisk is a benefit and allows us, the creators, to create n number of actions and map them to appropriate HTTP operations like GET, PUT, POST, DELETE, etc. The API gateway interface provides a handy API explorer that you can use to test your API endpoints.
With your API gateway, you never expose your actions directly to outside world. The API gateway endpoints are what you can expose to your applications. You can add the appropriate authentication on the API gateway itself and secure your endpoints.
With cloud-native applications becoming more and more prominent, the development paradigm is moving more towards platforms and runtime versus infrastructure. We, as application developers can focus completely on the logic we need to execute compared to server configuration and other infrastructure concerns. Serverless means freeing ourselves from infrastructure concerns and more focus on the business values of our applications.
OpenWhisk, as a serverless platform or service offering on IBM Bluemix, is an interesting offering. What I showcased in this post was a basic "Hello world" kind of application. I believe the potential of OpenWhisk is left to your imagination. The simplicity of creating actions in the language of your choice, sequencing of actions, and API gateway are a big plus of the platform. Do give OpenWhisk a try.
Published at DZone with permission of Lohith Nagaraj , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.