Split Fargate Service into WEB and API

[joswayski]

Right now the NextJs app and Rust API are on the same fargate task. We should figure out a way to split these using the service-2-service protocol of the month (ECS Service Connect) from AWS but im not sure how much benefit we will get aside form being able to scale independently. Will probably introduce some latency which im hesitant to do just for this one benefit :/

https://www.reddit.com/r/aws/comments/zpc7rh/how_to_have_inter_container_communication/

https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/networking-connecting-services.html

Local task networking is ideal for communicating between containers that are tightly coupled and require maximum networking performance between them. However, when you deploy one or more containers as part of the same task they are always deployed together so it removes the ability to independently scale different types of workload up and down.

In the example of the application with a web tier and an API tier, it may be the case that powering the application requires only two web tier containers but 10 API tier containers. If local container networking is used between these two container types, then an extra eight unnecessary web tier containers would end up being run instead of allowing the two different services to scale independently.

A better approach would be to deploy the two containers as two different services, each with its own load balancer. This allows clients to communicate with the two web containers via the web service’s load balancer. The web service could distribute requests across the eight backend API containers via the API service’s load balancer.

Meh.

The thinking was that we wouldn't need lambda consumers and can process everything in one monolith using threads, but i think i want to decouple this completely anyway and have the API standalone as an API & producer of messages and leave consuming to something else / another service.

[joswayski]

Finished in #952 but k3s