16 02 2018
I work at a mostly AWS shop, and while we still have services on raw EC2, nearly all of our new development is on Amazon ECS in docker. I like docker because it provides a unified unit of operation (a container) that makes it easy to build shared tooling regardless of language/application. It also lets you reproduce your applications local in the same environment they run remote, as well as starting fast and deploying fast.
However, many services run on a shared ECS node in a cluster, and so while things like Chaos Monkey may run around turning nodes off it’d be nice to have a little less of an impact during working hours while still being able to stress recovery and our alerting.
This is actually pretty easy though with a little docker container we call
The Beast. All the beast does is run on a ECS Scheduled … Read more
15 02 2018
Edit: This code now exists at https://github.com/paradoxical-io/carlyle
When working in any resilient distributed system invariably queues come into play. You fire events to be handled into a queue, and you can horizontally scale workers out to churn through events.
One thing though that is difficult to do is to answer a question of when is a batch of events finished? This is a common scenario when you have a single event causing a fan-out of other events. Imagine you have an event called
ProcessCatalog and a catalog may have N catalog items. The first handler for
ProcessCatalog may pull some data and fire N events for catalog items. You may want to know when all catalog items are processed by downstream listeners for the particular event.
It may seem easy though right? Just wait for the last item to come through. Ah, but distributed queues are loosely ordered. If an … Read more