LoopBack As A Service Using OpenWhisk

In our previous blog we saw how we can host LoopBack as a multi-tenant micro-service on the cloud. As a quick recap, this would require us to:

Expose REST APIs for CRUD on /models and /datasources resources.

Use the LoopBack NodeJS APIs to create models, datasources and attach them programmatically.

Use the http path property of models to create models in the namespace of the tenant and generate unique URLs for each model (even if the resources they expose have the same name).

How to workaround challenges introduced because there are no LoopBack NodeJS APIs for deleting and updating datasources and models.

Following the steps in the blog would let’s stand-up a single instance of the LoopBack application which is great for demos. It is not yet ready for deploying at scale on the cloud. The previous blog ends with open questions on:

How to scale the application horizontally - Multiple instances of the application running and able to process simultaneous requests for the same API. This will also be needed to avoid single points of failure (min-3 deployments). Introducing multiple instances brings in challenges of deploying models/datasources to all the instances and keeping them in sync.

How to scale the application vertically - When we dynamically create datasources and models in the applications (which has finite resources in terms of RAM and CPU) we will eventually hit a threshold where no more models/datasources can be created. At this point, we need to be able to start deploying to another LoopBack application pool. Note that all horizontal instances of the application run the same models/datasources whereas different (vertical) application pools run different models/datasources. Introducing vertical scaling brings in the challenges of maintaining multiple application pools and logic for choosing which pool would be used for deploying a model/datasource.

When an application instance restarts after a crash or is newly added for horizontal scaling, it needs to create all models/datasources that peer instances have to get functional parity with them. For the time this takes, the instance can not join the load-balancing group of instances.

In real production scenarios, there could be LoopBack applications specific to each application type. This will introduce the need for having a registry for different applications supported and getting the network endpoint to work with each of them.

As one can see, to solve the above problems non-trivial and entails huge deployment and management (of instances, pools, application specific micro services and registry) effort.

This blog explores one particular way to address the challenges highlighted above. When it comes to deploying a LoopBack application (or any app for that matter) on cloud there are different ways to do it:

IaaS - The application is deployed on VMs or bare metal servers of a cloud provider or in private cloud.

The authors of this blog have first-hand experience running production LoopBack applications using PaaS and CaaS. We have also deployed LoopBack apps on VMs for a non-production scenario.

In this blog we are going to explore an altogether different and brand new way of deploying LoopBack apps using the latest cloud technology in town FaaS, “Functions as a Service” or serverless computing.

The serverless cloud computing model is event-driven wherein containers encapsulating the function/code defined by users are run in response to the event, the response returned to the caller and the container is killed and all of this is managed by the cloud provider in a scalable way. Further, the user is billed based on the events/invocations and resources consumed to fulfill the invocation. See this article on serverless computing and serverless architectures for a detailed explanation.

The advantages of such an architecture are:

Effortless scaling which is managed by the cloud provider transparent to the application provider.

Less or no operations cost for the application provider.

Cost-effective because you only pay when you use.

Simplifies the application architecture as we shall see very shortly.

Granular and parallel development and deployment model.

Truly stateless because of the ephemeral nature of the containers.

While there are many cloud vendors who are offering FaaS, in this blog we use the IBM BlueMix FaaS offering called OpenWhisk. Apache OpenWhisk is an open-source server less compute platform and IBM BlueMix hosts and manages OpenWhisk as a service. You can get more details in our About OpenWhisk documentation.

From OpenWhisk documentation:

An OpenWhisk action is a piece of code that performs one specific task. An action can be written in the language of your choice. You provide your action to OpenWhisk either source code or a Docker image. An action performs work when invoked from your code via REST API. Actions can also automatically respond to events from BlueMix and third party services using a trigger.

Let’s take a look at how we can architect the multi-tenant LoopBack micro-service using OpenWhisk actions.

The table below summarizes the different actions and their purpose.

Resource

Method

OpenWhisk Action

Description

/datasources

POST

createDatasource

Creates a cloudant doc in the datasources collection and returns the id.

/datasources /:id/definitions

GET

getModelDefinition

Lists the available model definitions available in the datasource using LoopBack connector.

/datasources /:id /schemas/:model

GET

getModelSchema

Returns the schema for the model using LoopBack connector.

/models

POST

createModel

Creates a cloudant doc in the models collection and returns the id.

/:tenantId /:modelId/:model

POST

createModelInstance

Creates an instance of the model on the datasource using the LoopBack connector.

Note: that this is a representative list of resources and methods and not an exhaustive list.

Let’s explore a couple of these actions in more detail. Once the examples are understood, the other actions can also be defined on similar lines.

Note: The implementation reads the model and datasource information stored by the createModel action in Cloudant. Sharing of datastores across micro-services is considered an anti-pattern and is done here only to simplify the implementation for demonstration purposes. In the real world, the createModelInstance would have its own persistence which could be optimized for low read latency (CQRS).

Install package dependencies

npminstall

Install the LoopBack Cloudant connector

npminstallloopback-connector-cloudant--save

Note: We use Cloudant connector to create a record in a collection specified in the datasource.

We can see that the model doc got created in Cloudant accounts collection.

A key thing to observe in the implementation of createModelInstance OpenWhisk action is that it is completely generic and can work for any LoopBack connector. In the example above we installed Cloudant connector (step 1) and it worked for Cloudant. We can use the same code base and install another connector (ex. Redis) and create an OpenWhisk action which can create records in Redis.

Note: An OpenWhisk action was created for Redis using the above mentioned approached and invoked as follows:

This confirms that different OpenWhisk actions can be created for different applications using the same common LoopBack application code and the specific connector and exposed at different base URLs as shown in the table below.

With a little tweak to the createModel action, we can return the base URL corresponding to the application for which the model is created (Cloudant/Redis/any other). This gives a neat and simple way of scaling the service to support multiple applications.

We now have a recipe for standing up a LoopBack service using OpenWhisk which scales in all dimensions:

Horizontal - Since we are not explicitly standing up a server, we need not worry about multiple instances.

Vertical - Since we are not explicitly standing up a server, we need not worry about how many models can be deployed in it.

Multiple Apps - We can scale by creating an OpenWhisk action per application using the same LoopBack app code but the specific connector bundled in.

The architectural simplicity is also clear because there is no need to manage instances of servers, keep them in sync, deploying and managing multiple server pools, need for placement logic for selecting the pool, and maintaining servers specific to applications. Since the execution model is request based, there is no need to worry about the deletes/updates to models deployed in servers and nor is there a need to worry about restoring models in a server after restart or to a newly added instance.

The other benefit of this approach is the possibility of parallel development of the actions. Each action can be developed, tested and deployed by a different person in the team due to inherent decoupling in the deployment and execution paradigm.

Finally, as one can see, there is no/little operations cost because there are no servers to be deployed, managed and scaled. The platform takes care of it all. And since the billing is based on usage, there is no capital cost incurred either.

The one thing which could be a potential concern is the latency of serving requests. We have not yet measured the response times and compared approaches (good topic for a future post) but what we observed with the naked eye was pretty good.

All in all FaaS/serverless/OpenWhisk seems to be very promising and definitely worth an evaluation not just for LoopBack as a service but cloud-based services in general.

Note: The astute reader will notice the minimal input validation and no security implemented in the code for the actions shared in the post. These are omitted to simplify the blog but are needed for a production implementation.