A new developer journey, Make apps smarter with serverless, is now available. It shows you how to enhance enterprise applications using serverless technology, enabling you to transform and improve traditional legacy systems.

What is serverless?

Serverless is centered around responding to events. The programming model is based on four concepts:
  • Packages
  • Triggers
  • Actions
  • Rules
Packages provide event feeds, triggers associated with those feeds fire when an event occurs, and you can map actions — or functions — to triggers using rules. OpenWhisk flow There are a few serverless solutions on the market today, such as Google Functions and Amazon Lambda. Acme Freight uses Apache OpenWhisk, which IBM created and open sourced through the Apache Foundation. IBM also added a native API experience to OpenWhisk on Bluemix that made integrating recommendations into our Acme Freight application easy and straightforward.

Scenario

Acme Freight is a fictional logistics company. It’s a sophisticated business that is able to respond to weather fluctuations by rerouting shipping paths or choosing a different delivery truck to complete the shipment. They can reroute because of the intelligent recommendations application built into their architecture that uses the serverless event-based model. With Acme Freight, we chose to implement just the recommendations aspect using serverless, but there are companies that have moved their entire web architecture to serverless. The benefits are very easy to see and many organizations are embracing serverless. Serverless is also great for things beyond web applications, such as data processing, IoT, chatbots, and batch jobs.

Serverless and responsive

Acme Freight uses a serverless approach to respond to weather events. An action is triggered by a storm event; retailers affected by the weather event are identified; their stock and shipments are retrieved; recommendations are made based on the storm, stock and shipments. While the guts of the code are abstracted out of this flow into their own function blocks, you can see the process in the following code from the recommend action: `actions/recommend.js`

    return new Promise((resolve, reject) => {
      async.waterfall([

        // delete existing recommendations for this demo
        function(callback) {
          self.cleanup(
            args['services.cloudant.url'],
            args['services.cloudant.database'],
            args.demoGuid,
            callback);
        },

        // retrieve list of retailers
        function(callback) {
          self.getRetailers(args['services.controller.url'],
            args.demoGuid, callback);
        },

        // identify retailers affected by the weather event
        function(retailers, callback) {
          self.filterRetailers(retailers, args.event, callback);
        },

        // retrieve their stock and make new shipments
        function(retailers, callback) {
          self.recommend(retailers, callback);
        },

        // persist the recommendations
        function(recommendations, callback) {
          self.persist(
            args['services.cloudant.url'],
            args['services.cloudant.database'],
            args.demoGuid,
            recommendations,
            callback);
        }
      ], (err, result) => {
        if (err) {
          reject({ ok: false });
        }
        else {
          resolve({
            demoGuid: args.demoGuid,
            event: args.event,
            recommendations: result,
          });
        }
      });
    });

The code above has comments inline to describe the flow of the action:

  1. delete existing recommendations for this demo
  2. retrieve list of retailers
  3. identify retailers affected by the weather event
  4. retrieve their stock and make new shipments
  5. persist the recommendations
The last code block has an if/else function that either rejects the promise if there is an error or else it resolves the promise with an object of recommendation information.

OpenWhisk Native APIs

If you look at the actions in the repo, you’ll see the functional code is broken into logical separations of concern. With these actions deployed to Bluemix, we are able to take advantage of the new native API experience for OpenWhisk and make the recommendations interface available to our application using APIs. This is a new feature of Bluemix and is rolling out across a number of services and applications. Through the API pane of the OpenWhisk web UI, we can manage our API layer on top of our OpenWhisk functions. You can:
  • Provide a clear interface to our recommendations functionality.
  • Simplify authorization details to just an API key from the calling code.
  • Add API management, such as rate limiting, tokenization and more.
Making our OpenWhisk interface available as an API keeps the seams between the Acme Freight application and the recommendations engine cleanly defined. Separating the recommendations logic from the Acme Freight application cuts our costs, removes deployment dependencies and frees up our developers to focus on the core application needs. To learn more and deploy the Acme Freight Recommendations app yourself, visit the Make Apps Smarter with Serverless journey.

Additional resources

Thanks to Daniel Krook for the graphic above and his input on this article.

Join The Discussion

Your email address will not be published. Required fields are marked *