In a hybrid cloud environment you use both private and public clouds. For example, you might use an on-premises database and storage for your sensitive data. At the same time, you might use a public cloud platform for the other parts of your architecture, like web applications or static files. One challenge is trying to tap into on-premises resources from the public cloud. Serverless computing is a public cloud resource that’s available for developers to use. But in order for serverless functions to interact with on-premises resources, you need a tunnel that connects them.
Even though a public cloud approach is becoming more popular, some solutions still need to use an on-premises or private cloud environment to handle sensitive data or workloads. With an approach like the Secure Gateway service you can quickly set up the communication between your public and private environments, connecting both public and private clouds. This code pattern uses local deployments of CouchDB and Minio as the on-premises resources and uses Docker to easily deploy them.
You can start working with this code pattern, try out how it works, and see how you can implement your own serverless functions with your existing on-premises resources.
This code pattern demonstrates using serverless computing and on-premises resources. Serverless functions can securely access on-premises resources, such as databases and web applications, by using a Secure Gateway tunnel. You can trigger the serverless functions through events or REST APIs.
The sample application in this code pattern demonstrates IBM Cloud Functions (based on Apache OpenWhisk), which interact with on-premises resources by using the Secure Gateway service. The use case in this code pattern demonstrates how you can allow Cloud Functions access to your on-premises resources such as databases and web applications. The code pattern uses a local CouchDB deployment, which is accessed by the serverless functions. It also uses a local Minio open source object storage server, and is served through a local Node.js web application. The local resources are exposed through a Secure Gateway tunnel.
The serverless functions for CouchDB use the existing OpenWhisk Cloudant package, which is possible because Cloudant is based on CouchDB and has similar APIs. Changes in the database trigger an action. In this case, the action output is the document ID. Other actions, such as creating and reading a document, can be invoked through the
wsk command. Another scenario is running actions through REST APIs.
The actions interact with the local Node.js web application that uses object storage. The actions create a bucket and an object from a URL. All the actions use the Secure Gateway tunnel.
The following components are used in this code pattern:
When you use this code pattern, you learn the following skills:
- Allow Cloud Functions to access on-premise resources.
- Create a Secure Gateway tunnel that will be used by serverless functions.
- The user of the application adds a document on the on-premises database.
- A trigger is fired after the document is added to the database.
- An action connected to the trigger is invoked. The action prints the document ID of the added document.
- The user can also interact with the on-premises database through the actions available in the Cloudant package.
- The user can also interact with serverless functions through REST APIs by using the API Gateway that is integrated with Cloud Functions.
- The actions send http requests to the available cloud host that is exposed by the Secure Gateway service.
- All the interaction with the on-premises database goes through a tunnel through the Secure Gateway service, which is also installed in the on-premises environment.
Find detailed technical steps for this code pattern in the README.md file in the GitHub repository.
- Clone the repo.
- Create the Secure Gateway service with IBM Cloud.
- Run CouchDB and Minio with Docker.
- Deploy Cloud Functions.
- Test with database events.
- Test with the REST API to access the on-premises web app.