What is serverless architecture?

Serverless architecture explained

A common misconception about serverless architecture is that applications don’t use servers. This isn’t the case. It’s the concept of individual servers which is removed because the infrastructure is managed by a cloud provider. Think of it like storing data on the cloud rather than your computer; it’s still stored on physical hardware, just not your own.

Serverless is a service-in-the-cloud provider you work with that runs the physical servers and allocates resources on your behalf. How and where the code is run is abstracted from you and handled by the cloud provider. Serverless architecture can drastically reduce the time to market, as you spend less time setting up infrastructure and more time building.

Serverless architecture and microservices are also sometimes mixed up, and though microservices are often deployed with a serverless approach, they are not required to be serverless.

DevOps teams like to go serverless because a serverless architecture also often supports automatic scaling. When your apps receive a lot of traffic, the system scales up to meet demand. When the demand drops, the system automatically scales back down again and can stop running altogether – making a substantial saving on costs when idle. 

In contrast, with a traditional approach, you must deploy all of your infrastructure up front, which comes at financial and time costs. Plus, it requires specialists. This inflexibility means you’re paying for infrastructure to always run, even when it’s not in use.

How does serverless architecture work?

At its core, serverless architecture allows systems to be executed in the cloud without managing the underlying infrastructure. This can be a whole backend system — for example, a database that you can connect to and run queries on — where the hardware is managed for you. 

Serverless computing goes hand in hand with functions as a service (FaaS), where a single, self-contained code snippet is deployed and executed in the cloud. The most popular FaaS are AWS Lambda from Amazon or Azure functions from Microsoft.

Serverless functions are event-driven, and can be triggered by anything, from websites to IoT and smart home devices. Each event starts an invocation of the function, which in the background, provisions the infrastructure and runs the code. The time that it takes to provision the infrastructure is called the “cold start.”

Within a serverless architecture, you only pay for what you use. 

For instance, say you want to build an API. Traditionally, this involves running the API on a server behind an API gateway that would always be running and accepting requests. Meanwhile, if the same API is run using serverless architecture, each component would be deployed as a separate function. Every time someone makes a request, the provider bills you on demand for the execution of the specific piece of code that handles that request.

From a developer’s perspective, serverless architecture and serverless functions mean breaking down complex problems into smaller units of business logic that you can deploy separately. This lets teams and individuals work on things in parallel.

Benefits of serverless architecture

Several benefits come with using serverless architecture. Three of the most significant include the ability to scale without trouble, reduced costs, and ease of use. Let’s explore each of these in detail.

Reduced costs

As mentioned before, with a traditional architecture, you need to account for the maximum load upfront. This is cost-effective only if your APIs are constantly under load. But if your APIs only get seldom called, you can benefit from the reduced cost allowed by automatic downscaling.

Ease of use

Serverless architecture can make life easier for developers because you can concentrate on business requirements without worrying about infrastructure. 

Furthermore, any infrastructure configuration is stored in config files along with the code, simplifying the deployment and allowing other developers to gain an understanding of how their code is run. 

Challenges of serverless architecture

Some challenges come with serverless architecture. Let’s explore a few.

Security risks

With no infrastructure to manage, the security risks differ from traditional applications. If misconfigured, serverless functions can be prone to denial of service attacks. This is because attackers could exploit the automatic scalability by invoking the function many times and making you pay a large bill.

Vendor lock-in

The beauty of serverless and cloud computing is that you don’t have to manage the infrastructure yourself. However, this comes at the cost of being closely tied to your third-party cloud provider. This limits your ability to move from one provider to another, as many serverless tools are bespoke to the cloud vendor.

Fortunately, providers are uniting in WinterGC to address this shortcoming, seeking to create a more unified API surface that all JavaScript developers can use regardless of runtime.

Constrained runtime and cold starts

Serverless functions usually have a constrained runtime. In most cases, the upper limit is 10 to 15 minutes. This makes them impractical for long-running tasks.

Additionally, if serverless functions aren’t kept active at regular intervals, they can be de-provisioned, requiring a cold start again. If you get a request after de-provisioning, the time required to get a response is the usual amount of time and the cold start. This takes a toll on latency and performance.

Parallel processing

When a function is invoked many times in parallel, it can cause throttling. Your infrastructure might no longer be able to serve requests and they won't be able to recover from the failure state.

Serverless use cases

Serverless architecture has many use cases, from smart home devices to chatbots. This section highlights a few use cases.

All of the use cases below are well-suited to serverless architecture because they follow an event, action, and scale process. They each start with a triggering event, the entry point to the function, before performing an isolated action. As demand increases for each use case, it’s easy to scale up by running more instances of the function to meet the demand.

Autoscaling websites and APIs

With serverless applications, you can spin up as many instances of your website or API functions as necessary and scale down as soon as web traffic wanes. You pay only for what you provision from your cloud provider, minimizing concerns about overburdened servers and crashes and providing a more consistent experience for your end users. 

Multimedia processing

The power of cloud services enables you to incorporate media processing capabilities. For example, if your organization allows card-based payments, you could integrate a real-time image recognition API that lets customers upload photos of their credit cards and instantly extract their information.

Wrapping up

Serverless architecture removes infrastructure workloads from development teams, giving them more time to improve and refine your user experience. The architecture also reduces costs as you only pay for actual run time and enables almost infinite scaling due to the cloud provider's ability to spin up many instances of the same process to meet demand.