Guide - Software Architecture: Containers vs Serverless
- Type
- Guide
- Year
- Category
- Containers, Serverless, Software Packaging, Cloud Infrastructure, CI/CD
Containers have indeed become a de facto standard for software packaging and delivery, revolutionizing the way applications are developed, deployed, and managed.
Almost 10 years back one company trusted Docker containers from their predecessor LXC Containers. Docker was launched back in 2013 and immediately became popular among developer communities due to it's simple and versatile use case.
How Docker Helped Us Achieve the (Near) Impossible - Iron.io / 2014
In an older Stackoverflow thread, Solomon Hykes, creator of the Docker, explained key features over it's predecessor LXC containers. I am using older posts to highlight the reasons it was invented and how the landscape looks today, after over 10 years.
What does Docker add to lxc-tools? - Solomon Hykes / 2013
The rise of containers as a de facto standard for software packaging and delivery can be attributed to their ability to provide consistency across environments, efficiency, support modern application development, and deployment practices like CI/CD and Microservices.
Serverless Computing: Hidden Infrastructure
Serverless cloud computing handles virtually all the system administration operations needed to make it easier for programmers to use the cloud. Essentially the resources becomes APIs and the inner working of those resources including the operations, security and scaling is managed by the Cloud providers.
In any serverless platform, the user just writes a cloud function in a high-level language, picks the event that should trigger the running of the function—such as loading an image into cloud storage or adding an image thumbnail to a database table—and lets the serverless system handle everything else: instance selection, scaling, deployment, fault tolerance, monitoring, logging, security patches, and so on.
A Berkeley View on Serverless Computing
UC Berkeley released two significant papers on Cloud Computing and Serverless Computing, 10 years apart. The first one was about the Rise of Cloud Computing and it's future, the next one was about Serverless Computing.
Above the Clouds: A Berkeley View of Cloud Computing
https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf
Cloud Programming Simplified: A Berkeley View on Serverless Computing
https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf
Even with the rise of cloud computing, the world still revolves around servers. That won’t last, though. Cloud apps are moving into a serverless world, and that will bring big implications for the creation and distribution of software and applications.
Post from 2012 / https://readwrite.com/why-the-future-of-software-and-apps-is-serverless
Given the history of both and their current popularity, let's look at some of the most common differences between Containers and Serverless:
Ease of Use
Serverless: Serverless computing provides a simplified development experience as it abstracts away the infrastructure management. Developers can focus on writing code without worrying about server provisioning, scaling, or maintenance. This makes serverless suitable for rapid application development and deployment.
Containers: Containerization requires a deeper understanding of the underlying infrastructure, including container orchestration tools like Kubernetes or Docker Swarm. While containers can be more lightweight than virtual machines, they still require knowledge of container management and networking. This can add complexity to the development and deployment process.
Scalability
Serverless: Serverless architectures are designed for automatic scaling on demand and scale down to zero. They can handle sudden spikes in traffic or load without manual intervention, making them highly scalable. However, serverless doesn't mean no servers, in the background the service has to acquire and initialize required infrastructure, this could add some extra latency.
Containers: Containers can also scale, but the scaling process is typically manual or requires the use of container orchestration tools like Kubernetes. While containers can be more lightweight than virtual machines, they still require management of the underlying infrastructure, which can impact scalability.
Performance
Serverless: Serverless functions can have higher latency than containers due to the dynamic creation and execution of code. This can result in longer response times for the first invocation of a function, known as a "cold start". Although there are ways to improve the performance, it does require additional management and configuration.
Containers: Containers provide consistent performance due to their dedicated and persistent nature. They do not suffer from cold starts and can maintain predictable response times, which is beneficial for applications that require low latency. But unlike serverless, scaling containers to match demand can be a bit of a tricky exercise. Scaling time required to process first-request may vary from container to container and will require container image optimization.
Security
Serverless: Serverless functions are generally short-lived, which can provide fine-grained IAM controls. However, it can be harder to verify the code integrity of serverless functions during CI/CD processes. The security of serverless functions depends on the implementation of the cloud provider's security measures.
Containers: Containers by default are not about security. Additional measures like gVisor, Kata containers, and Firecracker can be used to enhance container security. The security of containers depends on the implementation of security best practices and the use of appropriate tools and services.
Cost
Serverless: Serverless computing is generally more cost-effective because it follows a pay-per-use model. You only pay for the actual compute time used, which can lead to significant cost savings, especially for applications with variable or unpredictable workloads. The cost of serverless typically does not increase with usage, and in some cases, it can become cheaper as usage increases.
Containers: Containers require upfront infrastructure costs and ongoing management expenses. While they can be more cost-efficient than traditional virtual machines, the cost of containers can increase with usage due to the need to manage and maintain the underlying infrastructure. Some specific cloud services do provide scale to zero infrastructure like Google App Run.
Deployment and Management
Serverless: Serverless deployments are typically simpler and require less management than containers. Developers can focus on writing code without worrying about infrastructure management, which can lead to faster development cycles.
Containers: Containers require a more involved DevOps workflow that involves managing the infrastructure, including container management, orchestration, and networking. This can add complexity to the deployment and management process.
Benefits of Containers Over Serverless
Containers does offer more control, flexibility, and the ability to handle complex applications and stateful workloads, which can be advantageous in certain use cases.
Full Control: Containers offer full control over the environment, including the choice of root operating system, programming language, and software dependencies. This allows for greater flexibility and the ability to move legacy applications to a container model. This also avoids vendor lock-in as a growing concern for many enterprise use cases. Containers are easy to port across different cloud providers and orchestration tools.
Microservices Architecture: Containers are better suited for microservices architectures, where applications are split into smaller, independent services. This can lead to more efficient resource allocation and easier maintenance. This is debatable topic as Microservices architecture can be achieved by following specific serverless-patterns.
Stateful Applications: Containers can support stateful applications, which can be beneficial for applications that require persistent data or long-running processes.
Local Development and Deployment: Containers can be easily run in local data centers or on developers' workstations, making it easier to develop and test applications before deploying them to production.
Security: Containers can be more secure than serverless applications, as they can be run on dedicated infrastructure and are self-contained, making it more difficult for hackers to access the code and data.
Complexity Management: Containers can help manage the complexity of large, interconnected applications by encapsulating services and their dependencies. This can make it easier to scale and maintain such applications.
Benefits of Serverless Over Containers
Many modern services is fast moving towards the Serverless infrastructure, for example, Vercel, CloudFlare, Netlify, number of cloud databases, etc. Serverless can be a very good choice for startups or niche ideas.
Time-to-market: By reducing operational overhead and streamlining application development, businesses can bring new features and updates to market more quickly.
Faster development: By using serverless functions, you can reduce the need for dedicated server infrastructure and only pay for the compute resources you use.
Increased adaptability: IT teams can easily adjust resources as needed, without having to worry about over-provisioning or under-utilization.
Cost efficiency: Serverless architectures will reduce costs for applications that see inconsistent usage, with peak periods alternating with times of little to no traffic.
Ecosystem and community: Major cloud providers provide integrated services that work seamlessly with serverless computing, including databases and machine learning capabilities. This enables the creation of feature-rich applications.
Summary
Both the architecture style has pros and cons. You will find a lot of hybrid use cases where both are combined together to get the best of both worlds. Ultimately, it depends on the use case, team skill set and the willingness from stakeholders to experiment.
