AWS Summit New Delhi : Serverless and Container: Better together?

AWS Containers with and without Serverless

In this post, we'll look at how Serverless may be used in conjunction with Containers to make deploying and operating your containers more efficient and straightforward.

Containerized cloud deployments have grown popular among businesses because they give the full value of digital transformation through unrivaled agility and flexibility.

All cloud service providers offer a variety of containerized workload-specific services, such as Kubernetes services(EKS), container registry services(ECR), and serverless compute engines. Managed services based on K8s and serverless technologies enable enterprises to focus on applications and innovation rather than hosting environment setup and maintenance.

Amazon Web Services' managed Kubernetes offering is Elastic Kubernetes Service (EKS). This solution automates K8s control plane deployment, update management, patching, node provisioning, and other administrative tasks. Clients can now focus on constructing and delivering their applications to the cluster.

AWS Fargate takes a step further by providing a serverless hosting option for containers that can be connected to EKS. In this article, we'll examine the features of AWS Fargate and how it integrates with EKS to host serverless pods.

AWS Fargate

With AWS Fargate customers don't need to worry about setting up and managing servers to deploy containers. It can be connected to both ECS and EKS in order to run the workloads. Overprovisioning and waste are prevented by just providing the computing resources required to run the containers.

This deployment strategy is tailored to guarantee that you only pay for the resources used by the application. Through Fargate Spot and calculate savings schemes, costs may also be decreased. For workloads that can withstand interruptions, these savings may reach 70%, while for persistent workloads, they could reach 50%.

As needed by Fargate, the backend infrastructure for hosting the containers is built and kept up to date using patches. All infrastructure upkeep tasks, including as patching, scalability, and environment security, are isolated from users, removing any related operational costs.

Because they operate in separate kernel runtime environments and don't share any resources with other pods, the pods deployed in Fargate are secure. With Amazon's CloudWatch Container Insights service, observability into the container runtime metrics and application logs is offered right out of the box.

Container Services: EKS and ECS

Elastic Kubernetes Service (EKS):

EKS is an open source Kubernetes-based container deployment service. A Kubernetes distribution or Kubernetes-as-a-Service are other names for it.

Elastic Container Engine (ECS):

Amazon created a proprietary container orchestration engine that supports ECS, a container deployment service. AWS released ECS during the "orchestrator wars" era, before it was evident that Kubernetes would swiftly surpass all other container orchestration solutions.

Managed Nodes vs Autoscaling vs Fargate

You might be asking yourself at this point, "Can't I just configure Autoscaling or utilize EKS controlled node groups if I don't want to have to manage the infrastructure that hosts containers running on EKS (or ECS)?"

The answer is “basically, yes.” Both EKS and ECS can be setup with autoscaling, which allows you to instruct AWS to automatically scale your container host infrastructure up or down. Furthermore, managed node groups, a feature that automates node provisioning and lifecycle management, are available on EKS.

Autoscaling and managed node groups are quite similar to Fargate. However, there are significant differences:

• Setup: With autoscaling, you must still setup the baseline infrastructure. Fargate completely removes the installation procedure.
• Control: Autoscaling allows you to have greater control over how scaling is handled. AWS handles all scalability in Fargate mode on its own.
• Price: While there is no charge for using EKS autoscaling and managed nodes, the EKS pricing structure differs from Fargate's.
• Support: Fargate and EKS managed node group support vary per AWS region. Before configuring them, be sure your region (or regions) supports the deployment mode you intend to employ.

Example of EKS with and without Serverless(Fargate):

Let's look at three basic cluster building examples to see how EKS with and without Fargate differs.

EKS in Standard Mode: No Autoscaling

To set up an EKS cluster in standard mode, that is, without Fargate, managed node groups, or autoscaling, you must specify how many nodes to construct when configuring the cluster with an eksctl command such as:

eksctl create cluster --name=cluster-1 --nodes=2

This process is simple enough, but keep in mind that we have to decide on the size of the cluster ahead of time. You may always go in and manually add or delete nodes later, but this is less desirable than defining the desired cluster size from the start.

EKS in Standard Mode: Autoscaling

To setup autoscaling, use the -nodes-min and -nodes-max flags to indicate the range of the cluster size you wish to configure, just as in other AGS. As an example:

eksctl create cluster --name=autocluster-2 --nodes-min=2 --nodes-max=4

With autoscaling enabled, we can be more certain that our cluster size will match workload requirements even as they vary. Nonetheless, we had to make an explicit decision regarding the size of the cluster from the start.

EKS: Managed Nodes

If no node count is specified, your EKS clusters will use managed node groups. As an example:

eksctl create cluster --name mycluster-3 --region region-code

That was rather simple. We let EKS decide how big our cluster should be. The disadvantage, of course, is that we give over cluster management to AWS, giving us less control.

EKS: Fargate

To create a cluster for use with Fargate mode, we use the –fargate flag:

eksctl create cluster --name fargatecluster-4 --region region-code --fargate

That was also pretty simple. The limitation is that we do not have explicit control over cluster scalability. Furthermore, this cluster's invoicing will be based on Fargate pricing.

When to use Fargate

Now that you're familiar with the numerous ways for working with EKS, consider the primary elements that often determine when and when not to use Fargate mode.

Security

Fargate-deployed containers are slightly more secure in some ways since they run within dedicated virtual machines. This kind of isolation will not prevent all risks, but it will help.

The fact that Fargate does not allow privileged mode is actually a security benefit, since it prevents you from running privileged containers.

On the other side, the increased control provided by EKS in standard mode may result in improved security.

Control on Clusters

Fargate reduces your control in a variety of ways. Not only do you not have control over cluster sizing, but you also cannot provide configuration variables like HostPort and HostNetwork for Fargate mode containers. You can't additionally run containers in privileged mode or setup DaemonSets.

Fargate makes the most sense when you don't require fine-grained control over how your containers run. Use EKS in standard mode if you need as much control as possible.

Availability

As previously stated, Fargate support varies per AWS region. It is also not available if AWS Outposts or EKS Anywhere are used. In some circumstances, your overall AWS deployment approach will affect whether or not you may use Fargate.

Cost

As previously stated, regular EKS and Fargate have separate price schedules. The actual charges vary depending on the AWS location and workload type. If you utilize standard EKS, whether Fargate or regular EKS is more cost effective is primarily determined by how proficient you are at establishing the proper cluster size.

In general, Fargate is less expensive in the long term if you don't do a good job setting EKS autoscaling or if your workload scales up and down dramatically on a regular basis. However, regular EKS will likely cost less for workloads that do not require frequent scaling or when you carefully rightsize your cluster based on cost and performance requirements.

Convenience

Fargate is the obvious choice if simplicity and ease of use are your main priorities. EKS in ordinary mode isn't difficult to operate, although it takes more work than Fargate mode.

Conclusion

There is no decision that is inherently right or wrong when deciding between EKS in normal mode and EKS in Fargate mode(Serverless). To choose whether or not to utilize Fargate with EKS, you must carefully consider the sorts of workloads you are deploying, their scaling needs, and the degree of management effort you are willing to put out.