Containers or serverless functions: A path for cloud-native success (SVS209)
Containers or Serverless Functions: A Path for Cloud Native Success
Fundamentals of Containers
Containers share the kernel of the host operating system, making them more resource-efficient than traditional virtual machines.
A container is defined by a container image, which has multiple layers including the base image, runtime, and application code.
Containers need to run on a compute node, which is managed by a container runtime and a container orchestrator for high availability and scaling.
The container lifecycle includes initialization, running the application, and potentially shutting down the container.
Fundamentals of Serverless Functions
Serverless functions are a way to build and run applications without having to manage infrastructure.
The key components of a Lambda function include the function handler, which is the code that runs when the function is invoked, and the firecracker microVM that provides isolation for the function execution.
Lambda functions are event-driven and can be triggered by various AWS services like API Gateway, SQS, and DynamoDB streams.
Lambda functions scale automatically based on the incoming request volume and can scale down to zero when there are no requests.
Cold starts and warm starts are important aspects of Lambda function execution, with cold starts taking longer to initialize the execution environment.
Operations, Integrations, Portability, and Pricing
In terms of operations, containers offer more control and flexibility, while serverless functions provide more simplicity and reduced operational overhead.
Containers are more flexible in terms of integrations, as they can expose any port and communicate with various services. Serverless functions have better integration with the AWS ecosystem.
Containers are more portable at the application layer, but the container orchestrator may require more effort to port. Serverless functions can be made more portable by using frameworks and hexagonal architectures.
Containers have resource-based pricing, which is better suited for predictable and constant workloads. Serverless functions have usage-based pricing, which is more efficient for variable and spiky workloads.
Real-World Customer Examples
Delivery Hero: Built a container platform using Kubernetes and EKS to standardize infrastructure and operations across their subsidiaries.
DVLA (UK): Used both containers and serverless functions, with containers for stable components and serverless functions for event-driven, asynchronous processing.
Autodesk: Chose serverless functions over Kubernetes for their resource-intensive and variable-demand simulation workloads.
Lexware Office: Containerized parts of their SaaS accounting application, while using serverless functions for event-driven invoice processing.
Key Takeaways
Containers are better suited for constant and predictable workloads, while serverless functions excel at handling spiky and variable workloads.
Containers offer more control and flexibility, but also more operational responsibility. Serverless functions provide a more managed and simplified experience.
Containers have better portability at the application layer, while serverless functions can be made more portable through abstractions and Frameworks.
Pricing for containers is resource-based, while serverless functions have usage-based pricing, making them more efficient for variable workloads.
The choice between containers and serverless functions should be driven by the non-functional requirements of the application, such as scaling, operations, and pricing.
These cookies are used to collect information about how you interact with this website and allow us to remember you. We use this information to improve and customize your browsing experience, as well as for analytics.
If you decline, your information won’t be tracked when you visit this website. A single cookie will be used in your browser to remember your preference.