My manager gave me an AWS IoT Button

With the touch of a button you can notify the world that you touched a button.

I was sitting at my desk the other day, busily shifting paradigms and engaging synergies, when my manager plopped a small brown paper box on my desk.

Image for post
Image for post

“What’s this?” I asked, setting aside my efforts to break down silos through gamified product-thinking.

“It’s an AWS IoT Button. From Amazon. Do something cool and write about it,” he replied.

I knew of AWS — who doesn’t? But I didn’t know they had an Internet of Things offering. So the first step was to visit the page and…

Wow, that’s complicated.

So I turned my attention to the button. And the documentation was pretty understandable. Within an hour I had hooked the button into the team’s Slack channel, thanks largely to a pre-existing AWS Lambda blueprint for Slack integration.

This is all kinds of fantastic for me. With the touch of a button I can execute more code than all the Apollo missions combined and annoy my team by spamming the Slack channel?

Image for post
Image for post

But what exactly does the button do? Like, under the hood?

Thanks, header!

Under the hood we’re taking advantage of a slew of AWS IoT features:

  1. The Thing — in this case, the button itself. IoT maintains a Registry of all your Things, which can be given a Thing Type and a couple of searchable attributes. You link Things with Certificates.
  2. Certificates — these are generated to enable mutual authentication between the Thing and AWS. Certificates also link Things to Policies.
  3. Policies — these are JSON documents that grant your Things specific access to specific resources on behalf of specific users. I think. The Button uses a Policy to tie a Thing to a Topic.
  4. Topics — imagine a fancy publish/subscriber queue. Things generate data, and when they do the data will usually end up being pushed to one of these Topics to be consumed by a Rule.
  5. Rules — here’s where things get interesting. These Rules are simple business rules, as in a rules engine. On a truthful evaluation of a business rule (given the input from your Thing) the data can be dispersed to any one of AWS’s many Services via an Action.
  6. Actions — one of AWS’s many services. Such as Lambda, which is what I used to trigger the Slack integration.

Okay, that’s a lot of background, so let’s go through the Button example.

I press the Button, which initiates Internal Button Logic. This logic connects (via Certificate) to the AWS IoT endpoint assigned to the Button (which is a Thing in the Registry). When the connection is established and authenticated the Button uploads its state data (what kind of click, how much battery power is left, and its identifier) to the IoT endpoint.

So far so good.

When the IoT endpoint receives the data it publishes it to the associated Topic (which is known via the Thing’s Certificate’s Policy). A Rule is watching this Topic and, when it notices the incoming data, evaluates it against the Rule’s conditional (for the button the conditional is “is there data?” since data is only uploaded on a click event). Assuming truthful evaluation, the data is then shipped off to the associated Action. Which in this case is an AWS Lambda. A Lambda that annoys my team.

It turns out you can buy many different AWS IoT kits on, of all places, Amazon. I imagine the kits take advantage of some of the IoT code provided by AWS, such as the C, Arduino, and JavaScript SDKs.

As for me, I’ll have to wait for my manager to interrupt me again with a new toy. I don’t have time to invest in this IoT stuff while there are all these glass ceilings to leverage via B2B mindshare.

bearded programmer

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