People like to ask me the same question: How do you keep up with AWS service and feature releases? I get it almost as frequently as what the hell is wrong with you?
It’s a fun question, and today I’d like to take a stab at answering it in a format that goes beyond “a few snarky tweets.” Come along with me for a deep dive into how the sausage gets made.
For the sake of argument, let’s say AWS announces a service. We’ll call it AWS Elastic Underpants, which is such a great name for a service that there’s zero chance AWS will ever use it for something. Let’s further accept that this isn’t done on stage at re:Invent; that’s a whole separate ballgame. Assume it’s a quiet release for any given Tuesday.
The first I hear about it is, most of the time, via the AWS release announcement RSS feed, consumed via my run-of-the-mill RSS client, Reeder. Some folks like to hook that announcement feed up to Slack notifications, desktop alerts, etc.—but it’s SUPER noisy. As a result, since so much of my news comes from RSS, I check that thing pretty heavily throughout my day.
That said, there are exceptions where I become aware of new services via other means. I’ll sometimes see release announcements on Twitter. And occasionally, someone will ping me wanting to get my hot take on things.
But let’s not kid ourselves: That’s usually much more for existing services—like if Route 53 supported more of the SQL syntax it really should be supporting anyway.
The impossible job that is AWS comms
If I click the link that goes to the “What’s New” section of AWS’s feed, I see inane nonsense that I basically can’t parse into English.
Check it out; this stuff is presumably written by gremlins. No pictures are ever included here (a real treat when talking about console redesigns that basically require screenshots), and it’s always written in the same stilted corporate voice of somebody who expressed an opinion once and was promptly put on a PIP.
Knowing what I know about large companies, it’s almost certainly a symptom of the reality that these announcements are workshopped heavily to death in committee. Unfortunately, that means that they’re devoid of all personality and are using the same buzzwords that the marketing landing page uses.
For a big enough launch of a new service, Jeff Barr or one of the other members of the blogging team will absolutely write up a blog post, and therein lies something super helpful. I mean, go look at that thing. I’ll wait. Jeff’s telling us about feature enhancements to an esoteric service but it’s couched within the context of why someone might care and what this means for customers.
In effect, it’s someone with a personality taking you through using the service step-by-step. I tend to gloss over the click here bits and instead focus on the story they’re trying to tell. It shows me how Jeff or his teammate understands the service use case and that, in turn, breaks it down in a way I can digest.
For truly big releases, such as AWS Elastic Underpants, there will also be a formal press release that pretty much rehashes the same content as the marketing page—but in a broken-down way using smaller words so that mainstream journalists at least have a chance of understanding it. Imagine how small and sad your life would be if you didn’t have an in-depth working knowledge of the trade-offs between various datastores!
Given that AWS is willing to be misunderstood for long periods of time, odds are that the AWS Elastic Underpants service isn’t going to be written up in the New York Times any time soon unless it causes an embarrassingly large data breach.
If you squint hard enough from a certain angle, I kind of look like a journalist. So, I periodically get various AWS PR folks emailing me that press release directly as well. The AWS corporate communications employees have what seems to me to be an impossible job: ensuring that the story that AWS inarticulately mumbles into the ecosystem lands the right way. When it invariably doesn’t, they do their best to correct the misperception.
Remember them in your prayers. They’re all very nice people.
No service is for everyone, but every service is for someone
Remember: No service that AWS builds is for everyone, but every service is for someone.
With AWS Elastic Underpants, the biggest of service launches, there’s going to be a list of customers who’ve had early access to the offering. Unlike some competitors, AWS always always ALWAYS has real-world customer launch stories for their releases. Frequently, some of those launch customers are my consulting clients, so I get to feign surprise about things I’ve known about for months.
In case you’ve wondered why I decline to predict AWS products or features, this is it: I already know some of the answers.
As for the rest? If I guess accurately, nobody will believe I didn’t leak something, breach an NDA, or am just being a jerk. It’s not my market, and that’s okay.
Running my own experiments to avoid being a talking head
Everything I’ve said so far is based upon what AWS is saying about their own product.
That’s all well and good. But if all I’m doing is repeating their talking points to the broader world, I’m just a talking head. For better or worse, I’m considered credible when I opine on whether something is good or terrible, so there’s more work to be done.
Most of the time, I’ll spin up a quick experiment myself with the product in question. Since I get access to it on the day-of-launch, I’m going to go ahead and assume that AWS has done a terrific job of keeping the product from leaking to the folks on the AWS CloudFormation team. So, I’m going to be using the console to get it spun up and working.
This is, contrary to popular opinion, a good thing.
What I think the AWS console gets right and gets nowhere near enough credit for is in what it exposes about the intended use cases for the product. In many ways, it shows me how the service team envisions the user journey.
Sometimes, it automatically spins up ancillary resources like IAM roles and SNS topics on its own. Other times, it tells you to go set them up yourself and then come back—which is irritating and counts as a point against the service.
After all, if I have to set up a bunch of other services first just to kick the tires on a new one, it’s frustrating. A number of customers flat out won’t go through that again. The last time I set up a custom IAM role, hackers came to my house and killed my goldfish! they cry, and who wants to deal with poor Goldie’s funeral more than once? They’re going to find absolutely anything else to work on instead, and I can’t blame them a whit for it.
Find a bug, win fame and glory
The first day a service is live is a great time to win fame and glory by finding bugs.
Until this point, the folks working on it have all been “too close to the service” in that they have context that mere customers don’t. They know what the service is supposed to do, how it’s designed to work, and tend to only go down their happy paths. Fun issues such as “hook it up to something in another AWS account” or “what if I do this with restricted permissions instead of the Admin role” get overlooked something fierce. Sometimes you’ll find typos, which has got to sting.
As an aside, something that I make it a point to avoid in these early reviews is mocking the service itself. There are teams of people inside of AWS who’ve spent months or even years working on the service in question, pouring blood, sweat, and tears into it.
If the first thing I do when I see it is publicly crap on it, that can’t feel great. Instead, I try to pick on something harmless—like the service name. Nobody spent 18 months naming Systems Manager Session Manager. And if they did, they frankly deserve to feel a bit bad about that monstrosity.
The final step: Turning things off
At this point, I’m mostly done with my review. I turn off anything I spun up. But I also set a reminder a day or so out to go back to that specialized account and scrutinize the bill for whatever sneaky thing snuck in that I didn’t expect—and that’s something I do periodically for that account.
For instance: If you spin up an Amazon Workspace, the pricing is pretty straightforward—except it creates a Simple Directory for you. As long as you’re using Workspaces, this is free. But when you stop using Workspaces, that directory persists and charges you 5¢ an hour as a tax for not having read the pricing documentation thoroughly six times, run your own experiments, and become lifelong pals with the service team who set the pricing dimensions.
Customer obsession apparently only goes so far.
And there you have it; that’s how over 90% of service releases come to me. There are variants, of course. But in short? I dig into these things so you folks don’t always have to.
You’re welcome to thank me on Twitter.
