WWW.Cloud Series – Episode 5 -Amazon Web Services (AWS) – Fargate

The low down on Fargate

The What –

AWS Fargate is a serverless compute engine for containers offered by Amazon Web Services (AWS). It works with Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). Fargate makes it easy for developers to deploy and manage containers without addressing the underlying infrastructure.

The Why –

Fargate is especially suited for applications with variable workloads and requires flexibility in scaling. By abstracting away the infrastructure management, Fargate allows developers to focus on building and running applications, not the underlying infrastructure.

  1. Serverless: With Fargate, you don’t need to provision, scale, or manage servers. You define your container applications and specify their requirements (like CPU memory), and Fargate takes care of the rest.
  2. No Cluster Management: While using Fargate with ECS, you don’t need to manage the cluster, unlike when using EC2 launch type in ECS, where you must work the EC2 instances.
  3. Automatic Scaling: Fargate tasks can be scaled automatically based on demand.
  4. Isolation and Security: Every task in Fargate has its own isolation boundary and does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with other tasks. This brings added security and isolation compared to traditional shared instances.
  5. Integrated with AWS Services: Fargate integrates seamlessly with other AWS services like Application Load Balancer, Amazon VPC, and AWS IAM for enhanced functionality and security.
  6. Pricing: With Fargate, you only pay for the vCPU and memory of your containerized application requests, which can lead to cost savings compared to provisioning and managing servers.
  7. Seamless Integration with ECS and EKS: You can use Fargate to launch tasks via ECS or pods via EKS without managing the underlying EC2 instances.

The When –

AWS Fargate can be an excellent choice for containerized workloads in specific scenarios. Here are situations where you might consider using Fargate:

  1. Serverless Architecture: If you aim for a serverless architecture where you don’t want to manage or provision servers, Fargate offers a serverless way to run containers.
  2. Variable Workloads: For workloads that are sporadic and don’t run consistently, Fargate can be more cost effective because you only pay for the vCPU and memory when your task is running.
  3. Isolation Requirements: Each Fargate task runs in its own kernel runtime environment, offering a high degree of isolation. This can be ideal for multi-tenant applications where isolation between tasks is essential.
  4. Microservices: Fargate is an excellent fit for microservices, especially when different services might have varying resource requirements and scaling needs.
  5. No Dedicated Ops Team: For teams that don’t have dedicated operations or infrastructure teams, Fargate abstracts away many of the complexities of managing a containerized infrastructure.
  6. Short-lived Tasks or Batch Processing: For tasks that are ephemeral or are part of batch processing jobs, where you don’t need long-running instances or nodes, Fargate can be a suitable choice.
  7. Rapid Prototyping: When you want to quickly deploy and test applications without worrying about the underlying infrastructure, Fargate can expedite the process.
  8. Hybrid Deployments: If you’re using both ECS with EC2 and Fargate launch types, you can manage tasks running on both types of infrastructure within the same ECS cluster.
  9. EKS Integration: If you’re using Amazon’s managed Kubernetes service (EKS) and want to mix traditional EC2-backed pods with serverless pods, Fargate for EKS can be helpful.

However, there are also scenarios where Fargate might not be the best choice:

  1. Highly Customized Environments: If you need a high degree of customization of your environment (like specific kernel tweaks), a traditional EC2 environment might be better.
  2. Dedicated Performance: For applications that require dedicated, high-performance hardware, directly provisioning EC2 instances can be more appropriate.
  3. Cost Concerns: While Fargate abstracts away many complexities, it might be more expensive than managing your own EC2 instances, especially for predictable and steady workloads.

It’s crucial to analyze your application’s requirements, cost constraints, and management preferences when deciding to use AWS Fargate.

Example Reference Architectures –

ITS adopts microservices architecture for improved air travel search engine <1>

Figure 1. ITS’ microservice architecture, using AWS

Genomics workflows, Part 4: processing archival data <2>application’s

Figure 1. Solution architecture for S3 Glacier object restore

  1. ITS adopts microservices architecture for improved air travel search engine
  2. Genomics workflows, Part 4: processing archival data

Discover more from CloudTechVibe

Subscribe to get the latest posts sent to your email.