Composing Serverless Apps With IBM Cloud Functions

at serverlessconf , ibm announced a new key capability (as an ibm research preview) of ibm cloud functions . with the new tool composer , apps can be created that contain multiple cloud functions. these apps coordinate the invocations of actions and the data flow. compared to the previously available action sequences , the new functionality is much more flexible.

cloud functions are typically rather simple and focussed on specific tasks, which is why people often refer to cloud functions as microservices. cloud-native applications usually have many microservices. while the implementation of the microservices is rather simple, the key challenge is the orchestration layer above the microservices. that’s why frameworks like kubernetes, with additions like istio, have become very popular. with the new composer tool, developers can now build apps that leverage multiple cloud functions and that require more complex, coordinated flows for end-to-end solutions.

composer is an ibm cloud functions programming model for composing individual functions into larger applications. compositions, informally named apps, run in the cloud using automatically managed compute and memory resources. composer is an extension of the function-as-a-service computing model, and enables stateful computation, control flow, and rich patterns of data flow. composer has two parts. the first is a library for describing compositions, programmatically. the library is currently available in node.js. the second is a runtime that executes the composition.

let’s take a look at a simple example. with the new composer functionality, different functions can be invoked depending on the result of a previous function. the screenshot shows the new tool ‘fsh’ (functional programming shell), which displays the flow graphically.

the apps (compositions) can be defined via json, which is executed by a runtime component. in addition to ‘if’, many other composition methods are supported.

what i really like is the second approach to defining apps, which i think is more natural for developers. while you can define apps as json configurations, you can also write node.js code that uses the composer sdk, and you can use constructs as variables, try/catch statements, loops, data forwarding, and much more.

the node.js code is compiled into json, which is executed by the runtime. in order to handle the state of the apps, developers need to provision redis datastores (see the documentation for details). the managed runtime, together with the datastore, allows hosting and running serverless apps.

to find out more, check out the quick start guide .