I’m very tempted to buy this https://www.etsy.com/listing/86833090/11x17-poster-robot-print-poster-monster

Programmable Infrastructure in Production with Kubernetes

What does our service do?

How does it work?

  • containerized, stateless & orchestrated in a k8s cluster (on AWS) OR
  • an AWS service (SQS for the queues).
  • The API service (Go) handles API requests from the web and either serves cached content or drops a request for new data on the Inspection Q. The web client polls the API until the request is fully complete.
  • A single-threaded Inspector service (Go) polls the Inspection Q for a new work item and requests the quick data from Docker Hub. It processes and caches the response and it also drops a request for the slower data onto the Size Q.
  • A single-threaded Size service (Go) polls the Size Q for a new work item and requests the slower data from DockerHub and processes and caches the response.

Behaviourally, what are the key features of this system?

  • The API service is vital, so needs to be fully resilient and fast (Go was useful for this).
  • The queues are also vital. We handle that by using a cloud queue service, which is expensive, but hey-ho. Note using SQS for our saved state keeps our k8s cluster stateless, which is easier to set up.
  • The Inspector service is urgent for new images, which are vital for our valuable new users.
  • The Size service is less urgent — if it’s unavailable for a while Microbadger won’t be as good but it’ll still work OK.

Ideal for programmable infrastructure!

  • a demand metric (in this case, we used the lengths of the two queues)
  • the high priority service container identifier (we used the inspector service)
  • the low priority service container identifier (the size service)
  • It ensures we run only the minimum number of services, which reduced our expensive rest-state SQS polling operations by ~70%
  • It reduced the total amount of resources we used significantly, potentially enabling us to reduce our bill in future in a multi-tenant cluster, for example.


  • Easier to manage/deploy (very CD-able — small, independent components+APIs->small teams+fewer clashes, all of which worked well with the k8s rolling deploys)
  • Division of labour (specialisation of people and their services is more efficient)
  • Improved ability to leverage specialist 3rd party services (e.g. SQS)



SciFi author interested in tech, engineering, science, art, SF, economics, psychology, startups. Chaotic evil.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store