World of Serverless Computing

Written by Abdul Rehaman|5 min read|

The world's major cloud providers are rushing to offer serverless computing services. Here's everything you need to know about what it means to go serverless and how it could benefit your business.

What is Serverless Computing? 

Pay-per-use services that allow you to run snippets of back-end code for apps and websites without any overhead of managing servers. Serverless computing is a category of computing service that encapsulates two of the main selling points of the as-a-service model-offering computing that is nearly entirely hands-off and where you do only pay for what you use.

Benefits Of Using Serverless Computing

With serverless computing, there is no virtual infrastructure for the user to manage, and the user is only billed for when their code is running, down to the nearest 100 milliseconds. Everything from the scaling to the fault tolerance and redundancy of the underlying infrastructure is taken care of. There are servers involved, of course, it’s just the user doesn’t have to worry about any aspect of looking after them, the cloud service provider handles all of that.

This more granular, pay-per-use approach can be much cheaper for the right kind of workloads. A case in point is the web app that was built to allow football fans to upload themselves singing along with the official Euro 2016 anthem by David Guetta. The agency that created the web app, Parallax, used AWS Lambda for various functions, including generating a custom album artwork based on information shared by the user.

Design Patterns in AWS Lambda Serverless Architecture

Serverless computing services, such as AWS Lambda, are built to run snippets of code that carry out a single short-lived task. These small self-contained blocks of code, known as functions, have no dependencies on any other system and, as such, can be deployed and executed wherever and whenever they are needed. An example of a Lambda function could be code that applies a filter to every image uploaded from a website to Amazon’s S3 storage service.

Unlike a cloud application where the backend code is structured in a more monolithic fashion and may handle several tasks, code running on serverless services like Lambda is more typical of that found in microservices software architecture. Under this model, applications are broken down into their core functions, which are written to be run independently and communicate via API.

These small functions run by serverless services are triggered by what are called events. Taking Lambda as an example, an event could be a user uploading a file to S3 or a video being placed into an AWS Kinesis stream. The Lambda function runs every time one of these relevant events is fired. Once the task has run, the cloud service will spin down the underlying infrastructure. This approach results in users being billed only for the time the code is running, in the case of AWS Lambda and its Microsoft Azure alternative, down to the nearest 100ms.

The name Lambda is derived from the term Lambda function, which refers to small anonymous features used in Lambda calculus.

Drawbacks Of Using Serverless Computing

Like every computing paradigm, serverless has its drawbacks, particularly in its current form. One recent paper by UC Berkeley researchers highlighted the issues with the limited lifetimes of serverless instances, the network bottlenecks from regularly shunting data back and forth, and the fact that specialized chips such as GPUs aren’t available via serverless offerings such as AWS Lambda. Another common criticism is the latency when running a serverless function for the first time, stemming from the time it takes to spin up the underlying IT infrastructure.

Serverless services or FaaS offerings such as Lambda are not suited to running existing applications without those applications being rewritten; however, due to the code, they run being structured very differently to that found inside most existing apps and not being able to rely on the state of the application is saved. Serverless services run small modular functions, which are event-driven, as explained above, and stateless.

Long-running computational tasks are also not suited to Lambda at present, with each function running for a maximum of 15 minutes. However, Google’s serverless offering doesn’t have this restriction. A Lambda function can also only be executed 1000 times concurrently, although this limit can be raised on request.

Not every application is suited to be run on a serverless computing platform, with the vision being that serverless code will form part of a claim, serving as part of a larger whole. That said, there are plenty of use cases today for serverless computing. AWS Lambda can easily be integrated with many different AWS services and NoSQL databases via API, and there are no charges for transferring data between Lambda and a range of other AWS services within the same AWS region.

For Lambda, other possible uses include data processing, with Lambda carrying out real-time ETL on data within a Kinesis stream and loading it into a database after it’s been transformed. A more concrete example is the Lambda@Edge function could be used to select the type of content a web application should return to a user based on their location and the type of device they’re using. Lambda functions can also be used to glue AWS services together, being triggered by Auto Scaling events or CloudWatch alarms and, in turn, calling other AWS services.