Metadata in action! Get a Docker image’s scaling parameters from its labels
Our latest microscaling demo gets the scaling parameters for a container image from labels in its metadata, by reading them from the new MicroBadger API.
Ever since we built the first microscaling demos, we’ve been pondering the best way to manage scaling parameters. We’ve also thought for a long time that there are many other use-cases for metadata and parameters that control how an image is operated, but that the image code itself doesn’t need to be aware of.
In this article we’ll show how our latest update to Microscaling can pull scaling parameters from any image’s labels using the MicroBadger API.
What is Microscaling?
Microscaling is an agent that runs within a deployment, and scales containers according to current real-time demand. Each of the containers it is managing has a priority, and a target metric that it’s trying to achieve — this metric would typically be something like an average response time or the length of a queue. Microscaling manages the scale of each container, trying to keep containers as close as possible to the target metrics. If there aren’t enough resources, the highest priority tasks come first.
Background, low priority tasks can therefore be postponed when there is a lot of high priority work to do. This can lead to much better resource utilization. (Google and Netflix do something much along these lines to get their machine utilization to over 50%, compared with the <15% average that Gartner reports).
This Awesome Microscaling list is a good place to start for more background on the concept.
Connecting Microscaling and MicroBadger
This is an updated version of our NSQ demo where we we run two containers under microscaling — one is a “consumer” pulling items from a queue, and one is called “background”. The Microscaling agent scales the number of consumer containers to keep the queue length at or close to a target, and if there are spare resources it uses them for instances of the background task.
The easiest way to specify the container images that we’ll use for the consumer and background tasks is to specify them at app.microscaling.com, our Microscaling-in-a-Box app. This gives you a Docker Compose file that you download and run to start the Microscaling agent. Here’s a sketch showing what happens next:
- The Microscaling agent queries app.microscaling.com to find out which images it will be controlling.
- It queries the MicroBadger API to get the metadata associated with the specified images. The metadata for our demo images include labels specifying their scaling parameters.
- The Microscaling agent monitors the length of the queue, and works out whether we need to scale the consumer up or down to keep the queue length at target.
- If we need to change the number of consumer or background containers, Microscaling asks the Docker engine to change their scale.
- Microscaling reports the number of each container and the length of the queue to Microscaling-in-a-Box which displays a real-time graph.
What’s in the metadata?
These screenshots from MicroBadger show excerpts of the metadata for the two demo images, including the labels that define the scaling parameters.
Bring your own images
You can run your own container images by specifying them in Microscaling-In-A-Box. Add labels to those images if you’d like them to define your scaling parameters. More information here.
Is build-time metadata appropriate?
There is an obvious restriction involved in using metadata that’s baked into an image at build-time — once it’s built into the image it can’t be changed. We believe image users need the ability to apply context-specific metadata to an image after build time. Coming very soon, we’ll be publishing our ideas for how to do that very thing.
If you like this article, hit the green heart to help other people find it too. And follow Microscaling Systems here on Medium or on Twitter to keep up-to-date as we explore the use of metadata in containers.
Read next — Why metadata for containers is important
