Why you need a service registry

Good stuff. We are doing the exact same thing at Grofers (more or less). Our philosophy of our service registry is exactly the same - using services to connect kubernetes objects to AWS resources to monitoring dashboards to github repos.

The place where we differ is: * YAML instead of JSON * A lot of python based tooling to do the plumbing * We don't always rely on terraform for provisioning everything so we have monitoring of new resources in AWS and policies on how those untagged resources will be treated

Good to know that there are more people thinking in a similar way. Validates our approach. :)

Would love to chat in person to learn more about the setup and exchange ideas if you are up for it.

I really like what you're doing here, but oh my goodness that Jsonnet cries out for a more readable format which lets one focus on the semantics more than the mechanics of the mixins.

This looks way more legible to me:

    (service make-it-rain (gocardless/make-it-rain)
      ;; Example service called make-it-rain, powering a dashboard of falling
      ;; gold coins whenever anyone takes a payment via GoCardless.
      ;;
      ;; Banking teams love money, which is why they created this dashboard.
      ;; It's officially owned by banking-integrations, but core-banking
      ;; sometimes optimise the React code.
      ;;
      ;; It consumes data about new payments from Google Pub/Sub, and has a
      ;; separate Google Cloud Platform project for each of its environments,
      ;; of which there are two: staging and production.
      (team banking-integrations)
      (alerts-channel make-it-rain-alerts)
      (google-services pubsub.googleapis.com)
      (environments
       ;; By default, every environment should have banking-integrations as
       ;; admins, and core-banking as operators (they provide on-call cover
       ;; for the falling gold coins).
       (* (admins banking-integrations)
          (operators core-banking))
       (staging
        (google-project gc-prd-make-it-stag-833e)
        (argocd.new (cluster compute-staging-brava)
                    (namespace make-it-rain)))
       (production
        ;; Unlike most services, the production environment should permit
        ;; a non-engineering team to open consoles. Sometimes we take a
        ;; manual payment outside of GoCardless, and banking-operations
        ;; open a make-it-rain console and run a script, so we don't miss
        ;; any gold coins.
        (operators banking-operations)
        (google-project gc-prd-make-it-prod-1eb1)
        (argocd.new (cluster compute-banking)
                    (namespace make-it-rain)))))

It would be really easy to write, too. Basically a service takes a mandatory name & repo, then all other elements are mixins. You could take a couple of different approaches with the way the environment mixin works, too. You could still compile it to JSON, if that's what you need downstream, too.

I think there's a huge win in having a more man-readable, machine-computable format that JSON or Jsonnet: as the system and the tooling grow, I think eventually the Jsonnet will become an unreadable mess of spaghetti (some might argue the example already is!), while a well-thought-out S-expression alternative would not, I think, have the same problem.

Author of the post here, happy to answer any questions about our experience with building the registry, what things it tracks, how we might handle infrastructure deletions, etc.