Life before containerization was a sore spot for developers. The satisfaction of writing code was constantly overshadowed by the frustration of attempting to force code into production. For many, deployments meant hours of reconfiguring libraries and dependencies for each environment. It was a tedious process prone to error, and it led to a lot of rework.
Today, developers can deploy code using new technology such as cloud computing, containers, and container orchestration. This guide discusses each of these technologies. It will also answer the question: “What are the differences between Elastic Beanstalk, EKS, ECS, EC2, Lambda, and Fargate?”
- AWS Cloud Computing Concepts
- Elastic Beanstalk
- Elastic Kubernetes Service (EKS)
- Elastic Container Service (ECS)
- Elastic Compute Cloud (EC2)
- Comparing Services
AWS Cloud Computing Concepts
Cloud computing refers to accessing IT resources over the internet. Resources include things such as servers, storage, deployment tools, and applications. The AWS term for cloud computing is “compute,” which refers to virtual servers where developers place their code. In AWS, developers choose the specifications for their server, such as:
- Operating system
Cloud computing offers several benefits, including:
- Cost Savings: Companies won’t need to purchase servers to run their applications.
- Time Savings: Developers don’t need to worry about managing the servers. The cloud computing vendor handles all maintenance tasks.
- Security: The cloud vendor implements and manages all security tasks for the resources.
- Scalability: Resources are accessed on demand. If the developer needs more resources, the cloud computing platform can automatically allocate whatever is required.
- Flexibility: Developers can choose configuration options best suited to their needs.
- Reliability: Computing vendors provide an availability guarantee (usually 99.99%) to ensure applications are always available.
Containerization refers to a process of packaging code into a deployable unit. This unit is called a container, and it holds everything needed to run that code. From the application’s code to the dependencies and OS libraries, each unit contains everything the developer needs to run their application. The most widely known container technology is Docker, an open-source tool with broad community support. The benefits of containerization include:
Easier Application Deployment
Application deployment is one of the most basic yet effective benefits. With containers, developers have a much easier time deploying their applications because what once took hours now takes minutes. In addition, developers can use containers to isolate applications without having to worry about them affecting other applications on the host server.
Better Resource Utilization
App containers allow for greater resource utilization. One of the main reasons people deploy containers is because it enables them to use fewer physical machines. If someone has many applications running on a single machine, they will often find that it results in the under-utilization of one or more applications.
Containerization helps deal with this problem by allowing developers to create an isolated environment for each application. This approach ensures that each app has the resources to run effectively without impacting others on the same host. It also reduces the chance of introducing malicious code into production.
Containers provide a lightweight abstraction layer, allowing developers to change the application code without affecting the underlying operating system. Plus, the isolation attributes for applications in a container ensure that the performance of one container won’t affect another.
One of the most significant benefits of app containerization is that it provides a way to isolate applications. This is especially important when hosting multiple applications on the same server.
Containerization also simplifies deployment and updates by making them atomic. With containers, developers can update an application without breaking other applications on the same server. Containers also allow developers to deploy an updated version and roll it back if necessary. As a result, developers can quickly deploy and update their applications and then scale them without downtime or unexpected issues.
Since containers isolate applications from one another and the host system, vulnerabilities in one application won’t affect other apps running on the same host. If developers find a vulnerability, they can address it without impacting other applications or users on the same server.
Images are templates used to create containers, and they are made from the command line or through a configuration file. The file is a plain text file that contains a list of instructions for creating an image. The file’s instructions can be simple, such as pulling an image from the registry and running it, or they can be complex, such as installing dependencies and then running a process.
Images and containers also work together because a container is what runs the image. Although images can exist without containers, a container requires an image to run. Putting it all together, the process for getting an image to a container and running the application is as follows:
- The developer codes the application.
- The developer creates an image (template) of the application.
- The containerization platform creates the container by following the instructions in the configuration file.
- The containerization platform launches the container.
- The platform starts the container to run the application.
As applications grow, so does the number of containers. Manual management of a large number of containers is nearly impossible, so container orchestration can step in to automate this process. The most widely known container orchestration tool is Kubernetes. Amazon offers services to run Kubernetes, which we’ll discuss later in the article. Docker also provides orchestration via what is known as Docker Swarm.
How Does Containerization Work?
The first step in the process is creating a configuration file. The file outlines how to configure the application. For instance, it specifies where to pull images, how to establish networking between containers, and how much storage to allocate to the application. Once the developer completes the configuration file, they deploy the container by itself or in clusters. Once deployed, the orchestration tool takes over managing the container.
After container deployment, the orchestration tool reads the instructions in the configuration file. Based on this information, it applies the appropriate settings and determines which cluster to place the container. From there, the tool manages all of the below tasks:
- Provisioning containers
- Configuring applications
- Lifecycle management
- Managing redundancy and availability
- Allocating resources
- Load balancing
- Service discovery
- Health monitoring of containers
Now, we move to a discussion of the differences between Elastic Beanstalk, EKS, ECS, EC2, Lambda, and Fargate.
Continuing from the discussion above, Elastic Beanstalk takes simplification one step further. Traditionally, web deployment also required a series of manual steps to provision servers, configure the environment, set up databases, and configure services to communicate with one another. Elastic Beanstalk eliminates all of those tasks.
Elastic Beanstalk handles deploying web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on servers such as Apache, Nginx, Passenger, and IIS.
The service automatically provisions servers, compute resources, databases, etc., and deploys the code. That way, developers can focus on coding rather than spending countless hours configuring the environment.
Elastic Beanstalk Architecture
When deploying an app on Elastic Beanstalk, the service creates the following:
- Elastic Beanstalk Environment: This is the runtime environment for the application. The service automatically creates a URL for access to the application and a CNAME.
- EC2 Instances: These are the compute nodes for the application.
- Autoscaling Group: It handles scaling the compute nodes. Although the autoscaling group handles provisioning, developers can configure how many to establish. They can also specify when autoscaling can start.
- Elastic Load Balancer: It distributes web requests across the compute nodes.
- Security Groups: Specifies what network traffic is allowed in and out of the application.
- Host Manager: The host manager is a service on each compute node that monitors the node for performance issues.
When web requests take too long to process, performance suffers. Elastic Beanstalk creates a background process that handles requests to avoid overloading the server. Worker Environments, a separate set of compute resources, process longer running tasks to ensure the resources serving the website can continue to respond quickly.
Elastic Kubernetes Service (EKS)
Containerization eliminates a tremendous burden from the developers. However, there’s an additional challenge they face: provisioning, scaling, configuring, and deploying containers. Depending on the size of the application, manually handling these tasks is overwhelming. The solution? Container orchestration.
Amazon EKS is a managed Kubernetes service that helps developers easily deploy, maintain, and scale containerized applications at a massive scale. Amazon EKS replaces the need for manual configuration and management of the Kubernetes components, simplifying cluster operations.
What Is Kubernetes?
Kubernetes is an open-source containerization platform that automatically handles all tasks associated with managing containers at scale. Kubernetes is also known as K8s, and it does the following:
- Service Discovery: Kubernetes exposes containers to accept requests via Domain Name Service (DNS) or an IP address.
- Load Balancing: When container resource demand is too high, Kubernetes routes requests to other available containers.
- Storage Orchestration: As storage needs grow, K8s mounts additional storage to handle the workload.
- Self-Healing: If a container fails, Kubernetes can remove it from service and replace it with a new one.
- Secrets Management: The tool stores and manages passwords, tokens, and SSH keys.
The Amazon EKS infrastructure comprises several components that interact to perform container orchestration. Specifically, EKS architecture consists of:
The master nodes are responsible for several tasks, including scheduling containers on worker nodes based on resource availability and CPU/memory limits.
EKS Control Plane
The control plane manages Kubernetes resources and schedules work to run on worker nodes. It includes the API Server, which handles communication with clients (e.g., kubectl), and an API server process that runs one or more controller-type operations in a loop to supervise work.
EKS Worker Nodes
Worker nodes run on EC2 instances in a VPC. A cluster is a group of worker nodes that run the application’s containers, while the control plane manages and orchestrates work between worker nodes. Organizations can deploy EKS for one application, or they can use one cluster to run multiple applications.
Worker nodes run on EC2 instances in the company’s virtual private cloud to execute the code in the containers. These nodes consist of a Kubelet Service and the Kube-proxy Service.
- Kubelet Service: The Kubelet Service runs on the cluster and handles communication between clusters. It waits to receive instructions from the API server and executes those instructions.
- Kube-proxy Service: The Kube-proxy Service establishes and configures communication between services within the cluster.
EKS VPC: Virtual Private Cloud
This is a service to secure network communication for the clusters. Developers use the tool to run production-grade applications within a VPC environment.
Elastic Container Service (ECS)
ECS is an AWS proprietary container orchestration service. It is a fully managed service for running Docker containers on AWS, and it integrates with other AWS services, such as Amazon EC2, Amazon S3, and Elastic Load Balancing. Although ECS is similar to EKS, ECS does not automate the entire process.
The main components of ECS are:
ECS containers are pre-configured Linux or Windows server images with the necessary software to run the application. They include the operating system, middleware (e.g., Apache, MySQL), and the application itself (e.g., WordPress, Node.js). You can utilize your own containers that have been uploaded to AWS’s Elastic Container Registry.
An ECS Container Agent is a daemon process that runs on the EC2 instance and communicates with the ECS service. It does this by using the AWS CLI to send API requests and Docker commands. To use an ECS Container Service, a user needs to have at least one container agent running on an EC2 instance in the VPC. This agent communicates with the ECS service by calling the AWS API and Docker commands to deploy and manage containers.
An ECS task is a pairing of container image(s) and configurations. These are what run on the cluster.
An ECS cluster is a group of EC2 instances that run containers. ECS automatically distributes containers among the available EC2 instances in the cluster. ECS can scale up or down as needed. When creating a new Docker container, the developer can specify CPU share weight and a memory weight. The CPU share weight determines how much CPU capacity each container can consume relative to other containers running on the same node. The higher the value, the more CPU resources will be allocated to this container when it runs on an EC2 instance in the cluster.
Task Definition File
Setting up an application on ECS requires a task definition file. The file is a JSON file that specifies up to 10 container definitions that make up the application. Task definitions outline various items, such as which ports to open, which storage devices to use, and specify Access Management (IAM) roles.
The ECS Task Scheduler handles scheduling tasks on containers. Developers can set up the ECS Task Scheduler to run a task at a specific time or after a given interval.
Elastic Compute Cloud (EC2)
EC2 provides various on-demand computing resources such as servers, storage, and databases that help someone build powerful applications and websites.
The EC2 architecture consists of the following components:
Amazon Machine Image (AMI)
An AMI is a snapshot of a computer’s state that can be replicated over and over allowing you to deploy identical virtual machines.
An AWS EC2 location is a geographic area that contains the compute, storage, and networking resources. The list of available locations varies by AWS product line. For example, regions in North America include the US East Coast (us-east-1), US West Coast (us-west-1), Canada (ca-central-1), and Brazil (sa-east-1).
Availability Zones are separate locations within a region that are well networked and help provide enhanced reliability of services that span more than one availability zone.
What Type of Storage Does EC2 Support?
EBS – Elastic Block Storage
These are volumes that exist outside of the EC2 instance itself, allowing them to be attached to different instances easily. They persist beyond the lifecycle of the EC2 instance, but as far as the instance is concerned, it seems like a physically attached drive. You can attach more than one EBS volume to a single EC2 instance.
EC2 Instance Store
This is a storage volume physically connected to the EC2 instance. It is used as temporary storage and it cannot be attached to other instances and the data will be erased upon the instance being stopped, hibernated, or terminated.
AWS Lambda is a serverless computing platform that runs code in response to events. It was one of the first major services that Amazon Web Services (AWS) introduced to let developers build applications without any installation or up-front configuration of virtual machines.
How Does Lambda Work?
When a function is created, Lambda packages it into a new container and executes that container on an AWS cluster. AWS allocates the necessary RAM and CPU capacity. Because Lambda is a managed service, developers do not get the opportunity to make configuration changes. The tradeoff means developers save time on operational tasks. Additional benefits are:
Security and Compliance
AWS Lambda offers the most security and compliance of any serverless computing platform. It meets regulatory compliance standards like PCI, HIPAA, SOC2, and ISO 27001. Lambda also encrypts all data in transit and at rest with SSL/TLS certificates.
The service scales applications without downtime or performance degradation by automatically managing all servers and hardware. With Lambda, a company will only pay for the resources used when the function runs.
Cost efficiency is one of the most significant benefits of AWS Lambda because the platform only charges for the computing power the application uses. So if it’s not being used, Lambda won’t charge anything. This flexibility makes it a great option for startups or businesses with limited budgets.
Leveraging Existing Code
In some cases, existing code can be used as is, such as a flask application, with very little adaptation.
Lambda also lets you create layers, which are often dependencies, assets, libraries, or other common components that can be accessed by the Lambda function to which they are attached.
The Lambda architecture has three main components: triggers, the function itself, and destinations.
Event producers are the events that trigger a Lambda function. For example, if a developer wants to create a function to handle changes in an Amazon DynamoDB table, they’d specify that in the function configuration.
There are many triggers provided by AWS, like the DynamoDB example above. Other common triggers would include handling requests to an API Gateway, an item being uploaded to an S3 bucket, and more. A Lambda function can have multiple triggers.
Lambda functions are pieces of code that can be registered to execute or respond to an event. AWS Lambda manages, monitors, and scales the code execution across multiple servers. Developers can write these functions in any programming language and make use of additional AWS services such as Amazon S3, Amazon DynamoDB, and more.
AWS Lambda operates on a pay-per-use basis, with a free tier that offers 1 million requests per month. Developers only pay for what they use instead of purchasing capacity upfront. This pay-per-use setup supports scalability without paying for unused capacity.
When execution of a Lambda function completes, it can send the output to a destination. As of now, there are four pre-defined destinations:
- An SNS topic
- An SQL queue
- Another Lambda Function
- An EventBridge Event bus
Discussing each of those in detail is beyond the scope of this article.
If the code and its dependencies is sized at 10MB or over Lambda functions need to be packaged before they can run.
There are two types of packages that Lambda accepts, .zip archives and container images.
.zip archives can be uploaded in the Lambda console. Container Images must be uploaded to Amazon Elastic Container Registry.
When a function executes, the AWS container that runs it starts automatically. Once the code executes, the container shuts down after a few minutes. This functionality makes functions stateless, meaning they don’t retain any information about the request once it shuts down. One notable exception is the /tmp directory, the state of which is maintained until the container shuts down.
Use Cases for AWS Lambda
Despite its simplicity, Lambda is a versatile tool that can handle a variety of tasks. Using Lambda for these items keeps the developer from having to focus on administrative items. The tool also automates many processes for an application that a developer would normally need to write code for. A few cases are:
When the application uses S3 as the storage system, there’s no need to run a program on an EC2 instance to process objects. Instead, a Lambda event can watch for new files and either process them or pass them on to another Lambda function for further processing. The service can even pass S3 object keys from one Lambda function to another as part of a workflow. For example, the developer may want to create an object in one region and then move it to another.
Handling External Service Calls
Lambda is a perfect fit for working with external services. For example, an application can use it to call an external API, generate a PDF file from an Excel spreadsheet, or send an email. Another example is sending requests for credit reports or inventory updates. By using a function, the application can continue with other tasks while it waits for a response. This design prevents external calls from slowing down the application.
Automated Backups and Batch Jobs
Scheduled tasks and jobs are a perfect fit for Lambda. For example, instead of keeping an EC2 instance running 24/7, Lambda can perform the backups at a specified time. The service could be used to also generate reports and execute batch jobs.
Real-Time Log Analysis
A Lambda function could evaluate log files as the application writes each event. In addition, it can search for events or log entries as they occur and send appropriate notifications.
Automated File Synchronization
Lambda is a good choice for synchronizing repositories with other remote locations. With this approach, developers can use a Lambda function to schedule file synchronization without needing to create a separate server and process.
AWS Fargate is a deployment option of ECS and EKS and doesn’t require managing servers or clusters. With Fargate, users simply define the number of containers and how much CPU and memory each container should have.
AWS Fargate Architecture
Fargate’s architecture consists of clusters, task definitions, and tasks. Their functions are as follows.
AWS Fargate Clusters are a cluster of servers that run containers. When developers launch a task, AWS provisions the appropriate number of servers to run the container. Developers can also customize Docker images with software or configuration changes before launching them as a task on Fargate. Then, AWS manages the cluster for the user, making it easy to scale up or down as needed.
A task represents an instance of a task definition. After creating the task definition file, the developer specifies the number of tasks to run in the cluster.
What Are the Benefits of Fargate?
Fargate is easy to use. Deploying an application involves three steps:
- Configure the app’s environment.
- Describe the desired state of the app.
- Launch the app.
AWS Fargate supports containers based on Docker, AWS ECS Container Agent, AWS ECS Task Definition, or Amazon EC2 Container Service templates. The service automatically scales up or down without needing any changes to the codebase. Fargate has many benefits, which include:
- An easy, scalable, and reliable service
- No server management required
- No time spent on capacity planning
- Scale seamlessly with no downtime
- Pay-as-you-go pricing model
- A low latency service, making it ideal for data processing applications
- Integration with Amazon ECS, making it easier for companies to use both services in tandem
The beauty of AWS is the flexibility it offers developers thanks to multiple options for containerization, orchestration, and deployment. Developers can choose which solution best meets their needs.
However, with so many options, it can be difficult to know which option to use. Here are a few tips on how to decide between a few of these services.
Elastic Beanstalk vs ECS
Elastic Beanstalk and ECS are both containerization platforms, but the degree of control available is one key difference between them. With Beanstalk, the developer doesn’t need to worry about provisioning, configuring, or deploying resources. They simply upload their application image and let Elastic Beanstalk take care of the rest. ECS, on the other hand, provides more control over the environment.
Which Option Is Best?
ECS gives developers fine-grained control over the application architecture. Elastic Beanstalk is best when someone wishes to use containers but wants the simplicity of deploying apps by uploading an image.
ECS vs EC2
AWS ECS is a container orchestration service that makes deploying and scaling containerized workloads easier. The Elastic Container Service supports Amazon Fargate launch types. With AWS EC2, users don’t have to configure or manage their container management as AWS runs and manages containers in a cloud cluster.
Example Scenario: Moving From ECS to EKS
There may be times when a developer wants to migrate from one service to another. One example might be migrating from ECS to EKS. Why would they want to do this? As we mentioned, ECS is proprietary to AWS, with much of the configuration tied to AWS. EKS runs Kubernetes, which is open source and has a large development community. ECS only runs on AWS, whereas K8s (that runs on EKS) can run on AWS or another cloud provider.
Transitioning to EKS gives developers more flexibility to move cloud providers. It is possible to move existing workloads running on ECS to EKS without downtime by following these steps:
- Export the ECS cluster to an Amazon S3 bucket using the ecs-to-eks tool.
- Create a new EKS cluster using the AWS CLI, specifying the exported JSON as an input parameter.
- Use kubectl to connect to the new EKS cluster and use a simple script to load the exported containers from S3 into the new cluster.
- Start scaling applications with AWS elbv2 update-load-balancers command and aws eks update-app command or use AWS CloudFormation templates for this purpose (see an example here).
- Once the user has successfully deployed the application on EKS, they can delete the old ECS cluster (if desired).