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.

Philosophy

  • 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