Different compute solutions in AWS

AWS Lambda and AWS Containers are both powerful solutions for deploying applications and services, but they serve different purposes and come with their own set of advantages and limitations. Here we are going to discuss those.

Table of Content

• Selecting Compute Solutions
• Containers
  • EKS or ECS
• Lambda
• Batch
• Use Case Considerations

Selecting Compute Solutions

There are various parameters to consider while choosing a compute solutions from: Lambda, Containers (EKS, ECS/Fargate), and EC2

• Understand configuration (tuning) for selected compute solutions
• Capture Compute Metrics to understand resource utilization
• Use Elasticity of resources (scale up/down)
• Regularly re-evaluate resource requirements e.g. memory

Containers

Container orchestrators have emerged as an important tools for deploying, managing, and scaling containerized applications. Among the most prominent orchestrators are EKS and ECS. Containers, by design, are particularly advantageous for applications experiencing predictable, load-heavy traffic. They encapsulate the application’s runtime environment, ensuring consistency across development, testing, and production environments, thus making them an ideal choice for handling peak traffic efficiently.

EKS stands out for its cloud-agnostic nature, providing a seamless pathway for migrating code across major cloud providers such as AWS, Azure, and Google Cloud. This interoperability is crucial for organizations looking to avoid vendor lock-in, allowing them to leverage the best services across cloud platforms with minimal friction.

Furthermore, containers are exceptionally well-suited for applications that depend on specific software dependencies. By bundling the application with its dependencies into a single container, developers can ensure that the application runs flawlessly in any environment, eliminating the “it works on my machine” syndrome.

However, deploying and managing containers at scale requires a sophisticated infrastructure, underscoring the need for skilled personnel to handle the complexities of container orchestration. This is where ECS comes into play, offering powerful container scheduling capabilities that simplify the deployment and management of containerized applications. ECS integrates deeply with the AWS ecosystem, providing a streamlined workflow for deploying, managing, and scaling containerized applications without the overhead of managing the orchestrator itself.

EKS or ECS

1. Team Expertise: Consider the expertise of your team. If your team is already familiar with Kubernetes, EKS might be a more suitable choice.

2. Application Requirements: Evaluate the specific needs of your application. If you need the extensive configurability and portability of Kubernetes, go with EKS. If you prefer simplicity and tight AWS integration, ECS could be better.

3. Operational Overhead: Consider the operational complexity you’re willing to manage. EKS can require more effort to set up and maintain, while ECS with Fargate can reduce the operational burden.

4. Cost: Analyze the cost implications of both services. While the pricing models differ, your choice could impact the overall cost based on your application’s architecture and usage patterns.

5. Ecosystem and Tools: Consider the tools and services you plan to integrate with. EKS might be beneficial if you rely on Kubernetes-specific tools, whereas ECS might be preferable for deep AWS service integration.

Lambda

• Lambda is useful when traffic is unpredictable
• Lambda automatically take care of autoscaling.
• Best at Event-Driven Architecture
• no infrastructure needed. No patching
• Pay per use policy (10,000,000 Request per day cost 7 USD)
• Vendor lock-in (AWS)
• Limits (timeouts, cold start)

Batch

• Consider AWS Batch as Long running lambda, the more you run, the more you pay. AWS Batch is optimized for batch computing (multiple jobs in parallel) that does not require heavy logic. It requires Batch BASH script
• AWS Batch dynamically provisions the optimal quantity and type of computing resources based on the volume and specific resource requirements of the batch jobs submitted.
• There is no additional charge for AWS Batch. You only pay for the AWS resources (e.g. EC2/Fargate/EKS).
• In AWS Batch, job queues are mapped to computing environments (Fargate/EC2/EKS/Mix). A specific compute environment can also be mapped to one or many job queues. Within a job queue, the associated compute environments each have an order that’s used by the scheduler to determine where jobs that are ready to be run should run.

Use Case Considerations

• Short-Lived, Event-Driven Processes: Use AWS Lambda for lightweight, event-driven functions where execution time is short.
• Full Control and Customization: Use containers when you need full control over the environment or when running long-lived applications.
• Complex Applications: For complex applications with multiple components, containers can provide a better environment.
• Rapid Scaling: For rapid scaling needs, Lambda can quickly respond to varying loads.
• Long Running Jobs: AWS Batch is ideal for batch processing jobs, including data processing, image or media processing, and financial modeling.

In summary, the choice between AWS Lambda and Containers depends on the specific requirements and constraints of your project. AWS Lambda is ideal for serverless, event-driven architectures, while containers offer more control and are suitable for complex applications with heavy loads.