IBM Cloud Docs
Common use cases

Common use cases

IBM Cloud® Functions is deprecated. Existing Functions entities such as actions, triggers, or sequences will continue to run, but as of 28 December 2023, you can’t create new Functions entities. Existing Functions entities are supported until October 2024. Any Functions entities that still exist on that date will be deleted. For more information, see Deprecation overview.

The execution model that is offered by IBM Cloud® Functions supports various use cases. The following sections include typical examples. For a more detailed discussion of Serverless architecture, example use cases, pros and cons discussion, and implementation best practices, read the excellent Mike Roberts article on Martin Fowler's blog.

Microservices

Despite their benefit, microservice-based solutions remain difficult to build by using mainstream cloud technologies, often requiring control of a complex toolchain, and separate build and operations pipelines. Small and agile teams waste too much time with infrastructural and operational complexities such as fault-tolerance, load balancing, auto scaling, and logging. These teams want a way to develop streamlined, value-added code with programming languages they already know, love, and that are best suited to solve particular problems.

The modular and inherently scalable nature of Cloud Functions makes it ideal for implementing granular pieces of logic in actions. Cloud Functions actions are independent of each other and can be implemented by using various different languages that are supported by Cloud Functions and access various backend systems. Each action can be independently deployed and managed, is scaled independently of other actions. Interconnectivity between actions is provided by Cloud Functions in the form of rules, sequences, and naming conventions. This type of environment bodes well for microservices based applications.

Another important argument in favor of Cloud Functions is the cost of a system in a disaster recovery configuration. Compare microservices with PaaS or CaaS verses using Cloud Functions by assuming that you have 10 microservices, which use containers or Cloud Foundry runtimes. This comparison equates to 10 continuously running and billable processes in a single availability zone, 20 when run across 2 availability zones, and 40 when run across two regions with two zones each. To achieve the same goal with Cloud Functions, you can run them across as many availability zones or regions as you like, without having to pay a penny of incremental costs.

Web apps

Given Cloud Functions’s event-driven nature, it offers several benefits for user-facing applications, whereas the HTTP requests coming from the user’s browser serve as the events. Cloud Functions applications use compute capacity and billed only when they are serving user requests. Idle standby or waiting mode is nonexistent. This feature makes Cloud Functions considerably less expensive when compared to traditional containers or Cloud Foundry applications. Both of those tools have idle time, waiting for inbound user requests, and you are billed for all that “sleeping” time.

Full web application can be built and run with Cloud Functions. Combining serverless APIs with static file hosting for site resources such as HTML, JavaScript, and CSS, means that you can build entirely serverless web applications. The simplicity of operating a hosted Cloud Functions environment is not having to operate anything at all. Since Cloud Functions is hosted on IBM Cloud, it is a great benefit when compared to standing up, and operating a Node.js Express or other traditional server runtime.

IoT

Internet of Things scenarios are often inherently sensor-driven. For example, an action in Cloud Functions might be triggered if a need to react to a sensor that exceeds a specific temperature. IoT interactions are usually stateless with the potential of high load in major spontaneous events such as natural disasters, significant weather storms, or traffic jams. A need is created for an elastic system where normal workload might be small, but needs to scale quickly with predictable response time. So the ability to handle many simultaneous events with no prior warning to the system is desirable. It is difficult to build a system to meet these requirements that use traditional server architectures. As they tend to either be underpowered, and unable to handle peak load in traffic, or be over-provisioned and highly expensive.

It is possible to implement IoT applications that use traditional server architectures. However, usually the combination of different services and data bridges requires high performance and flexible pipelines. Spanning from IoT devices up to cloud storage, and an analytics platform. Often pre-configured bridges lack the programmability to implement and fine-tune a particular solution architecture. Given the variety of pipelines, and the lack of standardization around data fusion in general (IoT in particular), it is common to see environments where the pipeline requires custom data transformation. These custom data transformations apply to format conversion, filtering, or augmentation. Cloud Functions is an excellent tool to implement such a transformation, in a serverless manner, where the custom logic is hosted on a fully managed and elastic cloud platform.

Look at the following sample IoT application that uses Cloud Functions, Node-RED, Cognitive, and other services: Serverless transformation of IoT data-in-motion with Cloud Functions.

API backend

Serverless computing platforms give developers a rapid way to build APIs without servers. Cloud Functions supports automatic generation of REST API for actions.

Additionally, Cloud Functions actions can be connected to an API Management tool of choice. Similar to other use cases, all considerations for scalability, and other Qualities of Services apply.

See the following example that includes a discussion of using Serverless as an API backend.

Mobile back end

Many mobile applications require server-side logic. However, mobile developers usually don’t have experience in managing server-side logic, and would rather focus on the app that is running on the device. This development goal is easily obtained by using Cloud Functions as the server-side back end, and is a good solution. In addition, the built-in support for server-side Swift allows developers to reuse their existing iOS programming skills. Since mobile applications often have unpredictable load patterns, you want to use a Cloud Functions solution like IBM Cloud®. This solution can scale to meet practically any demand in workload without the need to provision resources ahead of time.

Data processing

With the amount of data now available, application development requires the ability to process new data, and potentially react to it. This requirement includes processing both structured database records as well as unstructured documents, images, or videos. Cloud Functions can be configured by system-provided or custom feeds to react to changes in data, and automatically execute actions on the incoming feeds of data. Actions can be programmed to process changes, transform data formats, send and receive messages, invoke other actions, and update various data stores. Supported data stores include SQL based relational databases, in-memory data grids, NoSQL database, files, messaging brokers, and various other systems. Cloud Functions rules and sequences provide flexibility to change the processing pipeline without programming, and is performed through simple configuration updates. The data store options and low administrative maintenance make a Cloud Functions based system highly agile, and easily adaptable to changing requirements.

Cognitive

Cognitive technologies can be effectively combined with Cloud Functions to create powerful applications. For example, Watson Visual Recognition can be used with Cloud Functions to automatically extract useful information from videos without having to watch them. This technology is the “cognitive” extension of the Data Processing use case that was discussed earlier. Another good use for Cloud Functions is to implement Bot function that is combined with cognitive services.

A sample application, Dark vision, is provided and does just that. In this application, the user uploads a video or image by using the Dark Vision web application, which stores it in an IBM Cloudant DB. Once the video is uploaded, Cloud Functions detect the new video by listening to IBM Cloudant changes (trigger). Cloud Functions then triggers the video extractor action. During its execution, the extractor produces frames (images) and stores them in IBM Cloudant. The frames are then processed with Watson Visual Recognition, and the results are stored in the same IBM Cloudant DB. The results can be viewed by using the Dark Vision web application or an iOS application. IBM Cloud Object Storage can be used in addition to IBM Cloudant, where video and image metadata are stored in IBM Cloudant, and the media files are stored in IBM Cloud Object Storage.

Event processing with Kafka or Event Streams

Cloud Functions is ideally to be used in combination with Kafka, IBM® Event Streams for IBM Cloud® (Kafka based), and other messaging systems. The event driven nature of those systems requires an event driven runtime to process messages. The runtime can apply business logic to those messages, which is exactly what Cloud Functions provides, with its feeds, triggers, and actions. Kafka and Event Streams are often used for high and unpredictable workload volumes, and require that consumers of those messages need to be scalable on a moment's notice. This situation is, once again, ideal for Cloud Functions. Cloud Functions has built-in capability to consume messages as well as publish messages that are provided in the Event Streams package.