”… and today I’m really excited to announce the global availability of our newest service, AWS Mousetrap, a service that’s designed to help you learn about the AWS ecosystem in a fun and competitive environment.”
The applause and hoots ring out in the massive auditorium as the GA release of AWS Mousetrap (which had been in preview for 6 years) becomes a reality. As the lights come up and the audience streams out of the hall, excited conversations strike up between attendees. Who will have the weirdest service use? Who can do it fastest? Who can create the most intricate Mousetrap?
What is AWS Mousetrap?
So, cool your jets – it’s not a real AWS service at all.
It’s a concept for a game that I came up with about 6 years ago, but haven’t done anything with until now. The goal is simple: get a message from one “side” of AWS to the “other side” using as many AWS services as possible.
Why. Just Why.
What the heck? Why would you want to do such a weird thing?
Well, I learn by doing. If I don’t have a reason to use a thing, I don’t get to do things with it and so I don’t learn about it. Knowing how things work, where the edge cases are, how they behave against the documentation – getting a visceral feel by getting in amongst it and using it for real, that’s where knowledge comes from for me.
Many others learn the same way, so I thought “wouldn’t it be fun to have an excuse to use all these services that show up in the console?”
That’s what AWS Mousetrap is.
If you’d like a more formally enumerated list of reasons, AWS Mousetrap provides you and your organisation with:
- opportunities to learn about new and less-used AWS services
- the chance to explore integrations between services that you might not have used before
- a way of building team spirit
- an excuse to boast about how awesome you are
How does it work?
The rules, and some examples, are in the aws-mousetrap GitHub repository but it basically goes like this:
Generate a GUID or UUID as your “input message”
Put the input message into an AWS service by making an API call
Retrieve the output message from another AWS service by making an API call
Verify the input and output match
Put as many services between the input and output as you can
Build it all as code so you can tear it down again at the end
Each service is only scored once
Let’s say I want to build a fairly simple mousetrap. Obvious services to use might be SNS, Lambda, and SSM Parameter Store. I would:
Create a CloudFormation template which creates the services and wires them together
Generate a GUID using the Linux shell command
Acquire AWS credentials for my account
Create the CloudFormation stack from my template
Put the message into the SNS topic using the AWS CLI
aws sns publish --topic-arn .... --message <my-uuid>
Consume the message from SSM using the AWS CLI
aws ssm get-parameter --name ... --query Value --output text
Verify the message is the same as the input
How you can use Mousetrap
There are many ways to use Mousetrap. You could:
- start a mousetrap competition in your company or social group?
- use a mousetrap on your own to learn about AWS services?
- use a mousetrap as an example in training environments
- use a mousetrap as a source for an interview question (don’t ask people to create one in an interview, that’s just cruel)
There’s no actual reason why Mousetrap has to be constrained to AWS – I’ve started here because they’re the cloud provider that I know best, and use the most, and because Cevo is an AWS Partner. You could use Mousetrap on Azure, GCP, or any other cloud provider with sufficient options and the ability to manage services as code. You could run a version where you specify that it’s multi-cloud, or includes on-prem systems; you could get really wacky and require it to include a printed element, or a pigeon, or … I dunno, it’s up to you!
I’m sure there are many creative uses of and extensions to Mousetrap that I haven’t thought of. I’d love to hear about them though, as issues or pull requests on the aws-mousetrap github repository
Go forth, explore, learn, and have fun.