Serverless (FaaS) vs Containers
Tags: docker, serverless, kubernetes, architecture
Published: 2019-12-19 07:39:04

---
title: Serverless (FaaS) vs Containers
published: true
date: 2019-10-10 12:14:21 UTC
tags: docker, serverless, kubernetes, architecture
canonical_url: https://x-team.com/blog/serverless-vs-containers/
---
Both serverless computing and containers are architectures that are lightweight alternatives to virtual machines. Because serverless and containerized apps both run in the cloud, they're a great way to significantly reduce a company's operational overheads.

Despite their similarities, there are significant differences between serverless and containers. This article will explore the most important differences between both architectures and explain which use cases are best suited for which architecture.

But before we dive into the differences, let's first establish what each architectural approach means.

### What is Serverless?

Serverless computing, and more specifically Function as a Service (FaaS), allows companies to use backend services on an _as-used_ basis. Through a serverless vendor, companies can remotely rent a computing environment and pay only when they use that environment, instead of paying for a fixed amount of bandwidth or a number of servers.

The benefits of serverless are that:

- companies don't need to worry about managing and maintaining servers, as that's entirely taken care of by the vendor. 
- it scales automatically with usage, so you won't end up paying for unused bandwidth. This is why serverless is cheaper than nearly every other alternative in most scenarios.
- it provides a quicker time to market. Companies don't need to worry about infrastructure. They can focus on solving business problems.

Examples of serverless platforms are Amazon DynamoDB, Amazon API Gateway, AWS Step Functions, and Amazon Simple Queue Service. However, AWS Lambda is the best-known serverless provider.

### What is a Container?

A container is a unit of software that packages up the entire configuration, code, dependencies, and runtime engine. The entire app and all the elements it needs to run properly are placed in a single container. The only thing a container needs is a hosting where it can run.

The benefits of containers are that:

- they give you greater control over the environment that your app runs in. You determine which programming languages are used, which libraries are used, etc...
- you can install almost any software you want. In fact, there's a rich ecosystem that you can dig into for prepackaged containers.

Popular container orchestrators are Kubernetes (K8), Amazon EKS, Amazon ECS, and Docker Swarm.

### The Differences Between Serverless and Containers

The first and biggest difference between both architectures is that you pay on an as-used basis with serverless, while you pay for the server space with containers. If your serverless app isn't used, you'll pay $0. If your containerized app isn't used, you'll still pay for the space your container takes up on the vendor's servers.

The second big difference is that a serverless app has no backend for you to manage. The vendor updates and maintains its servers. This is not the case with a containerized app, where you'll still have to make sure that the backend of your app is updated and patched regularly.

Thirdly, containerized apps take longer to set up initially, as you'll need to configure the system settings, libraries, etc... Once it's configured, a containerized app can be deployed in seconds. A serverless app, however, requires almost no setup whatsoever. Additionally, a serverless app is generally smaller than a containerized app and can be deployed in milliseconds.

Fourthly, because you have more control over the environment of your app, it's generally easier to test containerized apps before deploying them to production. It's easier to simulate a deployed environment with a containerized app, because you have full control over it. It's much more difficult to replicate a serverless environment.

Finally, there's something to be said about the security of both approaches. A serverless app relies much more on its vendor than a containerized app does, because the vendor controls the environment that a serverless app lives. You rely on the vendor for patching and upgrading their backend servers. This is not the case with a containerized app.

Additionally, because of its reliance on the vendor, a serverless app tends to lock you in with a single vendor. A containerized app is easy to transfer between vendors, because of its very nature: everything is inside a container and you only need to pick it up and place it in a different hosting platform.

### When to Use Serverless and When to Use Containers?

In general, using serverless is easier and faster than using containers. There's no need to think about backend infrastructure; you can focus on your business problem from the get-go. Serverless is also better when your traffic is unpredictable, as it scales automatically with usage.

However, containers are better if you want complete control over the environment that your app will be running in and/or if you want a rich ecosystem that you can dig into. It's great for companies who want to migrate one of their (monolithic) apps to the cloud, in particular if that app needs a webserver, app server, or third-party software to run well.

But it needn't be an either/or situation. It's possible to have a hybrid architecture too, with some functions that run on serverless and some functions deployed in containers. As said in the below rap song (yes, rap song): "_both of these architectural approaches are valid in different scenarios."_

{% youtube TN25-siFnS8 %}