Timeline for multi-container

[hsolomon]

In one of your video presentations you mentioned that multi-container support is on the roadmap. Do you have a rough estimate on timeline for this feature?

Thanks

[HatariOS]

@hsolomon, @georgebabarus, @madanadit, could you describe architecture and use case you have for multi-container?

[hsolomon]

I have an app that uses redis service and was thinking of using a dedicated redis container. I'm open to suggestions if there's a better way.

[madanadit]

@HatariOS Our application, deployed on ECS, will have multiple processes.

1. The first process (and container), has 2 endpoints: one for a REST server to serve the main web UI, and a second gRPC endpoint to serve API requests.
2. Within the main web UI, we plan to embed a dashboard UI (like Kibana) to visualize data in an ElasticSearch storage backend. The ask for multi-container support comes from the need to launch another process in a separate container for the dashboarding tool.
   The alternative would be to launch a process in the background and manage process logs, lifetime & restarts manually instead of ECS. However, I believe a single process per container should be the recommended way. Thx.

[brtrvn]

We are happy to announce that the core SaaS Boost team is beginning work on adding support for multiple compute resources for your applications. We will soon be creating a long running feature branch for this work. Note that this work will maintain complete functional parity with the existing solution we have today of only a single container.

Currently we are planning on supporting both "private" or internal containers as well as "public" containers.

So called private containers will not be addressable via public DNS, but will be addressable by other containers in your workload. These sorts of services are ideal for a "micro services" type architecture where you have a single point of public entry into your application, but use multiple services on the backend to process your business logic.

So called public containers will be addressable via public DNS, and we intend to implement this via path based routing in the Application Load Balancer that sits in front of the container services. For example, all requests to https://tenant-1.saas-example.com/serviceA/* would route to "serviceA" containers and all requests to https://tenant-1.saas-example.com/serviceB/* would route to "serviceB" containers.

Since each "service" will be a separate ECS Service in the cluster for your tenant they will be able to follow micro services best practice of independently scaling and defining their compute resource needs.

We are planning on allowing each "service" to optionally define extensions as they exist today in order to support the micro services best practice of each service independently owning its data stores.

Following Docker image best practices, each of your "service" container images will be managed in separate ECR repositories. This also provides for independent CI/CD of your compute services.

[tieujason330]

This is great @brtrvn. I see that there's a lot of updates in the mutli-container branch. Is there an ETA for when that's ready for use?

[brtrvn]

We're targeting a beta release by end of Q1 assuming we don't run into any unforeseen blockers.

[HatariOS]

We are getting closer...Exciting! Tell us about your use cases here or reach out here: https://pages.awscloud.com/SaaS-Preview.html

[PoeppingT]

The v2.0.0 Multicontainer pre-release is now available!

Download the source code here: https://github.com/awslabs/aws-saas-boost/releases/tag/v2.0.0-rc0

Or clone the source code into your local git repository by running

git fetch
git checkout tags/v2.0.0-rc0

Also, check out our discussion for a forum to leave comments and feedback here: #206