It’s no secret that I love to watch cartoons like Sponge Bob Square Pants and Adventure Time for their wit, innuendo, and I just plain find them funny. One of my favorites is Rick and Morty, an Adult Swim cartoon that follows the adventures of an odd duo consisting of a drunk scientist grandfather (Rick) and his fearful grandson (Morty). It’s sort of a play on Back to the Future, but more realistic in some ways and completely off the wall in others.
In the fifth episode, the other cartoon family members are complaining about simple problems like trouble opening a mayonnaise jar. The grandfather produces the focus of this blog post – a Meeseeks box. This box summons a Meeseeks, which is a blue gummy looking guy who can solve simple problems and then disappears.
The Rick and Morty wiki explains their purpose as the following:
Meeseeks are creatures created to serve a singular purpose for which they will go to any length to fulfill. After they serve their purpose, they expire. Their motivation to help others comes from the fact that existence is painful to a Meeseeks, and the only way to be removed from existence is to complete the task they were called to perform. (source)
Treating Automation Tasks like Mr Meeseeks
I saw this episode again recently and thought that a Meeseeks is very similar to the simple, repeatable, and modular automation tasks that we should focus on creating as operations folks. In many cases, it just means breaking down existing scripts and code into smaller chunks (something I’m guilty of with my NSX Tier Builder). By creating simple tasks with a simple purpose, we start to realize things like …
- Modular design with simpler troubleshooting, such as stepping through functions.
- Reusable modules that can be shared across complex workflows, regardless of the desired end state outcome.
- Code that can be read and assimilated by novice coders / scripters because they are so simple and unitask in nature.
- Each small task can be measured as a series of feedback points to understand where bottlenecks occur (and provide insight on how to shift the bottleneck).
Taking this idea train to the next logical station, it’s relatively simple to gather metrics from small tasks and put them into open source projects like the InfluxDB and Grafana combo I wrote about earlier. You could build your own dashboard showing how a set of tasks, workflows, or even projects are performing – or even build them dynamically based on the JSON files used to tell Grafana what it needs to look like.
In my NSX Tier Builder code, I could, for example, POST the completion time of each step to the InfluxDB database and ask Grafana to graph those points as a stacked chart. This would help my team better understand what’s taking the most time when users request NSX environments so we can prioritize that segment of code / automation in our next sprint.
More Meeseeks Wisdom
The wiki goes on to explain another important point about these magic Meeseeks!
They typically live for no more than a few hours, and thus time is much slower relative to Meeseeks. The longer the Meeseeks stay alive, the more sanity they begin to lose. (source)
In this case, I’d say that short lived unitasks make sense, and that creating longer sized tasks – such as the dreaded Massive Wall of Text – can drain the sanity of you and your team members. In fact, a Meeseeks can even summon more Meeseeks, which is akin to the idea of nested functions or scripts calling scripts.
Each Mr Meeseeks also uses a standard greeting type – they say “Hi, I’m Mr Meeseeks, look at me!” to you or each other. Sort of like a SYN, SYN-ACK, ACK for magic blue gummy people (sorry, I had to toss in a network joke). If you shoot for sanitized inputs and outputs, use schema validation (check out this great JSON example), and version control, your army of short lived Meeseeks will serve you well.
Just don’t ask them to knock two strokes off your golf game.
