Overview#

In this tutorial, we'll be taking a deep dive into the differences between AWS Lambda and AWS ECS. We'll be setting up sample applications using each of those and then contrasting the different use cases they have.

What is AWS Lambda#

Lambda uses resources that are the same that a server-driven deployment would've given us - EC2 instances, coupled with load balancers, security groups, auto-scaling services. However, unlike the latter, these resources are configured entirely on the backend, away from the user, and automatically scaled up/down as per traffic. All the user needs to do is provide the code, and let Lambda take care of ensuring it runs.

The following Block diagram describes how lambda works

What is ECS#

ECS stands for Elastic Container Service and is a container orchestration solution - meaning, it allows deployment and management of applications which are containerized using tools like Docker.

The following block diagram gives an explanation of how it all comes together

What is AWS Fargate#

We'll be using AWS Fargate in our ECS example. Fargate is a serverless, pay-as-you-go compute engine that lets you focus on building applications without managing servers. Unlike EC2, you don't actually have to worry about setting up and provisioning the servers. You only provide a containerized application, and Fargate handles the hosting based on the resources you require

Setting up Lambda#

Go to aws.amazon.com and sign up for an account if you don't already have one.

Once you're signed in, search 'Lambda' in the search bar. You should be redirected to the Lambda dashboard

Before you create a Lambda function, you need to identify its inputs and triggers, choose a runtime environment, and decide what permissions and role the service will use.

Lambda functions accept JSON input and JSON output. Your function’s input and output contents are closely tied to the event source that will trigger your function.

An event source is usually a web request, that'll cause the execution of the function code

You also need to select a runtime for your function. We'll be using Node.js

Finally, your function will need an AWS role, that defines the entitlements the function has within the AWS platform.

Click on Create function

Keep the default 'Author from scratch' option selected

Give your function a name as you wish, and leave everything else as it is.

Click on Create function at the bottom of the page

You'll be redirected to the function configuration page, that looks something like this

You'll first have to add a trigger for your lambda function. Click on add trigger.

You'll then be asked to choose a trigger - select API Gateway. An API Gateway essentially lets you create, deploy and monitor APIs. In our case, we'll be able to use our function like an API - when we hit the deployed URL, it'll trigger our function.

Choose API type as REST API, security as Open, and leave the rest as it is. Finally, click Add

You'll see that the trigger is added.

Next, you are given a code source window with an integrated code editor, where you can add/edit code and files.

A sample code snippet is provided. You can choose to modify the message to something you wish, and keep the rest of the code as it is for now.

Testing the function#

Next, we'll test if the function works as expected. Go to the test tab.

Here, you're given an option to create an event. An event is a happening that triggers the function. It has a JSON input. Since we're not actually using the input in any way, it's not much to us. However, when the lambda function is deployed as a service to some application, there'll be inputs coming in that the function will use. Those inputs can be given here to test if they give the required outcome.

Leave everything unchanged, and click Test.

It'll run the test using the event config, and will pass with the following message in a second or two.

Understanding the result#

The details show the function output. In our case, the status code and the message body.

The summary tab has a few important fields. The duration denotes the time it took for the lambda to run, which is an important pointer when we are running a production grade application and are likely to get timeout/performance issues

The billed duration is another important indicator - you only pay for what you use. Unlike the EC2 instance, where you were charged for the server just being on, irrespective of whether or not anything was running on it, Lambda only charges you for the times your function runs. Thus, being an obvious cost advantage

And the field one of the most significant to our discussion - Resources configured. 128 MB in our case. Do you remember configuring anything at all, apart from the function code itself? Nope. So where did the 128 MB come from? That's the magic - by just telling Lambda what code you need to run, it automatically provisions the resources needed to run it, saving considerable bandwidth of the developers that would've otherwise gone in getting the servers configured.

Deploying the Lambda function#

Go back to the code tab, and click on Deploy

Now, click on API Gateway in Function Overview.

It'll give you the API endpoint. Copy it, and paste it in a new browser tab.

Sure enough, you'll see the learning lambda message on the screen.

Come back to the lambda dashboard and go to the monitor tab. Here, you'll be able to monitor the calls being made to your API. Refresh the page of the API a few times, and you'll see the requests being shown on the graphs

Notice the usefulness of the graphs - The invocations show you how many times the API was invoked.

The error count and success rate let you track if the function is facing downtime/run time errors.

Setting up ECS#

Next, we'll setup and configure an ECS application using AWS Fargate

Go to AWS dashboard and search for ECS. You'll be taken to the ECS dashboard, that looks like this

Click on Get Started

We'll be selecting an Nginx container

Next, you'll be prompted to add a service, which ensures that the defined task instances are maintained. If not, a new task instance is created.

Next, you'll be asked to configure your cluster details - keep them as they are.

Finally, click create.

You can see the status of the resources being provisioned :

Finally, your service will be active

Go to task definitions

Copy the public IP and paste it in a new browser tab

You'll see that the default nginx screen opens up

Refresh it a few times

Come back to the ECS dashboard and go to logs. You'll see that for every refresh, a log entry is created

Difference between Lambda and ECS#

Thus, you created and deployed sample services using both Lambda and ECS(via Fargate).

At the first glance, these two look similar - both of them are serverless solutions that configure the server resources based on the configuration that your application needs, and work on a pay-per-use model. They both also provide monitoring and logs in a similar fashion

However, there are a few subtle differences - Lambda essentially allows you to run tiny functions -they can of course be as gigantic as applicaations themselves, but that's not what it's meant for. Isolated services that can then be plugged into existing applications via triggers like the API Gateway we used ensure that your services work in isolation, and the downtime of one doesn't affect the other.

ECS is a container orchestrator, and is principally meant for running 'containerized applications'. There's some configuration needed for you to define when setting up the resources, where in Lambda, it was handled in its entirety by AWS itself. ECS is mainly meant for larger applications but with a flexibility of not having to manage compute instances yourself.

Consider Lambda over ECS when#

• You have a smaller application that runs on-demand in 15 minutes or less.

• You don’t need advanced EC2 instance configuration. Lambda manages, provisions, and secures EC2 instances for you, along with providing target groups, load balancing, and auto-scaling. It eliminates the complexity of managing EC2 instances.

• You want to pay only for capacity used. Lambda charges are metered by milliseconds used and the number of times your code is triggered. Costs are correlated to usage. Lambda also has a free usage tier.

Consider ECS over Lambda when#

• You are running Docker containers. While Lambda now has Container Image Support, ECS is a better choice for a Docker ecosystem, especially if you are already creating Docker containers.

• You want flexibility to run in a managed EC2 environment or in a serverless environment. You can provision your own EC2 instances or Amazon can provision them for you. You have several options.

• You have tasks or batch jobs running longer than 15 minutes. Choose ECS when dealing with longer-running jobs, as it avoids the Lambda timeout limit above.

• You need to schedule jobs. ECS provides a service scheduler for long running tasks and applications, along with the ability to run tasks manually.

Conclusion#

Thus, in this tutorial, you got an introduction to AWS Lambda, AWS ECS and Fargate. You understood the similarities among them by setting up sample applications using each. You then created distinctions between them, and hands on checklists as to when one would be preferred over the other

References#

• AWS ECS

• AWS Fargate