Ten Attributes of Serverless Computing Platforms – InApps Technology 2022

Serverless Computing or Functions as a Service (FaaS) is gaining momentum. Amazon is fueling the innovation by expanding Lambda to edge devices and content distribution network. IBM, Microsoft, and Google have their own FaaS offerings in the public cloud. There are over half-a-dozen open source serverless projects that are getting the attention of developers. This year, expect to see new platforms emerging in this segment.

With all the excitement and hype around serverless, it’s important to understand what really defines the platform. Here is an attempt to highlight the key attributes of serverless computing platforms. For customers, it acts as a checklist for choosing the right offering while helping platform vendors in optimizing their product.

1. Polyglot Platform

The biggest benefit of FaaS is choosing the best of the breed languages and runtimes optimized for specific tasks. Each function could be written in a different language yet contributing to the same application. Though JavaScript seems to be the lowest common denominator for Serverless, supporting other languages is important.

AWS Lambda started with JavaScript but eventually added support for Python, Java, and C#. Azure Functions supports all popular languages including BASH scripting language. With Docker integration, some providers will enable BYOI (Bring Your Own Image) with support for legacy code and binaries. IBM OpenWhisk is an example of such FaaS. Polyglot is an important aspect of FaaS that customers should factor.

2. Support For Sync and Async Invocation

Functions deployed in FaaS may be synchronous or asynchronous. A certain class of applications demands immediate response while others may prefer asynchronous invocation. For example, the data generated by sensors needs to be processed and analyzed immediately while images uploaded to object storage may be converted to thumbnails by a batch process.

Running an application in FaaS is similar to flying a drone.

Irrespective of the style of the function, FaaS platforms should support both synchronous and asynchronous invocation. When a function is triggered asynchronously, the platform returns an identifier that can be used to poll the status. IBM OpenWhisk supports this pattern in which every function is treated as asynchronous unless the invocation includes a blocking request.

It’s also important to understand the number of concurrent invocations supported by the platform. Azure Functions

3. API Gateway Integration

The value of an API Gateway integrated with the serverless platform cannot be emphasized enough. Though the functions deployed in serverless environments are typically triggered by external event sources such as stream processors and databases, it is the API Gateway that lights up the functions. It adds the logical routes for mapping the standard HTTP verbs to respective functions.

For example, there could be four different functions responsible for the CRUD operations on a database which get mapped to GET, PUT, POST, DELETE verbs. This immediately brings a familiar API facade to developers. The consumers of the API may not even realize that they are dealing with a serverless platform.

The adoption of AWS Lambda skyrocketed only after the introduction of Amazon API Gateway. The lethal combination resulted in a robust platform that enabled many interesting use cases.

Customers should carefully assess if the serverless platform has good integration with an API Gateway.

4. Developer Productivity

Most of the IDEs that are used by developers today are not designed for modern DevOps processes. The support for source code control systems, build automation, CI/CD, and A/B testing came through plugins and third party add-ons. It will take a long time for traditional IDE vendors to support FaaS. Recently, Microsoft announced the support for Azure Functions in Visual Studio. AWS has also shipped a plugin for Visual Studio to enable development and deployment of C# functions in Lambda. But for other languages and frameworks, there are not many choices available.

5. Support for DevOps and Tooling

There is a misconception that FaaS magically reduces the need for DevOps and tooling. Serverless platforms should have tight integration with source code control systems and build automation tools. They should support automated and repeatable deployment patterns. Amazon is again one of the first to introduce Serverless Application Model (SAM) for declaring an entire stack including AWS Lambda resources. These templates can be integrated with git for consistent versioning. Microsoft also supports deploying Azure Functions through ARM. Google has a long way to go before it can include Cloud Functions in Deployment Manager.

IDE support and integration with existing DevOps pipeline is a major factor to consider while choosing a FaaS platform.

Serverless, Inc, is building tools for automating the deployment of FaaS applications across multiple platforms. Currently, in beta, the product aims to become the de facto framework for developing FaaS-based microservices.

6. Responsiveness and Performance

Responsiveness plays a critical role in designing microservices-based applications on FaaS. Poorly designed platforms will introduce startup latency and delay the invocation process, which would become obvious to end users. Lightweight, interpreted languages such as JavaScript and Python respond faster than Java and .NET. If there is a considerable gap between each invocation, the delay becomes noticeable. One trick to keep the function “warm” is to invoke it in a loop. But this is not an ideal solution for many customers.

The usage of Docker containers by some of the emerging FaaS platforms is a cause of concern. Each request to a function will result in the creation of a new container which will introduce significant delay. Though containers are faster when compared to VMs, they are still not meant to be the units of deployment for FaaS. We need a better execution environment than containers to implement FaaS.

Customers must benchmark the turnaround window for each language and runtime before deploying their microservices solution.

7. Logging and Monitoring

Running an application in FaaS is similar to flying a drone or an unmanned aircraft. The only way both can be controlled is through a powerful dashboard that shows the current state. FaaS platforms should have extensive support for logging and monitoring. Everything that is written to stdout and stderr should be logged to separate streams. This is essential to understanding the current health of an application and debugging individual functions. The monitoring tools should provide insights into the successful invocations, unsuccessful invocations, invocation time, response time, memory consumption and CPU utilization for each function.

Though FaaS is positioned as a NoOps platform, the logging and monitoring capabilities are heavily utilized by the DevOps teams.

8. REST Endpoints and Automation

Like most of the cloud-based delivery models, FaaS must be fully automated. This is only possible when the platform supports API for performing all the operations done through the portal or the CLI. This feature enables developers and operators to efficiently automate the workflow of deploying and managing the microservices.

For example, CI/CD systems can utilize the REST API of a FaaS to automatically push the latest version. This scenario can be extended further to automate the implementation of an A/B testing environment in FaaS.

9. Support Long-running Jobs and Batch Processing

Mature serverless platforms have inbuilt support for long-running, scheduled jobs. A function that is deployed in FaaS may be periodically invoked to perform at ETL job. FaaS platforms may support the same notion of cron to schedule jobs.

This capability extends further to support batch processing. For example, a large collection of high-resolution images uploaded to an object storage bucket may be processed at one go by a function. These scenarios are different from the asynchronous invocation patterns.

10. Extensibility and Integration

The real value of a serverless platform lies in the broad integration and extensibility. For example, the platform must support a variety of security schemes including oAuth and custom LDAP-based authentication. It should support HTTPS endpoints out of the box for secure transport.

The platform should have enough hooks for easy integration with a variety of event sources. Proprietary platforms such as AWS Lambda will only support integration with its services such as S3, Kinesis, and DynamoDB. Open source platforms should make it easy for database vendors and other platform companies to support FaaS. OpenWhisk’s Feed is an example of such integration.

Support for custom environment variables is another example of extensibility. With this, customers can pass parameters other than those included in the request. This simple feature turns FaaS into a powerful execution environment.

IBM is a sponsor of InApps Technology.

Feature image via Pixabay.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.