5

Background: I've worked with EC2 and RDS. Recently I received a query from a client in which he wants to develop both mobile and web applications using Amazon Web Services, and need advice on which service he should go with?

  • Elastic Beanstalk
  • Lambda
  • Elastic Container Service (ECS) or Elastic Container Registry (ECR)

Also, I've gone through several tutorials on YouTube and Google to understand these services, but still I'm unable to figure out with which service he should go with.

Problem: I don't have any proper knowledge and experience working with the above mentioned services. Therefore, I want advice from the people who have experience working with them.

Please explain with advantages and disadvantages of using specific service so it will be easier for me to advice.

the_jerryyy
  • 53

3 Answers3

6

Elastic Beanstalk is your traditional hosting - you can upload a PHP or Java or whatever application, say Wordpress, configure a database, etc, and go. There are some smarts for scaling, recovery, etc, but it’s still very much a traditional hosting platform.

ECS Containers can still run your traditional app but there are some more specifics - most notably the containers don’t have persistent storage and are ephemeral, they can come and go and be restarted at any time. Which means they have to be built and ready to run without manual configuration / intervention. There are ways to provide persistent storage for containers but if you can avoid it it’s better. Design your application in a way that it stores all its data in a database and all its files in S3 for example. BTW ECR (Elastic Container Registry) is only a storage for your containers. It's to be used with ECS.

Lambda is a cloud-native serverless concept where the app is split into small functions that serve the various API requests. The website frontend is typically built for example in React or Vue or similar and is served from S3 / CloudFront. Then it makes API calls to the Lambdas through API gateway.

Serverless apps and Containers can typically scale better than traditional apps if they are done right. On the other hand building your first serverless app will be quite a learning curve as some concepts are different from what you may be used to do.

It is a very brief overview. This topic can be discussed for hours :)

Try to google something like “serverless apps design best practice” or “containerised apps design best practices” if you want to go that way.

Hope that helps :)

MLu
  • 26,247
1

Adding to the previous answer - Elastic Beanstalk is more of a Pet platform while Docker (ECS) and Lambda are Cattles. That also means that Docker and Lambda are stateless which means they don't (must not) store any state locally, everything is in a database, in a memcache cluster, and in S3. Beanstalk on the other hand can store local state but it's discouraged with modern applications as it complicates scaling.

Have a look here if you're not familiar with the Pet and Cattle concept.

KeepLearning
  • 685
0

I know there's an answer that has already been accepted and another one with an upvote, but I don't believe that either answer is particularly good.

Firstly, let's recap what Elastic Beanstalk (EB), ECS and Lambda actually are:

  1. EB is definitely NOT your traditional hosting. Traditional hosting is where you spin up a server and it gets allocated an IP address and you ssh into the box and start installing stuff. EB, on the other hand, is a managed PaaS that allows the user to easily spin up a load balancer with one or more EC2s sitting behind it, which EB will then monitor and manage on your behalf. You can then upload your native application code (e.g. PHP, Python, etc) OR you can upload a Docker image OR define an S3 URL where the image is stored OR you can use ECR. Out of the box EB provides a web server configuration and a queue worker configuration, but it is easy enough to run queue workers on the web server configuration with a little bit of customisation. EB provides several options for auto-scaling and I have found average CPU to be the most effective - our production systems idle with two servers off-peak and auto-scale to around a dozen or so servers during peak times every single day. The upshot of this is that no, you cannot, and MUST not, treat EB as "Pets" - they are most definitely "Cattle". Nor can you rely on their storage being permanent, because just like ECS, EB will create and destroy EC2s according to your scaling requirements or if it detects that they are unhealthy.

  2. ECS is a solution for running Docker containers and it provides more control over the configuration and, by virtue of that, is more complex to set up, monitor and manage. You either need to spin up and assign your own EC2s for the ECS clusters or you can let Fargate look after the creation and destruction of the EC2s for you. The latter is less work but more expensive as you can't take advantage of cost optimisation opportunities such as reserved instances.

  3. Lambda, as the accepted answer notes, is a "server-less" concept for hosting that is often touted as being most appropriate for "small functions", but you can actually host monolithic web applications in Lambda, as long as your application doesn't exceed the memory limits of the configuration. (Look up Laravel Vapor by way of example). In reality, Lambda is not "server-less" - these functions run on VMs hosting a tiny version of Linux (which I've heard is called "Firecracker") and the whole thing is optimised around being able to boot up these VMs really quickly. That's why Lambda has the concept of "cold start", which is what happens when your "function" (aka VM) hasn't received any requests for a while and gets shut down. The main limitation of Lambda is cost (depending on your load) and the fact that a "function" isn't allowed to run for more than 15 minutes.

My advice to the OP, and, indeed, anyone new to AWS, would MOST DEFINITELY be to go with Elastic Beanstalk rather than ECS or Lambda. Using EB will provide a good introduction to load balancers, VPCs, EC2s and CloudWatch and the AWS console and will enable them to get started quickly. You'll be able to host either native code or Docker containers and you'll be able to run queue workers as well as serve web traffic. The scaling options are more than adequate for 99% of situations. The most commonly noted limitation of EB is the 4KB limit on environment variables, although even that has a workaround using Secure Secrets Manager.

ECS is the best option if you have some particularly long running and CPU-intensive batch operations, as you have better control over the cluster(s) running those task(s). However, ECS is more complicated and will require much more knowledge in order to set everything up. Honestly, for hosting a web application with some modest batch processing needs, EB is fine.

There are some SDKs and other tools that make Lambda fairly easy to use, even with monolithic web applications, but it can get expensive depending on your traffic volume and if you want to run batch jobs longer than 15 minutes then Lambda is not an option.

In summary, go with Elastic Beanstalk.

JamesG
  • 201