Serverless Computing Services

What is Serverless Computing?

Serverless computing is a concept within cloud computing where the provider is entirely responsible for allocating and managing the required compute, networking and storage resources to execute small, short-lived tasks, also known as functions. It is often used within a “microservices-architected” application, where a trigger or event drives small isolated services, each with a single purpose. The primary benefit of this is cost optimisation since providers charge only for the duration of that task execution, removing the wasted cost of running an idle server. In addition, developers can write and deploy their code without extensive knowledge of server infrastructure, operating systems, patching, scaling and availability since this is all handled by the cloud provider.

Serverless Technology in Action

In 2014, Amazon introduced AWS Lambda, which is widely acknowledged as the first modern serverless technology within public cloud computing. It was followed up by Microsoft’s Azure Functions and Google Cloud Functions in 2016 and 2017, respectively. The concept was simple – a compute service that executes code in response to an event, automatically deploying the required infrastructure and terminating this once complete. The customer is charged only for the number of served requests and the duration of the execution (initially in increments of 100 milliseconds, but this is now reduced to a price per millisecond), making it an extremely cost-effective process.

How Serverless Technology Works

The above diagram shows a theoretical example of a serverless application hosting a static website with dynamic information.

This architecture demonstrates the combination of five serverless services, in this case within AWS:

• Storage – the S3 bucket holds static HTML data files and can serve these across the internet with no server. This could be further improved by using a Content Distribution Network (CDN) such as AWS CloudFront.
• API – the API Gateway is a serverless tool to receive API requests and then uses these requests to trigger an action. In this case, it executes some code hosted in a function, but numerous other activities could be activated.
• Function – the Lambda function hosts the developer’s code to complete an action. In this example, it is receiving an API request for data, locating that data in the database and then sending it back to the client.
• Database – DynamoDB represents the serverless key-value NoSQL database in AWS. The relevant data can be retrieved using the key presented by the client through the API.
• Scheduler – finally, there is the EventBridge rule which runs scheduled events based on a standard cron schedule format, though it can also be an event-driven process itself.

Migration from a standard monolithic application to a serverless architecture would involve the following:

1. Identify all components within the application which perform a task and draw out how each links with the others.
2. Calculate each task that can be replaced using a serverless service or through code hosted in a function.
3. As per the diagram below, splitting each component into the relevant task then allows the application to be transformed into a serverless application.

This process of splitting the application into smaller tasks is called microservices architecture.

Benefits of Serverless Computing

In the past, the above would run on a server, or multiple servers depending on the number of requests received by the website. These servers would cost the same amount of money even without any activity. If there were the potential for a very high number of requests at times and very little activity at others, there would need to be sufficient servers running to cope with the increased demand, even when there were none.

In contrast, serverless computing charges are only applied by the cloud provider when there is some activity. Costs for the API Gateway, Lambda functions and DynamoDB database are accrued when these services are active. The one exception is the static data for the website stored in the S3 bucket. The cost of this is minimal compared to the running costs of a server. Server computing, therefore, means higher charges when there is high demand but little to no charges at quiet times, dramatically reducing the cost of the solution.

In addition, the developer who creates this application needs only to know the code to write and retrieve data from the database via the API. They do not need to be able to deploy a server, configure the operating system and install the applications which would fulfil these functions. There is also no ongoing management of the server infrastructure – no patching, availability and security monitoring of the operating system, disaster recovery planning etc.

Finally, serverless components will also scale automatically on demand. A well-designed and implemented serverless solution should scale with requests as they arrive, meaning your customers never receive an error due to an unexpected outage caused by popular demand – this can be crucial to a successful launch of a new product or service.

Drawbacks of Serverless Computing

As is always the case, there are some drawbacks to using serverless functions:

1. They are generally time limited in scope for short-term operations, and some processes will timeout and fail after a certain amount of time, e.g. AWS Lambda functions will run for a maximum of 15 minutes. This is by design since long-running tasks are not suited for such event-driven architectures.
2. They are designed to be ephemeral, so any application that relies on stateful data from previous executions may not be best suited to this. However, there are potential solutions, such as storing state in a storage or database service.
3. Latency can be an issue since functions are created at the point of need – the problem of “cold starts” sometimes means a delay of a few seconds before the code begins to run. It’s possible to counteract this by keeping functions “warm” by triggering them at regular intervals. Since this means they are only running for a few milliseconds, this is still considerably cheaper than running a server full-time.
4. Vendor lock-in – by their nature, serverless computing is tied to the services provided by that vendor. Whilst a solution built using AWS API Gateway, Lambda, S3, and DynamoDB can be migrated to another provider, it would take planning, deployment of those services in the new cloud provider and updating any specific code to the vendor initially chosen.

Why Choose Serverless Computing?

In summary, serverless computing should be a vital part of your cloud portfolio. Whilst there are some drawbacks, the cost benefits of migrating key services to serverless services greatly outweigh them for most scenarios and will allow your business to remain competitive in today’s challenging economic conditions. Serverless computing also fits into the cloud-native development and DevOps philosophies that enable faster, more reliable deployments and drive digital innovation.