Going into this project, I assumed the biggest problem would be how to retrieve the status of each product. Some products provide a nice status API, others provide a not so nice RSS feed. Others still provide nothing whatsoever, beyond some poorly-structured HTML.

Much to my surprise, retrieving the status information wasn’t particularly problematic. As ever, the real problem was naming things.

The problem

Some product lines are huge and granular. Amazon Web Services is a perfect example of this. AWS comprises over 200 services, most of which are available in 25 geographic regions. By the time you read this, there’s a good chance one or both of those numbers has increased.

Logically speaking, you could think of AWS as a “provider”, Amazon S3 as a “service”, and each service region as a “component”.

DigitalOcean also provides a couple of dozen products across a dozen or so regions. Once again, you have a “provider” (DigitalOcean), a “service” (Droplets), and a “component” (Droplets in the NYC-1 region).

Seems pretty straightforward so far. Most products are much simpler than AWS or DigitalOcean, though.

Mailgun, for example, provides an API. There are no regions or sub-parts of the API. So now we have a “provider” (Mailgun), and a “service” (API), but no “component”.

Suddenly our neat nomenclature isn’t quite so neat.

Then we get to the real kicker. You can check the status of Amazon S3 US-East 1, but you can’t check the status of DigitalOcean Droplets in NYC-1. It’s not possible.

This means that for Amazon S3 we’re monitoring the “component” (US-East 1), but for DigitalOcean we’re monitoring the “service” (Droplets).

Now our neat nomenclature is becoming positively messy.

The solution

After several false starts, I realised that the way a company chooses to organise its product line is irrelevant. All that matters is what I can monitor. Internally, Happy Stack refers to the thing I can monitor as a “component”.

For Amazon S3, the component is Amazon S3 US-East 1. For DigitalOcean Droplets, the component is DigitalOcean Droplets across every region. For the Mailgun API, the component is the Mailgun API.

For the sake of user convenience, I group these components into a “services”. Amazon S3 is a service comprising all of the Amazon S3 regions. DigitalOcean is a service comprising all of the DigitalOcean products.

Components and services. The most granular thing I can monitor, and a logical group of those things. That’s it.