To keep ahead of the curve, many organizations are looking at how to evolve their technical processes to accelerate their IT infrastructure development. Fast and robust deployments to the latest platforms are key to achieving the low lead times that enable this evolution.
Two of the most widely-used technologies to host these deployments are serverless functions and containers. What are they, how do they differ, and how do you decide which is best for your application? In this comparison, we will look at some important differentiators between serverless computing and containers and outline some criteria you can use to decide which to use for your next project.
What is serverless?
Serverless technology is a bit of a misnomer. With serverless computing, workloads do in fact run on a server that hosts the functionality behind the scenes. However, the server is not managed by the developer. It may be more accurate to say that it is the developer’s todo list that is serverless.
Serverless functions are usually small, lightweight programmatic functions with a single purpose. That single purpose can be anything, from getting a customer’s details out of a database to displaying a notification.
Most cloud providers offer serverless functions, which they may refer to as functions as a service (FaaS). The leading offerings are AWS Lambda, Azure Functions, and Google Cloud Functions, each with many integrations within the associated ecosystems. They are ideal for providing API endpoints or microservices.
What are containers?
The classic metaphor for understanding containers is to imagine a container ship transporting cargo across large bodies of water.
Containers are a self-contained, lightweight virtualization technology. They are similar to virtual machines (VMs), except they only virtualize the guest operating system (OS) and applications instead of an entire computer. Containers are quicker and easier to set up than a VM. To go back to our ship metaphor, the ship itself represents the host OS and hardware, while the cargo containers are the guest OS and application.
Once someone builds a container, they can deploy and run it using a service like Amazon’s Elastic Container Service (ECS) or Docker. However, DevOps teams most often deploy containers to Kubernetes clusters.
Containers are one of the best ways to transform an existing monolithic application into a cloud-native one. To be as efficient as possible, containers should also split the application into smaller parts.
Serverless vs containers: similarities and differences
There are several similarities between serverless and containerized applications. There are also some important differences.
How are serverless and containers similar?
In most cases, neither serverless functions nor containers require a developer to worry about servers or the infrastructure hosting their applications. The host hardware and operating system are compartmentalized away from the guest application and operating system. DevOps teams do not need to consider what hardware the serverless functions or containers use.
Both hosting options are scalable by simply provisioning better hardware such as a more powerful CPU, more memory, or faster networking ability.
The exception to this is when using containers with on-premises infrastructure. In that case, hardware provisioning is a manual process, often handled by a dedicated infrastructure team.
It is also possible to scale based on demands like traffic. Kubernetes, an open-source orchestration system, can horizontally scale containers in seconds. Similarly, many FaaS offerings can automatically scale out based on important metrics like the number of requests routed to the application.
Serverless functions and containers are both compatible with top continuous integration platforms, including CircleCI. For each build that completes successfully, automated tools can deploy a new version of a container image or serverless function to your infrastructure provider.
How are serverless and containers different?
Despite the similarities between the two technologies, each has unique uses based on some inherent differences.
Both serverless and containers are elastic, so they can scale in and out when required. However, DevOps teams that use containers need container orchestration software like Kubernetes to scale automatically based on given criteria. Meanwhile, many FaaS platforms provide this service out-of-the-box.
Serverless functions are often small, self-contained pieces of functionality with a single responsibility. They are usually short-lived, running for just a few minutes, or a few seconds if they are customer-facing. Meanwhile, containers work best for more extensive, long-running applications or applications with multiple responsibilities.
Containers are a good choice for:
- Moving away from traditional, on-premises infrastructure
- Making an existing monolithic application cloud-native
- Developing an application that runs for hours at a time
A significant difference is that your provider will bill you only for the time your serverless functions spend running. In contrast, you spin up container instances and keep at least some of them running 24/7, often leading to a higher cost. If your application is small and better suited to a serverless application, the wasted resources quickly generate unnecessary cost and lead to a larger environmental impact.
There are some examples of serverless offerings for containers, however. AWS Fargate is a platform used for hosting and running containers, and you are billed only for the time the container takes to finish running.
Another difference is that vendor lock-in is more of a concern with serverless functions. You can easily become tied into a particular ecosystem because of the code needed to integrate with associated services.
In contrast, containers let you stay vendor neutral. A side effect of this neutrality is that containers support any language, while serverless applications are limited to a small selection of languages. This list of supported languages varies for each provider.
How to choose between serverless and containers for your application
When you are deciding whether serverless or containers is best suited for your application, it is best to take all the factors listed above into consideration. However, your application architecture’s size and structure should be the main elements that influence your decision. And be sure to include other factors like pricing in your decision.
You can deploy a small application or one that we can easily split into multiple smaller microservices as a serverless application. On the other hand, a larger, more complex application might be better suited as a containerized application. Sets of services that are tightly coupled, that cannot easily be broken down into small microservices, are strong candidates for containers.
Due to limitations on serverless offerings, containers may be a better choice for some applications. Examples of these are those written in unsupported languages or those that have long running times, such as machine learning applications.
But you do not necessarily have to choose one or the other either. Serverless and containers are not mutually exclusive. You can use containers where needed, combining with serverless where it makes sense, and enjoy the best of both worlds. As we mentioned earlier, there are even serverless offerings for hosting containers that aim to bridge the gap between the two options.
Both serverless and containers are great options for creating the scalable cloud-native applications that will allow you to innovate more quickly. To find out more about how to get started, check out these tutorials:
Whether you choose to use serverless or containers, you can employ CircleCI’s continuous integration platform to automate your building, testing, and deploying. Once you have determined how you can use serverless and containers to your advantage, learn more about how you can use CI/CD pipelines to optimize and streamline your development process.