Recovery Sheets Structure

They are so named because our sessions, learning about AWS technologies, would be so overwhelming that students need to recover from them. These sheets were designed to help students recover, revising the topics from the lesson.

Many organisations often need to recover their data after a disaster. There is a whole industry concerned with backing up data. AWS proposes four models for backing up data. One involves keeping an active replica of the data (very expensive), and another involves occasional backups. I am drawing an analogy between information in our student brains and information in servers, with Recovery Sheets.

I decided to use these four disaster recovery models for the revision sheets. At the top is Active-Active data. You can read over the definitions quickly, without being referred elsewhere. This part of the sheet should be read over frequently, especially if you are attempting to build expertise in preparation for an examination. The Warm Standby section contains more detail. In the Pilot Light section, I take time to troubleshoot issues. Finally, in the Backup section is a repository of presentations and blogposts from AWS officials and those in the AWS community.

You can see how as you move down the four sections, more is demanded of you. The Backup section ought to be purely referential ("if you want to do better, here are the materials to surpass me"). In contrast, the Active-Active at the top ought to be devoid of references. The Warm Standby section is just a more developed version of the Active-Active section, and still ought to be devoid of references. In the Pilot Light session, we fight for understanding, wrestling with issues we struggled with, perhaps starting to make references, until we finally surrender our voice to the deluge of material in the Backup section.

This architecture has three key benefits. First, the active-active section gives novices to AWS a clear direction. The instructions are simple: repeatedly read these words, which are declarative. We avoid imperatives. For example, we avoid commands such as "Go and read this over section to learn more about X". User guides are often like this. This can overburden novices and make them worry about whether they should follow the reference. (If they followed every reference, they'd never read a complete page...) Second, it is, in the long-term, fail fast. If my text at the top of the sheets fails to win the trust of a particular student, then they are not beholden to me. They can failover to the primary sources, which are listed at the bottom of the Recovery Sheets. They can investigate for themselves, and perhaps reconstruct better accounts of the AWS technologies. Third, it allows the possibility of adding to the general understanding. We articulate our grievances in the Pilot Light section. Sometimes, these may just be a bubbling up of subjective failures to understand. But in other cases, they might contribute towards better ways for everyone to understand something. More generally, in any student's diet, there should be a section for practising from the offset. Specifically, practising the participating that would be involved, were you not a student, but an expert, in the world you want to enter. (AWS products are are form of communication, every successful product being an acnowledgement of an ache in a customer.) Tenderness can't be tacked on.