0

We have a product which is set of following .Net5 applications:

  1. Front-end web app for customers
  2. Admin Tools - for administrative activities
  3. Web API
  4. Worker Service - for background jobs

Right now we are using two AWS EC2 VMs(load balanced with AWS Load balancer) to host these application on IIS. Also we have 5 different vendors(will be more in future). So We deployed these 4 applications for each vendor i.e. we hosted 20 applications on IIS on each VM.

Now there is a requirement to move to server less Container service like AWS Fargate. Can anyone expert here suggest to proceed with any of following way:

  1. 20 container images, 20 Task definitions and 20 Services in the cluster
  2. 20 container images, 5 Task definitions( each with 5 container definitions) and 5 Services in the cluster
  3. 5 container images(4 applications in each container- if possible), 5 Task definitions and 5 Services in the cluster

I am not an expert in container services, So it is possible that the 3 ways I mentioned above are totally imaginary, in that case please suggest the appropriate way. My end goal is to find out the possibility of hosting these application in more scalable(auto-scaling) and cost effective way in comparison to EC2 VMs.

Thanks

Vikas Dagar
  • 143
  • 1
  • 1
  • 10

1 Answers1

4

Consider that a Task is an atomic unit of management and scaling. It's comprised of 1 (typically) or more containers (when needed). If your application has clear boundaries, it needs to scale separately from other modules and it has its own life cycle that is different from the other modules/applications ... then it needs to be its own task. In that task you may need to have more than one containers if that is your atomic entity. For example in a scenario where you have a front end, an appserver, an index service, a backend service, etc…. Each of these modules need to be their own task. Each of these tasks could be one or more containers depending on how your module is built.

A Service it’s just a construct that allows you to tell ECS “take that task and always run x instances of it”. That x could be a fixed number or you can tell ECS to scale the service in and out (in terms of number of tasks) based on the workload.

Based on what you say above it looks like your application is comprised of 4 modules (website, tools, API and worker). That means you probably are looking at 4 task definitions. Given I understand your application is not multi tenant you probably need to have dedicated services for specific users (“vendors” in your case?).

So assuming you have 5 vendors you are probably going to have 5 x ECS services for the web module, 5 x ECS services for the tools module, 5 x ECS services for the API module and 5 x ECS services for the worker module. Assuming you can customize each module with environment variables for the different vendors, you are probably good with only 4 task definitions that get personalized at run-time when you start them. If this is not possible, than you have to have a task definition per module AND per vendor.

This is at the high level how you should look at it. If you are new to ECS perhaps a better approach would be to use either the Docker/ECS integration we built with Docker or the Copilot CLI that simplifies a lot of the concepts described above.

HTH

mreferre
  • 5,464
  • 3
  • 22
  • 29
  • Another option which is more compact but less scalable would be a service for each vendor. each service task definition can then have the 4 containers. This would make the solution simpler but you won't be able to scale a specific container. – Pistazie Apr 09 '21 at 20:17
  • I think what you are suggesting is 1 service based on a 1 task definition per vendor. 1 task could in theory contain the 4 modules as separate containers and the service could schedule 1+ of these tasks. As you pointed out you'd lose individual modules scalability and life-cycle (i.e. if you need to deploy a new version of the API module you need to deploy all of the 4 modules). It may work if you want to keep simple but it has its trade offs. – mreferre Apr 09 '21 at 22:20