What is Serverless — Part 5: Reference Architectures for Common Types of Serverless Applications

This is the last part of a 5-part blog series. See part 1, part 2, Part 3, and Part 4.

At their core, Serverless functions are about running pure business logic or ‘functions’ inside a container. These functions could be anything that makes sense to a business application. Some common examples include:

• Payment Processing
• Alerting — sending an alert to a Security Ops Console
• Stream Processing — enriching a message with customer information
• Doing a credit check
• Submitting an insurance claim

Common use cases primed for Serverless functions include key industries, such as:

1. Power & Utilities — where streaming data is intercepted and analyzed to perform demand forecasting, equipment reliability management, etc.
2. Oil and Natural Gas Industry — Serverless is employed to perform log analytics to provide Single Views of Oil Wells
3. Advertising — serving mobile & online users with instant & relevant offers based on their browsing history, location and buyer characteristics.
4. Financial Services — such as banking and trading applications — where various facets of user data are populated in real-time in the customer portal.
5. Healthcare — for example, papulation of health management data

Let us examine some design patterns for common industry use cases to see how Serverless can help you accelerate innovation and software delivery for key event-driven applications. We’ll be using the open-source Fission serverless framework for illustrating these architectures, as it is the most flexible and is not locked to a specific cloud provider or related services, so that your apps can run anywhere. You can swap Fission with any serverless/cloud offering of your choice, too!

Reference Architecture #1: Internet of Things (IoT)

Typically in IoT — from industrial internet to wearables, to smart cars — a set of autonomous physical devices such as sensors, actuators, smart appliances and wearables, collect various types of data and communicate with an application running in the datacenter (either cloud/on-premises) using an IP protocol. Commonly, a lot of the data is aggregated using a gateway and then sent into a platform that can analyze all these variables for various business insights (performance, trends, triggered events, and more.)

The overall flow in an IoT application can be orchestrated using Fissions:

• Data is aggregated using a Gateway and sent into to various message queues running on a cluster of Kafka servers running on Kubernetes managed pods
• Fission functions are invoked based on the overall pipeline flow:
• For a given file placed in a message queue, the contents of the file are passed into a Fission function that first normalizes it, extracts variables of interest and then sends the output into a NoSQL database or a file system.
• The second function will run in response to the normalized file being placed in the NoSQL database. It will read the contents of the file, perform computations as needed (based on the use case) and then invoke microservices that perform functionality such as sending the data into a Data Lake or a Data Mart for further analysis.
• Fission functions can be written for any kind of processing actions in the event stream. The FaaS scales up or down as needed in response to data volumes.

Serverless Applications — Reference Architecture for IoT Use Cases

Reference Architecture #2: Financial Services (Payments Processing, Risk Calculations, etc.)

In the financial services industry, critical tasks such as payments processing, compliance checks and risk metrics can be calculated in real time using a Fission-based Serverless architecture.

• The overall flow in a financial application can be orchestrated using Fission: Developer deploys Fission functions as a shared capability across several applications that are the frontend to a variety of payment processing gateways. These applications handle user authentication, registration & collection of payment related data. These systems also interface on the backend with a variety of databases that record transaction data.
• Fission functions are created to parse a given input datastream that has the following variables: user’s credit card data, location of the transaction, any other demographic information, etc.

1. The first function can call a fraud detection API and based on the results of the check persist the data into an in-memory datagrid.
2. The second set of functions is invoked when the check has either passed or failed. If the check has passed, the function approves the payment and sends the user a confirmation.
3. If the payment is suspected to be fraudulent, another function is called which alerts a Fraud detection system at the backend.

Serverless Applications — Reference Architecture for Financial Services Use Cases

ReferenceArchitecture #3: Web Applications Augmentation

The vast majority of enterprise applications are three-tier web applications. These do everything from onboarding new customers, to interfacing with various back-office functions performing a range of business tasks as well as technology tasks (such as backups, reporting, alerting, data enrichment.)

An emerging pattern is for Serverless Fission functions to handle these tasks without impacting the complicated development and deployment methodology of a monolithic n-tier application.

The overall flow in web applications augmentation can be orchestrated using Fission:

• Business users continue to interface with the (legacy) application, but can take advantage of the augmented functionality provided by Fission functions
• Functions are created for a range of compute and data processing tasks as depicted
• The main application triggers these functions as it opportunistically needs to do
• Dedicated functions perform the appropriate logic as depicted, and if needed “report back: to the application.

This could be seen as a way to gradually refactor or decompose/enhance existing legacy applications into microservices, or easily adding additional functionality that is not dependent on the development and release processes of the “mother ship”.

Serverless Applications — Reference Architecture for Web Apps Use Cases

Reference Architecture #4: Modernizing Legacy Systems

Legacy systems such as mainframes, N-tier applications are prevalent and deeply rooted in industries such as Banking, Insurance, Retail, and more. Oftentimes it is not possible to simply rip and replace these systems (due to complexity, business dependencies, time it would take to re-architect, as well as the fact that often these legacy systems still perform quite well and have mature usage patterns.) To ensure interoperability with modern interfaces, such as web services and mobile applications, Fission functions can provide standards-based API wrappers around these systems.

For instance:

• Requests are sent in to the API Gateway which performs basic transformation and invokes Fission functions as needed based on the endpoint being requested
• Functions take in the input data (e.g. JSON) and convert it to a format the end system can process and then calls the (legacy) business system
• Once the system responds, functions can take the response and convert it into a format the source system understands and then invoke the API Gateway with the appropriate response.

Serverless Applications — Reference Architecture for Modernizing Legacy Applications

Reference Architecture #5: Machine Learning and Deep Learning with Apache Spark

Across-industries, we see applications increasingly infusing business processes and big data with Machine Learning (ML) capabilities. From fraud detection, customer behavior and pipeline analysis, virtual reality, conversational interfaces, chatbots, consumption trends, video/facial recognition, and more — it seems that ML (and AI) is everywhere.

For most companies, ML and Predictive Analytics initiatives have typically been silo’d to a specific project within the organization. To realize the real value of ML, it’s advantageous for the data, learnings, algorithms and models to be shared across applications. Fission, in conjunction with technologies such as Apache Spark, enables you to provide the data of stream processing and trend predictions to be consumed by a variety of end users/applications.

The overall flow in Machine Learning applications can be orchestrated using Fission and Apache Spark:

• Data from business operations is ingested in real-time into a cluster of Kafka-based message queues.
• Spark Streaming is used to ingest this data in micro-batches, typically based on a time window. This data is stored into a data lake for batch analysis as well as sent into a Spark MlLib runtime where different predictive models are stored.
• These models are based on general-purpose ML algorithms that run on Spark. These include both supervised and unsupervised algorithms — e.g. clustering, classification algorithms, etc.
• Once the results of the model are written into a NoSQL database or an in-memory datagrid, Fission functions are triggered.
• These functions do a range of business-critical functionality. For example: updating business analytics dashboards, sending real-time customer offers & alerting customer agents.

Serverless Applications — Reference Architecture for Machine Learning and Big Data Applications

Conclusion

Serverless has immense industry mindshare and is emerging as the hottest trend after Kubernetes. However, as with other transformational technologies, significant concerns remain around lock-in, scalability and ecosystem integration. Open source Serverless solutions help industry verticals solve their pressing business challenges using a highly flexible, state of the art, and standards-based FaaS platform that can run anywhere- on premises and on any public cloud.