Recap of compute services

In a nutshell:

Use EC2 for traditional applications with full OS access.

Use containers for applications with a microservices architecture; choose between ECS or EKS for container orchestration, and choose between EC2 or Fargate for running the containers

Use AWS Lambda for event-driven, serverless functions.

At this point, you've covered a few different AWS compute services. It cane be quite overwhelming to learn so many new concepts, so let's recap and play a fun game!

By the end of this recap, you'll feel much more confident about when to use each compute service.

We will present three different use cases that require compute on AWS, and it's up to you to choose the right service for the use case.

Ready? Let's go!

Scenario One

SET THE SCENE

Consider a scenario where you are a developer who is tasked with creating a new feature for a web application being hosted on EC2:

• The web app is an online store.
• All the items being sold in the store are loaded into a database manually behind the scenes. There is a person who adds a new row to a database for each new item to be sold in the store.
• This process takes a long time, isn't very scalable, and is prone to error.
• New inventory gets updated once a quarter.

YOUR TASK

Automate the process of getting the new item information loaded into the inventory database.

YOUR GOAL

To have a person upload an inventory spreadsheet into Amazon S3, your object storage service, then have a process automatically load the data into the inventory database.

What compute would you use to host the processing logic* to load the items from the spreadsheet into the database?

*Processing logic = the set of instructions or code that specifies how this task is done.

Pause here now. What do you think?

.

.

.

.

.

Promise us you've paused and had a proper think about this!

.

.

.

.

.

(Pinky promise)

.

.

.

Are you ready? The answer is right under this line!

You could have decided to use Amazon EC2 here. It's possible.

• You could spin up a new instance specifically for this process and write some code that finds the location of the spreadsheet for a new upload every so often.
• BUT Amazon EC2 charges per second or per hour. So if you have an instance running all the time to serve requests that happens once per quarter (since inventory only gets uploaded once a quarter), you would be spending money on a resource you rarely use. It certainly would work, but it may not be the best fit for this use case.

AWS Lambda is the correct answer for this one.

• Lambda only charges you for the compute you consume when the code is actually running.
• Code is only run in response to triggers or a direct invitation.
• Lambda integrates with many AWS services to act as triggers, and Amazon S3 is one of them.
• That means you can create an AWS Lambda function, configure the trigger from Amazon S3.
• Now when inventory is uploaded, Amazon S3 will trigger the Lambda function to run and automatically add inventory into your database.

Scenario Two

SET THE SCENE

Let's say you have an application hosted in your on-premises data centre. It's currently running on Linux servers in the data centre.

YOUR TASK

Migrate the on-premise data centre onto AWS.

YOUR GOAL

You want to minimise the amount of refactoring* needed to migrate to AWS. It's important that this workload is elastic and can support different levels of demand.

*Refactoring = making significant changes to the code to adapt it for a new environment or platform. It's like remodelling a house to fit new furniture or appliances – in this case, it's about modifying the software to fit the AWS platform.

What compute option would you choose?

Time to pause!

.

.

.

.

.

.

(pinky promise you've had a think about this)

.

.

.

.

.

Are you ready? The answer is right under this line!

Considering the fact that minimising refactoring is important, the best option is Amazon EC2.

• EC2 instances can be launched from Linux-based AMIs.
• The application could be hosted on the EC2 instance, the same way it would be hosted on a Linux server on premises.
• EC2 also has the ability to scale in or out based on demand.

AWS Lambda could work, but you can't just upload the same code you would run on EC2 into a Lambda function. There would have to be a decent amount of refactoring to take advantage of that service. Same idea with any of the AWS container services, like ECS or EKS. You'd have some amount of rework required to migrate to containers. Since minimising refactoring is your goal, EC2 is the best option.

Scenario Three

YOUR TASK

You are planning to write a brand-new application using a microservices design.

YOUR GOAL

1. You want to architect the application where it can scale up or down quickly
2. You want to lower the risk of deploying new changes to production.

Which AWS compute service would you use?

Time to pause!

.

.

.

.

.

.

(pinky promise you've had a think about this)

.

.

.

.

.

Are you ready? The answer is right under this line!

One of the AWS container services like Amazon ECS or Amazon EKS is best for this.

• Using containers makes it easier to support microservice or service-oriented designs.
• Containers boot up quickly, so scaling is quicker than EC2 instances
• The use of containers helps with code portability. Meaning, if you write the code on your laptop and run it in a container, then test it in a container, you can then expect the same container to behave the same way once deployed to production. This reduces the risk of deployments causing errors because of environmental issues.

And that's a wrap!

As we're well aware now, AWS offers a brand range of compute offerings - virtual machines (VMs), containers, and serverless.

Remember that these services exist to best suit different use cases helps.

Don't try to use the same compute service for all of your use cases. Instead, pick the right one for the job, and consider reevaluating choices for existing workloads as AWS continues to release and improve offerings.

• Use EC2 if you are trying to host traditional applications and want full access to the underlying operating system like Linux or Windows.
• Use containers if you are looking to remove the need for managing an operating system or run a microservice architecture:
• You first need to choose your orchestration tool. Do you want to use Amazon ECS or Amazon EKS?
• After you choose your tool, you then need to chose your platform. Do you want to run your containers on EC2 instances that you manage, or in a serverless environment like AWS Fargate - which is managed for you?
• Use AWS Lambda if you are looking to host short running functions or event driven applications and you don't want to manage the underlying environment at all.