Wednesday, 30 March 2016

Microscaling based on Queue length

We've been working with our friends at Microsoft to demonstrate Microscaling containers based on maintaining a target queue length.

Update: the video of this at Microsoft //build/ is now available.

Here's the setup.




The producer app adds items to a queue, and they're pulled off by a consumer.  There is a force12 agent controlling the number of instances of the consumer app (these instances are called tasks in Marathon terminology, but they are each an instance of a container). We're using spare capacity to run folding-at-home. That's right, with Microscaling you can help cure cancer with your spare compute resources!

The Marathon UI shows the 4 different apps

In the video you'll see us use the Marathon UI to start Force12, which automatically starts some consumer and folding-at-home tasks. Our graph shows how many producer and folding-at-home containers (tasks) are running, along with the current length of the queue. Initially the queue length is zero as there aren't any producers adding items to it.

Then we use the Marathon UI to manually change the number of producer tasks, and hence vary the rate at which items arrive. The Force12 agent also communicates with Marathon (via its REST API) to control the number of consumer tasks - in this example we're maintaining a queue length of roughly 50 items.


This is all running on the new Azure Container Service, which has an option to set up a Mesos / Marathon cluster for your container tasks.

Want to Microscale tasks in your own infrastructure? We'd love to hear from you.

No comments:

Post a Comment