Copilot-cli: Feature: Worker service type

[hnrc]

Copilot currently supports two service types, Load Balanced Web Services and Backend Service. Both assumes and supports HTTP type services where a port is exposed either internally in the VPC or publicly to the Internet.

I'd be interested in a service type that do not expose any port at all. I'm thinking of a Worker service type for long running background services. A typical use case can be a service that crunches messages from a queue.

Something similar to Heroku's Worker dynos.

Does this make sense?

[efekarakus]

Yup totally makes sense! In your situation how does the queue get populated? Are you subscribed to a SNS topic from a different microservice or something else?
Do you use SQS or EventBridge as a queue? Does it even matter 😛?

[hnrc]

Are you subscribed to a SNS topic from a different microservice or something else?
Do you use SQS or EventBridge as a queue? Does it even matter 😛?

Aye, the most typical setup looks a little like this:

+-------------+    +-------+    +-------+    +-------------+
|             |    |       |    |       |    |             |
|  Service A  +--->+  SNS  +--->+  SQS  +--->+  Service B  |
|             |    |       |    |       |    |             |
+-------------+    +-------+    +-------+    +-------------+

However, there are also use cases where the worker service feeds itself with work.

[mwarkentin]

+1 for this from us - in our existing apps we have several which use SQS, and a whole bunch more which consume tasks from RabbitMQ.

[mwarkentin]

Seems like this can be closed after #1478 was merged.

[efekarakus]

I think there might be still room for us to explore a nice UX around publishing and subscribing to events from services.

My initial thought was to provide something like this in the manifests:

# in serviceA's manifest
publish:
  topics:
  - name: "subscriptions"

# in serviceB's manifest
subscribe:
  topics:
  - from: "serviceA"
    name: "subscriptions"

ServiceA could create an SNS topic named "serviceA-subscriptions" and ServiceB gets a SQS queue that gets subscribed to the same topic.
Or similarly ServiceA publishes to an EventBridge at the environment level (shared across services), and ServiceB's SQS queue becomes a target.

This is very high-level, we haven't investigated the tradeoffs yet. At first glance, the first approach might result in cross stack imports which can be troublesome during deletions. But let us know if anyone has thoughts on what type of experience you'd like around pub/sub!