Corey: Hi, Jerry. Thanks for joining me. So you’re better known these days as AWSgeek. A few months ago you starting putting up these fascinating drawings about various AWS services. So, who are you, and how did you get started with this?
Jerry: By day, I’m a Solutions Architect at Rackspace. As part of this role, and in order to keep up-to-date and maintain relevancy in the field, I periodically review different AWS services and features and take notes to help me remember relevant information. I’ve been experimenting with creating visual notes using an iPad Pro and Apple Pencil and I thought “Well, let me clean one of these up and put it up on Twitter and see if anybody likes it.” I was surprised at the number of people who commented positively on it and wanted to know how I did it, what tools I use, and also found the high level summary information useful. For myself, I use them as a visual reminder, as a way of cementing some of the details about particular services and features into my mind so that when I’m talking with customers, I can relay that information to them and then I can help them decide what services and features best fit their particular architecture.
Corey: No, that’s a very fair caveat. There’s nothing else like this that I think I’ve seen. It’s a terrific way of distilling complex services that aren’t very easy to describe into something that resonates a lot more with visual people or folks who for various reasons don’t tend to sit there and absorb giant walls of text in quite the same way.
Jerry: Right, and that’s one of the challenges that I’ve had. The one thing that sometimes I have to remind people of is that these are really my notes; these help trigger memories of features and services and details. They’re not all-inclusive, so all of the details about a service aren’t there. I tend to focus on those things that I find useful in my interactions with AWS customers. Obviously, I hit things like service cost, common use cases, features, limits, those types of things, but they’re definitely not intended to be a “you’ll understand this service at a glance” type of thing. It’s to get you moving in the right direction.
Corey: What’s your background? You mentioned you were a solutions architect for a while. Can you talk a little bit more about that?
Jerry: I have a background as a developer, starting at Intel over 20 years ago writing hand-optimized assembly and C/C++. I recently spent a few years at AWS on the SNS and SQS team, while there working on the initial SMS implementation for SNS. At some point I thought, “Wow, the AWS ecosystem is much bigger and broader than this. I’d like to know more about it.” That’s when I transitioned to the Solutions Architect role where I worked with AWS customers, just like I do today, helping them understand their requirements and then translate those requirements into architectures that use AWS services and features that are appropriate for their particular needs.
I’ve been in the solutions architect role for the last five years, focused almost entirely on AWS. I dabbled in GCP a little bit, passed the GCP professional architect certification exam, but not much beyond that.
Corey: We’ve all had youthful indiscretions, it’s fine. I won’t mention that. [EDITORIAL NOTE: Totally mention that!] Those folks are strange anyway. Back to topic, what do you call these drawings? Some people call these “sketch notes,” while others would call them “diagrams.” How do you think of these when you sit down to draw one of these? I don’t even know how to describe them accurately.
Jerry: Yeah, it’s kind of a combination of those. “Sketch notes” is an interesting one because when I was thinking about putting all of these together I started with a sketch note approach. I looked a couple of other people who were doing similar things and adopted their methodologies, but it’s kind of morphed into my own thing now. I honestly don’t know what to call them. They’re a “visual service summary” for lack of a better term.
Corey: I like that. As any observer of AWS services can attest, naming things is hard, particularly consistently. Are there any services that you’d like to end up drawing a visual service summary for but can’t figure out the best way to represent visually?
Jerry: Some of them are just so darn big and broad now that it can be hard to put all of this information on one page and make it useful. Like EC2, I’m not sure where I would start with that, other than I guess the very basics. Or VPC. I may combine some of them, like SNS and SQS, it may depend. Broader services are hard to approach. Core services and fundamental building blocks of architecture, those are fairly straightforward to do, but some of the more peripheral services, elastic transcoder for example. I’m not sure when I’ll get to that.
I’d like to do one for every AWS service but it’s just a matter of time. I spend a minimum of two to four hours on each one of these and, in some cases, even longer because for some services that I just don’t use, I tend to use them as an opportunity to go deeper into the service. I may work on one of these intermittently over the span of a few days, just because I’m spending more time digging into the details.
Corey: Which makes sense. Part of the challenge, I think, with any offering that’s as broad as AWS is there are some services that almost sound like a punchline, such as where you have 100 petabytes of data in a truck hurtling down the freeway. There’s no way to make a drawing of that that isn’t deeply sarcastic. There are services, I think you’re right, that lend themselves more effectively to this, while others are just too vast, like EC2. You might be able to pull that off if we give you six years and a piece of paper the size of a football field but it doesn’t lend itself to that.
What amazes me is not just how effective your drawings are at clarifying a lot of these things for you, but how well the internet has responded to this. Every time you publish a new one there’s a flurry of activity around it. Does that surprise you?
Jerry: Yes it did. At first, I just wanted to get feedback from people: “hey, is this useful?” The feedback was overwhelmingly “yes it is useful, we want more!” I continued to get positive feedback from just about everywhere from customers of AWS, from evangelists and developers and product managers at AWS. Right now my visual service summaries are unique and I expect that the furor will probably die down– but who knows. I plan on continuing to make them public and share them with others. My hope is that other people find them useful too, that people are actually using them and referring back to them over time. That brings up the other point… Am I now responsible for keeping these up to date and refreshing them when AWS adds new services and features? That becomes a more long term maintenance kind of question. I haven’t answered that yet.
Corey: That is a constant struggle. With the open guide to AWS one of the challenges we find is keeping things current. Every time I read through it looking for information on some service I’m about to start touching again, I trip over things that I know are out of date. It seems like I never sit down and absorb information because I’m too busy submitting pull requests to keep things current. Keeping up with AWS and all 91 of its services and products is a full-time job– that’s why I started my newsletter. Worse for us, it doesn’t feel like the pace of innovation is slowing down.
I guess what I’m wondering is, at some point do you wind up conceding defeat and saying, “As of this date, this is how this works. If it’s not up-to-date anymore, good luck. Best wishes, I’m out” or do you wind up keeping an eye out for massive changes and plan to go back and make edits later in time?
Jerry: Yeah, that’s a good question. I think it would probably be similar to what you see with the open guide. That is, you try to keep things as up to date as possible. I’m actually drawing these on an iPad so it’s not as though someone can submit a pull request and integrate their changes into one of these. It’s a very personal project and I’m not sure how I would share that and farm that out to get others to help with it and so ultimately it is as of this date, this is what the state of this particular service was. With the understanding that even on that date, this is an incomplete description of this service and there can and will be updates to it. I expect that at some point they will wither because it doesn’t seem like something that I’ll be able to do full time or at least long term, anyway.
Corey: What’s your work flow for building these?
Jerry: I do these on an iPad Pro with an Apple Pencil using an application called Notability. I have a basic template built out, a 3×3 grid. I start based off of what I think I need to know to evaluate the service, along with what AWS customers that I’m working with are going to find useful. Those things include cost, limitations, architecture patterns, interaction with other services, security, common use cases, and best practices. I break this down, and you start to see this in a lot of these diagrams.
Take my current EFS one. I have a cost section which describes the cost structure is, how you pay for it, what the pricing model looks like. There’s a performance section, and hoo boy. That’s one of the things that I find a lot of people have difficulty with on EFS– just understanding how it preforms and how IOPS are procured. There’s another section on the AWS storage family and how it fits into that family. Another section on security. I try to break it down into little bit sized chunks and summarize each one of those. That’s really it.
Initially I was just posting these as images on Twitter and then people would come back and say, “Hey, this is great. Looks like you made a mistake here or it would be interesting if you add this particular piece of information to the diagram.” You can’t really update a Twitter post. That’s why I put together the AWSgeek website. I host these images on S3 and makes changes to them and those changes would be reflected wherever I shared them with, so long as people don’t just share the image itself. Once I create this image, I upload it to that site, create a simple webpage for it using a static site generator, and then I share a link to that on Twitter or other social platforms I’m on.
Corey: And then it catches fire and we have conversations like this one.
Jerry: Yeah. I’ve been kind of experimenting now too just to see what services are more interesting than others. Serverless is obviously interesting, as judging by my traffic. The services that are more peripheral, I get fewer hits on.
Corey: Are you planning on being at re:Invent in the back of the room with a white board drawing whatever gets on stage to talk about in near real time or is that a little unrealistic for this year?
Jerry: Well, I will be there and I will be doing that for some of the sessions I go to, but those tend to be more mind map-ish.
Corey: Somewhere Simon Wardley‘s ears just perked up. If you say the word “map” three times, he appears.
Jerry: With regard to re:Invent sessions, I take my iPad with me and I take notes and they end up being more of a mind map of notes and those are the types of things that I may do at Reinvent, just sort of summaries of individual sessions and doing some of those pseudo-real time, maybe on a daily basis, I don’t know. What would be cool is, obviously they’re going to announce new services and new features there, if I can turn one of these around quick enough, that would be fun to do a new service while it’s there.
Corey: That would be interesting to see! According to legend / the rumor mill, there are going to be more than a couple. We’ll see what happens. It very well may be that this is all smoke and mirrors and congratulations, there’s a new class of instances that they’re going to announce and not release like last year. We never know, it’s always interesting trying to read the tea leaves on what Amazon has going on.
Is there anything else you’ve considered doing with these?
Jerry: One of the things that people have asked about and I’m considering is some sort of a webinar or a Twitch session or something of me drawing these live. These take me a few hours to do, but if I could capture all of that interaction with an iPad and then go back over it with an audio track and really just talk through the things that I’m drawing out. That would be fun to do, I just haven’t quite figured out how to do it and how to orchestrate it all and then put it all together. That could be fun to turn into a 10 or 15 minute video where I talk about a particular service.
Corey: That would be a really interesting idea. I’d like to see that done. Thank you very much for your time. I appreciate it and I hope to catch up with you at re:Invent!
