Using IBM Cloud Functions to Create Serverless Microservices

Development

Reading Time: 4 minutes

Modern web developers are increasingly embracing the usage of serverless applications in their architecture. These applications are referred to as “serverless” because they’re hosted and executed on the servers of third-party providers (and not on servers you own). Delegating this responsibility to another cloud provider allows you to worry only about the code that’s run and not maintaining the server running it.

One major serverless service that’s been catching my attention lately is IBM Cloud Functions. The concept of IBM Cloud Functions is very similar to that of Amazon Web Service’s Lambda or Google Functions. IBM Cloud Functions allow developers to write out applications on IBM’s servers and have the execution of those services triggered remotely on demand.

What I want to explore is how IBM Cloud Functions might be the best solution for your tech stack and how Codeship can help you better test serverless parts of your architecture.

Getting Started with IBM Cloud Functions

First and foremost, we need to sign up for IBM Cloud. The service offers a convenient 30-day trial that doesn’t require any credit card info. Once registered, we can start digging into what IBM Cloud Functions has to offer.

From the IBM Cloud dashboard, navigate to the Functions section and select Create Action.

Our application will be based on Node.js, and we’ll name it HelloWorld. Once you have reviewed your settings, you can create the action. You’ll then be navigated to the *Code * screen.

The screen should present something that looks like an interactive online IDE. On this screen, we can manually write out our application or upload an existing one. For our purposes, we’ll be writing our application from scratch.

To start this, replace the existing code on the screen with the following:

function main(params) {
    var name;   
    name = params.name;
    if (name == undefined)
        name = "";
         
    return {
        html: "<b>" + JSON.stringify(params) + "</b>",
        js: "alert('hello " + name + "');"
    };
}

This application is going to be returning two fields: html and js. The html field will hold pure HTML code in the form of a string, and the js field will hold JavaScript in the form of a string. Our function is simply taking in JavaScript responses from them.

Click Save and Invoke to create and run the action. The function will run, and you’ll be presented with a result that looks like:

{
 "html": "<b>{}</b>",
 "js": "alert('hello ');"
}

So what does this mean?

The initial execution of our application was successful, but we still haven’t leveraged it to its full potential. Our application was built to handle cases where name is blank or undefined. However, we want to see how it actually handles live inputs of “real” data.

We can insert this data by clicking Change Action Input. This will present you with a blank piece of JSON code that you can configure to your liking. For our purposes, we want to modify this JSON to include a name parameter:

{
  "name": "Codeship"
}

Click Apply and the Function will run with the newly added parameters. Our output should now look like:

{
  "html": "<b>{\"name\":\"Codeship\"}</b>",
  "js": "alert('hello Codeship');"
}

With a primitive application created, active, and working, we can start to figure out ways to trigger it from other locations.

!Sign up for a free Codeship Account

Remotely Triggering IBM Cloud Functions

While experimenting and refining our IBM Cloud Functions in the IBM Cloud console is productive, the true value of Functions lies in having them triggered remotely. IBM Cloud Functions allows you to call functions from other IBM services with ease.

However, what if we want to call a function from a server we own? We can turn our function trigger into a POST endpoint with a few simple steps.

In the function dashboard, click the Additional Details tab. There, we’ll find a REST API URL that we can POST to and trigger this function. Check the box to enable POST execution of the endpoint, and you’ll be able to copy the URL with a format that looks something like:

https://openwhisk.ng.bluemix.net/api/v1/namespaces/[organization]_[workspace]/actions/HelloWorld

To test this out locally, we can launch our API client of choice (I recommend either Paw or Postman) and attempt to POST to this URL. From here, we can start inserting and executing this function in other applications or even in other serverless functions!

IBM Cloud Functions and Codeship

The advantage of serverless functions is you can save a good chunk of money on cloud hosting costs. The downside of all of this is that your application ecosystem depends on an external service.

This means that even for local development instances of your application, you have to either mock out calls to those services or configure development-enabled versions of those services. Depending on how crucial your external function is, it could be costing you a lot of money to simply develop and test an application locally.

With Codeship, we can utilize IBM Cloud Functions in a variety of ways, but one of the most practical paths would be to use it as an effective staging environment for Codeship Pro. We can configure our projects to trigger or enable execution of IBM Cloud Functions when testing out or deploying our applications.

You can find more information on how to enable IBM Cloud in Codeship’s Documentation Library.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles.
Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.



We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.