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.
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:
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.
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:
Popular container orchestrators are Kubernetes (K8), Amazon EKS, Amazon ECS, and Docker Swarm.
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.
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."