In a world of configuring systems and applications and fast-paced deployment to meet customer demands, companies are turning to solutions that will ensure the process of making changes to their products is fast, efficient, scalable, and reliable. These premises have led to a lot of innovation around how applications are deployed, whether on-premise or in the cloud. The method of delivery employed for applications greatly determines your core DevOps metrics, which are:
– Mean Time to Recover
– Change failure rate
– Release Frequency
– Lead time for changes
But what options exist in terms of efficient software delivery, and how do you choose for your organization? There are various delivery models, but in this article, we shall focus on two major models in use: Serverless and Containers
Serverless Deployment Model
Serverless is a model of application management that abstracts the operational complexity of managing servers from the engineers. Serverless ensures that applications deployed to it are highly available, scalable, and easy to manage. A Serverless engineer does not require Linux or Sysadmin knowledge to deploy and manage a serverless-based application. The focus in Serverless is on the code only, with minor tuning of the environment to align with the behavior of the application.
Serverless systems usually give minimal configuration options to manage the application such as memory allocation, CPU allocation, and concurrency configurations. Serverless applications are designed for one-time operations that involve a specific task.
An example is an API call to perform a database operation and return a response. Consume messages from a queue. Resize an image. These one-time, short-term operations are where serverless applications shine. One other application they are good for is State Machines. When the system you need to implement involves a series of steps and operations with feedback at every stage and a mechanism to retry, like a DAG, serverless applications are useful in this scenario. AWS Step Function is a serverless service that can be used to implement state machines.
Serverless Underlying Architecture
Serverless is more of a model of application delivery than there is “no server”, just like the concept of cloud computing does not necessarily mean there are computers in the cloud. So, “behind the scenes,” serverless servers are running and managed by the cloud provider with a platform that delivers the serverless capability and abstracts the server from the user. Abstraction systems like Firecracker that orchestrate MicroVMs power services in AWS, such as AWS Lambda and AWS Fargate. Firecracker still needs to be deployed and run inside of a virtual machine or bare metal machine with an operating system. There is also the defunded Kubeless, which was an abstraction on Kubernetes used to run serverless applications. So in the end, serverless applications run on a PaaS (Platform as a Service) with major abstractions of the operational complexities of system administration.
Container Deployment Model
Containers are a way to package applications for efficient delivery and running of the application. Apart from packaging applications like its RPM and DEB counterparts, it also ensures isolation from its host. A common implementation of containers is Docker, which has been explained here in detail.
For containers to run at scale, it requires an orchestrator is required. A container orchestration tool helps to manage the life cycle of containers, ensuring the availability and scalability of containers.
The first step in using a container after the application is ready to be deployed is an image that needs to be built, which is the package that contains the application, its configurations, and dependencies. The image needs to be stored in an artifactory for easy retrieval and reuse. An instance of a container is created from the image, while the image remains the source of truth. Multiple containers can be created from a single image. An image is a potential container, a static container, while a container is a kinetic image which is a dynamic image.
Container Underlying Architecture
A container requires an operating system to run. It has certain core components that make its features possible, they are namespaces and groups. These two components make it possible to run a container in a Virtual Machine or a bare metal with an operating system. Using Docker as an example to represent containers, it is made up of three major components: Docker CLI, Docker API, and the Docker Engine. The runtime manages the life cycle of a Docker image when it is not running inside a container orchestration service like Kubernetes.
Comparison between Serverless and Containers
1. Containers require knowledge of containerization and the most popular option is Docker. The application needs to be packaged, stored, shipped, and deployed before it can run. Some Linux skills are needed to do this effectively and manage the virtual machines where it will be deployed.
In Serverless, the focus is on the code, and not on the environment or infrastructure that runs the application. If your code is well optimized, then you are guaranteed a smooth running of your application
2. Containers require a virtual machine or a bare metal machine to run. With a container runtime deployed on the machine before the container can run. Serverless does not require a virtual machine, just the Serverless platform with a specific language runtime.
3. Applications packaged in containers do not require any unique knowledge and understanding of the environment they will run on. Developers can write their code however they like; it gets packaged, shipped, and runs the same way it was built. Serverless applications require a specific method of coding, and it has limitations in some use cases. For example, in AWS Lambda (a serverless compute service from AWS), the starting function must be configured with a handler, which is the trigger to start the application. Without that configuration, the Lambda function will not run properly.
4. Container hosting services in the cloud are usually billed per hour, for example, Amazon ECS Fargate or AWS Apprunner. Serverless services are billed based on the number of invocations, just like in AWS Lambda or Amazon SQS
5. Scaling container-based workloads requires some manual work and an understanding of your scaling needs. However, our serverless-based workloads do not require any manual intervention for them to scale.
6. Container-based workloads are good for long-running operations like an ETL Pipeline, while Serverless workloads are ideal for short tasks, like connecting to a database to retrieve a small amount of data.
7. Container-based workloads are portable across cloud providers and even on-premise infrastructure. The same container can be deployed across the board without any changes to the Docker image. Whereas Serverless workloads are vendor-specific. A code written for AWS Lambda will not run in Azure Serverless Functions; it will need some re-architecting to run
Cost Comparison
It is good to establish the fact that the cost of an infrastructure is directly proportional to the implemented architecture. We can do a baseline comparison between AWS Lambda and AWS Fargate using similar system configurations.
System Specification: 1vCPU, 2GB RAM with 1million request in a month
Lambda Cost
Assuming this specification:
- Number of Requests: 1 million per month
- Average Execution Duration: 100 milliseconds (0.1 seconds)
Compute Charges:
- Total Compute (GB-s): 1,000,000 requests × 0.1 seconds × 2 GB = 200,000 GB-s
- Compute Cost: 200,000 GB-s × $0.0000166667/GB-s = $3.33
Request Charges:
- Since the first 1 million requests are free, there are no additional request charges.
Total Monthly Cost:
- Compute Charges: $3.33
- Request Charges: $0.00
Total: $3.33 per month
Fargate Cost
30.42 tasks x 1 vCPU x 24 hours x 0.04048 USD per hour = 29.55 USD for vCPU hours
30.42 tasks x 2.00 GB x 24 hours x 0.004445 USD per GB per hour = 6.49 USD for GB hours
20 GB – 20 GB (no additional charge) = 0.00 GB billable ephemeral storage per task
29.55 USD for vCPU hours + 6.49 USD for GB hours = 36.04 USD total
Fargate cost: $36.04 per month
*Cost varies and is subjective on many other parameters such as data transfer, region, and application operations.
Use Cases
Serverless: Event-driven systems, State Machines, Microservices
Containers: Web Applications, Machine Learning, Data Engineering, Database
Conclusion
The choice between Serverless and Containers depends solely on the knowledge base of your team, cost, and team dynamics. There is also a hybrid architecture where Containers and Serverless technology can be used, which I think is a better approach. None is better than the other in the end, but the implementation is what matters.
