Why everyone wants to go serverless

Serverless is a cloud-native development model that allows developers to create, build, and run applications without having to personally manage servers. Instead, server management is handled by the cloud provider.

There are multiple advantages to the serverless model, such as reducing costs, providing greater scalability, reducing maintenance overhead, and allowing quick deployments. Serverless also decreases latency since the code can be run closer to the end user.

In this article, you’ll explore the benefits of serverless and what to consider before you migrate to a serverless model. You’ll also learn about some real-world use cases.

Serverless is a computing method that provisions backend services on a per-user basis. Essentially, you can write and deploy your code without having to worry about the underlying infrastructure. Serverless is popular for several reasons, detailed below.

You’re only charged for what you use, so your code will only run when the backend infrastructure is required by the serverless application. This payment model is similar to the one used by utility providers; for example, you only pay for the electricity you consume. In this cloud scenario, you only pay for the computing resources you use. This means you don't need to purchase server capacity that you might not use, which reduces your overall costs.

Serverless allows you to build applications using the function-as-a-service (FaaS) paradigm. FaaS is a serverless way to run functions or specific server-side logic in a cloud environment. Each function needs to be small and do one specific thing. The advantage of this paradigm is that there is no need for server configuration when an application is being deployed. You can focus on developing your function code without needing to build and maintain the backend infrastructure.

A key tenet of serverless is managed services, in which the provisioning and maintenance of backend infrastructure are delegated to the cloud provider. For example, you build and run your applications on servers that provide a certain level of computing, but you don’t manage these servers. The provider is responsible for things like keeping the server software updated and applying security patches. This allows you to focus on your application code.

Service integration is the ability for serverless services to interact and provide input or output to other services. There are a lot of serverless services that do specific things; for example, you can have storage services that store objects, compute services for writing custom computation, and database services for providing access to databases. Service integrations allow you to connect these different services so that they work as one application. Using the above three services as examples, you can build an application using service integrations in which a new object being stored triggers your custom compute service to process the object. When the computation is complete, the results are stored in your database service.

Serverless applications are highly scalable in provisioning infrastructure. Provisioning is quick and dynamic, automatically scaling up and down as needed. This reduces your costs in the long run and improves the availability and reliability of your services. The improved availability ensures that you’ll always have the right amount of infrastructure to meet your demand.

With serverless, you don’t need to host an application on an origin server, because the application code can be run from anywhere. Most cloud providers deploy your code to multiple servers and allow the code to run on the servers that are close to the end user. This also reduces latency, since the user requests are simply run from the closest server.

In addition to the above benefits, serverless also offers advantages over service-oriented architecture (SOA). SOA is an architectural style that uses service interfaces to integrate separate, reusable, and distributed software components.

The key difference between serverless and SOA is that serverless deals with infrastructure provisioning and management, while SOA uses services that hold the code and the data integrations required to execute a specific business function. With serverless, you don’t need to manage the underlying infrastructure.

Another benefit of serverless over SOA is that serverless is not dependent on an enterprise service bus (ESB), in which other connected services are impacted if issues occur.

There are many advantages to going serverless, but there are challenges as well. The following are some possible issues you’ll need to consider first.

This is a challenge when using serverless, because traditional databases are not suitable for serverless workloads. Serverless functions can’t maintain persistent connections and connection pools. Additionally, they communicate using HTTP, not TCP/IP, and they spin down aggressively, leading to potentially longer restarts. These factors mean that your database choices are limited. Two of the best-known options are DynamoDB and Firestore.

However, the number of serverless databases has increased in recent years. Aside from existing tools like MongoDB Atlas and Azure Cosmos, new options in the market include PlanetScale and Fauna.

When a serverless function is not being used, it is killed. This means that when it’s called again, it needs to boot up. The speed with which the code executes is temporarily slowed, possibly affecting your operations. This request for a function that has not been used for a while is called a cold start.

Serverless is mainly suitable for short-running tasks with a single purpose, so if you need to perform in-depth analysis or long-running tasks, serverless might not be the solution. For example, there are time and memory limits on Lambda functions. Generally, Lambda functions can run up to fifteen minutes and edge functions can run up to five seconds. This can impose limitations on what you’re able to accomplish.

With serverless, you do not own or have control over the underlying infrastructure. This means that hardware faults or errors and any other issues affecting your servers could impact your operations. If you decide to go serverless, you should choose providers with strong reliability numbers as well as several replications and backup services to guarantee continuity in case their hardware fails.

Building and running serverless applications from one provider can mean that migrating to or using services from another provider can be problematic. You may need to rewrite code and put in the manual work required to move or integrate with other providers. If you are going to go serverless, make sure the provider you are choosing has the services you need to avoid problems down the line.

Testing is more complicated with serverless. Developers can create and run unit tests on their function code, but integration tests that measure how components interact are more difficult to perform in serverless environments. This is because every time a serverless function is created, it creates a new version of itself, which makes it hard to collect the necessary data to debug and fix the function.

Serverless is mainly used to manage workloads that experience fluctuations in request traffic; for example, the request traffic can be infrequent with intermittent spikes. For this reason, serverless includes the following main use cases.

Serverless is ideal for any activity that triggers an event or a series of events, such as change data capture. A change to a database can trigger a replication job to ensure that a backup database is updated.

Serverless functions can handle behind-the-scenes application tasks such as resizing image files and transcribing or transcoding videos after upload. It does this without adding any user-facing latency, because the task continues without interrupting the flow of the application.

Continuous integration/continuous deployment (CI/CD) pipelines allow you to push code in small increments to allow for quick bug fixes and updates. Serverless can automate such processes. When you commit changes to your code, for example, a serverless function can be triggered to create a build. When you create a pull request, a serverless function can be triggered to start automated tests.

Serverless allows you to build polyglot applications, meaning you can use several programming languages and build each function in the most appropriate language for that function. This prevents you from being locked in with a legacy language, since new languages can be used to build new functions.

Serverless applications can autoscale to meet demand, so they can be used for applications like chatbots, websites, and application programming interfaces (APIs).

As you saw in this article, there are many reasons to go serverless. Doing so enables you to simplify your workflow, reduce your costs, and increase your scalability, among other benefits. Even the potential disadvantages can be accounted for if you make sure to choose the right provider.

One tool that can make serverless projects easy is Fauna, a truly serverless, document-relational database. Fauna, the first natively serverless database, is designed to offer high flexibility and scalability without you needing to manage servers or clusters. You can use Fauna for new or existing applications and track your usage and billing in near real time. To see how Fauna can help you, sign up for free or talk to an expert.