Screaming in the Cloud - Episode 20: The Wizard of AWS

Episode Date: July 25, 2018

Today, we’re talking to Jeff Barr, vice president and chief evangelist at Amazon Web Services (AWS). He founded the AWS Blog in 2004 and has written more than 2,900 posts for it and another 1,100 for his personal blog. As chief evangelist, Jeff strives to explain the benefits of Cloud computing and Web services to anyone who will listen. Jeff is the voice of AWS. He does what he does best - exploits his superpower of explaining technology in ways that people can understand it. Jeff tries to be the same person all the time. He loves to meet people and go out of his way to say “Hello.” So, if you see him at re:Invent, say “Cheese” and take a selfie with him! Some of the highlights of the show include: Jeff uses AWS Workspaces for his blog; one of Jeff’s blogging principles is to not take anybody else's word for anything to the absolute best of his technical ability Zero Client: Jeff has no rotating hardware, disk drives, just a zero client; wherever he is, it's the same workspace AWS has something for everyone; it build things in response to customers’ questions, requests, and feedback Naming Services and Products: Is it helpful? Is it descriptive? Does it have any hidden meanings? Amazonian DNA and Dog Friendly Workspace: Jeff went from super fearful to accepting, to now thinking of dogs as incredible creations because they add fun and excitement to the office As part of hiring, each interviewer is assigned Amazon leadership principles (LPs) to ask questions that measure a candidate against those LPs What is the secret to getting hired at Amazon? Study the LPs to understand what they're about and be able to express your philosophies and history with LPs re:Invent makes sure customers understand services - What is it? What does it do? How do they put it to work? What are the best use cases for it? Things can never be too simple; you start from zero, put a lot of different things in there, and then you need the feedback to build in simplicity AWS is following a more on-demand approach than traditional reserve instances; it opens the door to being used in a lot of ways AWS does a lot of work before a launch to make sure it’s got infrastructure, scaling, monitoring, and capacity in place If you are a customer, talk to AWS and let them know what they're doing right or wrong; write a blog post, tweet about it, share it with them in some way Is the breadth of product offerings from AWS too vast? Is it offering too many things?  AWS was not explicit about where it was going with Cloud computing or do analyses or projections about it; it simply launched SQS and let it speak for itself Customer feedback shapes what Amazon works on; customers share and then AWS re-prioritizes to make sure it’s delivering the right thing at the right time Remember: It's not just bits and bytes, it's about the organic life form Links: Jeff Barr on Twitter Jeff Barr on LinkedIn AWS AWS Blog Jeff Barr’s Blog Amazon Machine Images Zero Client AWS Workspaces AWS Lambda Amazon Leadership principles re:Invent The Robot Uprising Will Have Very Clean Floors Serverlessly Storing My Dad Jokes in a Dadabase Days Until re:Invent.

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored by Iopipe. Iopipe is the best way to instrument your serverless applications and various Lambda functions, so you have a hope of understanding just what it is that they're doing. With a quick two-line change to your existing functions,

you get to see not just how often your functions run, but also what invoked them, how long they ran, whether they were cold-started or not, alerting when they error out if for some reason you care about that, tracing where they spend most of their time, and profiling to give you incredibly insightful perspective into functions you've long since forgotten writing. They're not just a sponsor, I'm a paying Iopipe customer. Be forewarned, there's a dark side. You can't unsee what Iopipe shows you. Some of the third-party APIs my Lambda functions call are incredibly latent. It's also probably not normal to have a Python loop that just iterates over a list of links take 45 seconds to complete. There's no escaping that sometimes the real observability

lesson is the brutal truths about ourselves and our code quality that we learn along the way. The first month is free. If you sign up and tell Iopipe that Corey sent you, they'll give you an additional month for free out of sympathy. Thanks again to Iopipe for their support of this podcast. Hello and welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Jeff Barr, AWS's Vice President and Chief Evangelist. Welcome to the show, Jeff.

Hey, Corey. How's it going? Oh, not too bad. Thanks for fitting me into your schedule. I know it's sometimes challenging, especially as the drumbeat of reInvent gets closer. Let's start at the beginning here. You're AWS's Chief evangelist. How did you get there, and what do you do? All right, so I like to think of my career as a long series of improbable events. Since I was very, very young, I was always the tech guy in the family, and when I

was very young, I was the one that would take apart lamps and put new wiring in them and replace electrical sockets. And then as a young teenager, I started to understand what computers were all about and started to study digital logic and the like and Boolean algebra. I ended up getting a computer science degree from American University back in, I think, 1985, before most of your readers were actually born, listeners. And for a long early part of my career, I would always be in the back room. I'd be building tech. And I was always sure that myself and my team, we were doing our job as related to building something really, really cool and awesome. But I quite often found myself a bit frustrated by we'd hand this really cool thing off to marketing. And then in my eyes, and of course, biased a little bit, they were never quite doing enough to market and sell what it is that we built.

Maybe they didn't understand what it was. Maybe it wasn't a great fit for customer needs. But regardless, we'd build something awesome only to find ourselves frustrated. So pretty early in my career, I started to add a little bit of marketing to what I was able to do. I would take it upon myself to go out and speak at events and conferences. And I found myself really at home with effectively one foot on the tech side, the out ways that I could take that deep understanding and then explain it to all different kinds of audiences in a way that they hopefully found not just useful but also somewhat entertaining along the way. What's interesting is you've been at Amazon for well over a decade now. And if you start stalking you on LinkedIn, there's an interesting progression where you went from evangelist to director to earlier this year to VP. How did you get to the point where you are effectively the voice of AWS?

I mean, a minute or two ago, I felt vaguely silly introducing you. If someone's listening to this show and doesn't know the name Jeff Barr, I question whether or not they've been paying attention. Well, that's a great honor, and I really appreciate that. As far as the career path and the promotions here, one thing I've really appreciated about Amazon and about AWS and working directly with Andy Jassy, especially in the early days, they've been really, really great at letting me be me. If you look at our org chart, and if you look at some of the more traditional VPs, they are running organizations with often hundreds or maybe even thousands of folks in those

organizations. And they have let me really carve my own path and just say, well, Jeff is really good at being Jeff, and we're not going to force fit him into an AWS mold and say, you must run a large team. You must do all these kind of business-y things. They simply said, do what you do best. Really exploit your superpower of explaining tech in ways that people can understand it. And it's been really gratifying to know that I had that unique path. And I've had quite a few colleagues come up and talk to me in the last couple months that actually said, you know, we're really encouraged by the fact that you were able to find this non-traditional path because it gives them some expectation that they too can

really focus on their strengths and be themselves and that they can have that expectation of growth and promotion through the year. So super honored to have that happen, and really, really happy that it did happen. Well, I can't think of too many people in the AWS ecosystem who are as dialed in to what Amazon is working on than you are. To that end, I saw you a few weeks back when you were introducing the new Amazon Linux 2 workspaces. And as it turned out for the 4th of July week, I was on vacation in rural Wisconsin, so far out in the boonies that Hicks make fun of it. And I brought my iPad with me, and what was astonishing was how smooth the experience was, how well it worked. And I was

frankly astounded that I hadn't discovered this service before. It's a hidden gem. What else is lurking around in the AWS service catalog that you think people either don't realize exists or take too lightly? Well, let's see. That's a big question. So if I could talk about workspaces for a minute, I'm super happy that you actually found the same things I did. It is a gem because before I used workspaces, when I'd hear virtual desktop, there was this big flashing light in my head that just said, boring, boring, boring. This is not of interest to you. This is an enterprise corporate thing. Oh, absolutely.

When you gave a talk about this a week ago, I expected it to be a story of here's Amazon's attempt at putting lipstick on this same pig. The experience did not match up to that expectation at all. Exactly. And this gets back to one of my main principles when I'm blogging about things. I don't take anybody else's word for anything. To the absolute best of my technical ability and based on a suitable environment, I will always get personal hands-on in-depth experience with the things that I blog about. So I started using workspaces as a user for the purposes of writing the blog post, really liked what I saw, found myself more and more working within the workspaces environment after I launched the blog post. And then within not that long of a period, I said, you know what?

I can actually be 100% in this workspaces environment. And I remember very definitively the day that I took my desktop PC and I put it over to our recycling shelf in our copy room. I'd switched over to what's called a zero client, which is this really small, lightweight box that's essentially a display processor, some networking, and a whole bunch of different ports. So I have no rotating hardware on my desk.

There's no fans. There's no disk drives. I have this little, tiny, slim zero client. And to me, the awesome thing is that wherever I am, if I'm at the office, if I'm at home, if I'm on the road, I log into my workspace and it's the same workspace. The configuration is exactly where I left it. The same set of apps are running. The same windows are open. And I don't have that momentary time when I have to wait for things to connect and sync and reestablish themselves.

I pick up where I left off. And it's hard to describe how valuable that is, not just from a productivity standpoint, but from a mental continuity standpoint where you don't have that little, oh, I left the wrong thing on the wrong PC, or I don't have everything configured exactly right in all of my different environments, or where are those bookmarks, or where's the file? You're simply reconnecting to the same environment. It just takes away a lot of mental overhead and mental friction. And that to me really shows not the value of workspaces, but the value of getting personal experience with technology in order to be authoritative when you talk about it. So that's a very, very quick overview of my workspaces experience.

As far as hidden gems, as you discovered, using workspaces while you travel is a great benefit. Another one that isn't quite so obvious is not sure exactly where you were or the level of connectivity that you had, but when you're connected to your workspace and you're downloading massive files, you're downloading those over Amazon's network with that massive bandwidth and low latency and well-connected all over the world. So you could be in rural Wisconsin, as long as you've got connectivity back to your workspace, regardless of the speed of that connectivity, your network IO to your workspace is going to run

at AWS speed, which is going to be better than anything you can get on your own. Yeah, I believe the published metric for AWS internal network transfer is fast with nothing quantitative. I think that's the number that we try our best to use.

So other hidden gems, I think there's really too many to pick out one. I actually hesitate to pick favorites only because I think of them almost like I do of my own family members. And you'd never want to designate a favorite among your family members.

There is really something for everyone, as you know. I think the fact that we build so much of this in response to customer questions and customer requests and customer feedback really means that it is going to satisfy this huge number of different customers and open up doors to lots and lots of different use cases. Absolutely. And even Uncle Simple DBs is still invited to Thanksgiving dinner. That's right. Oh, yes.

Classic Thanksgiving dinners. Those are always a lot of fun for me at my house because of the way that we have to schedule reInvent. And we've got the different venues booked out so far ahead for reInvent. Thanksgiving day for me is time sharing between getting the final touches on blog posts and running downstairs to spend time with my family back and forth. Oh, absolutely. I remember last year, I ran into you briefly at Replay and you started with an apology that you were so drained by the rest of the event. I didn't

expect more from you than a wave. The fact you even had the energy left to give a sentence based upon everything else that had happened that week was just astonishing. You're one of the more gracious people I think I've ever had the privilege of working with, let alone at AWS. Yeah, the hard-hitting journalism questions. Why are you such a nice guy? Yeah, no one ever asked that. Oh, good question. So one thing I've noticed when I look at you, when you read any of the various celebrity magazines or websites, and I have to admit to being a fan of some of those, you often see these letdown articles that says, oh, I was such a fan of such and such celebrity, and then I met them in person once and they treated me so horribly bad. And that's the story.

And I would never want to see a story like that emerge about me. So the philosophy that I've come up with is that I try to be the same person all the time. There isn't one Jeff Barr that switches into operation when I step in, when I put on my AWS cape and I'm AWS Jeff, and then I step out the door and I'm just me and I have a different personality. The easiest thing to do just says, I'm just me all the time. And I'm just naturally, I love to meet people. I go out of my way to say hello to people. I love it when I'm at reInvent and people stop me and say hello. And if they like to take selfies, that's totally, totally awesome. I do ask that they actually send me an email copy just so that I have a great record of

the time that I got to meet them. But it's so awesome to meet people and to realize that as far as I'm concerned, I'm just sitting at my desk and I'm typing. And then they come up and say, you know what, you've actually improved the quality of my life, of my career. Based on what I wrote, they've been able to learn something new. They've been able to improve in their job, maybe get a better job. And to me, I'm just sitting here looking at the keyboard, trying to find the right letters and symbols to push.

And somehow that translates into I've helped someone's life get better. So I find that super, super gratifying. As you should. It's difficult to find someone who is adept, not just the technology, but also at telling that story to people who are unfamiliar with it. I mean, it took me sitting in front of you giving a demo of workspaces before that finally to click in my mind. But enough of the Jeff Barr fan club. Let's get to the hard-hitting questions that tend to really, I guess, get to the meat of this. So Amazon machine images, that has... You mean Amis, right?

That's exactly the point. There are two pronunciations. There are people who pronounce it as AMI, and there are people who are wrong, who pronounce it as Ami, generally who work in Amazon. What's the story there? And why is this the particular hill that so many Amazon folks choose to make their last stand? Well, I think we always choose our names with care. And one thing that you learn when you work at Amazon and you see naming discussions start to come up, you almost always want to run the other way. Because if you look at a name and say that is not optimal, then the next thing you know, you're invited to some naming meetings and lists of dozens and dozens of names are presented and evaluated. You look at every name to see, is it helpful? Is it descriptive? Does it have any

hidden meetings that could come up later and make us regret the choice of name? I don't think we actually choose pronounceability as a criteria. And if you think back to the super early days of AWS, if you think back to when we launched EC2, the AMI was definitely one of the first AWS names that we emerged with. So in hindsight, could we have given a pronunciation guide? Probably could have. Now, one of the things I find interesting about this is that I have run into customers that actually pronounce AWS as Oz.

And I was in some other part of the country or part of the world the first time I heard it. And I have to say that the first five minutes, I actually wasn't sure what they were talking about. And you learn when you're meeting with folks that sometimes the best thing is let them go on and you have these little pieces of really unevaluated information in your head. And at some point, rather than having them clarify, you just try to figure out by context and suddenly it all dawns, you know, oh, they're talking about AWS when they say Oz. And so I would never correct them. I would let them use their own chosen pronunciation and let them go about their merry way with that.

But I have heard that pronunciation of AWS. I've definitely heard Ami and AMI, and it's reader choice. Well, at that point, if I ever get the privilege of introducing you for a keynote or something, I'm just going to call you the Wizard of Oz and see what you do with that. Cool. Okay. But that would also mean pay no attention to the man behind the curtain, which wouldn't result, right? Exactly. Other things that are distinct to Amazon culture, let's address one of the best parts about it, namely the dogs. Oh, yes. I was a little bitter for years after I interviewed at AWS many

moons ago, and they sent out a very nice warning that Amazon is a dog-friendly company. If I have an allergic issue, I should let them know so that I can go to a dog-free facility, which I most assuredly did not because dogs are wonderful. And then it felt like a bit of a bait and switch because out of the, I think, seven people who interviewed me, none of them were dogs. And that just felt like a real letdown. I wasn't quite prepared for it. But on a more serious note, what is it about the Amazonian DNA that makes it such a dog-friendly workspace? I mean, most legal types tend to shy away from the potential liability. It's not a great risk, but if it does happen, it makes headlines and that's a risk no one wants. So back in the early days of Amazon,

one of the early employees brought in a dog named Rufus. And for quite a while, when you put in a bad URL to the Amazon website, you actually got a 404 style page that had a picture of Rufus. I don't know if that picture is still there or not, but that was one of the original Amazon dogs. Now, what I found when I first joined the company, I was a lifelong avoider of dogs. I had been scared incredibly badly by a dog as a child, and I was absolutely terrified of dogs. And one of the first people that I met, I really wanted to work with him, but he had this very large and very scary dog in his office. My fear was such that at the point when the elevator opened and I got off on his floor, his dog would actually start barking. And I was totally sure she was going to just tear me piece by piece.

My desire to work with Rob Frederick really overwhelmed my fear of Nola, his dog. And I went from super fearful to accepting to now I think dogs are incredible creations. And I really just enjoy seeing them around. And I have to say that seeing my co-workers' dogs in the office and seeing them there, they actually add some fun. They add some excitement. The dogs are very well-behaved. I would actually say that the dogs are often at least as well-behaved as my co-workers and sometimes a little bit better. I've interviewed folks that are so excited about the Amazon dog culture that as part of their interview, they will tell me about the dog that they're planning to get as part of their onboarding to Amazon. So I think it's a really attractive part

of our culture. The dogs, they're fun to have around. I've never seen them cause trouble. Very rarely do they make any noise, and I love it. It's one of the more interesting and, would argue unique aspects of Amazonian culture. The other, if I had to pick from the vast, vast, vast field of things that Amazon does, would probably be the leadership principles. How have you, I guess, seen that differentiate Amazon from virtually every other company on the planet? Okay, so way back when I started in 2002, many of the current leadership principles were already in effect. I've looked and looked, but I can't find a copy that dates to that time. I think at that point, we probably had eight or nine. Over the years, in response to changes in the workforce

and changes in the company's requirements, we've updated and consolidated and introduced new leadership principles. We generally call them LPs for short. So there's currently 14 different LPs. You don't pronounce them lips? Go right ahead if you'd like. That's a new one. I've never heard them pronounced, but they are definitely the Amazon LPs in my mind. And what I've found is that as the company grows and as we hire people from all over the world, I know that as part of our hiring process that we're always interviewing candidates with respect to the different leadership principles. And you always know that when you're working with a colleague in the same office or the same country,

or you go halfway around the world, and you know that your colleagues have been interviewed versus the leadership principles, you know that they have successfully passed the interview, you have a lot of confidence that there's really a shared background there. I'm often asked by people from complete strangers that I meet on the street to family members, they will say, what is the amazing secret to getting hired at Amazon? And regardless of who they are, again, from strangers up to my own family members, I'll simply say, you need to study the LPs and you need to understand what they're all about.

And you should be able to express yourself, your philosophies, your history in terms of the different LPs. What we do as part of hiring is that each of the people that you meet with in the course of your interview day, they'll generally be assigned to one or two different leadership principles. So I did an interview last week, and I was asked to check on earning trust and on learning and being curious. And so I style my questions to really measure the candidate against that pair of leadership principles. Got you.

From there, do you find that some leadership principles are harder for people to learn? In other words, are some of them more built into who someone is versus what someone does? I actually think that most people have the roots of a lot of these, but they haven't had them called out in so many words. And as a way to counteract that, what I find is that our leadership strongly reinforces these principles at every opportunity. And they do them using the precise words that are the titles of the leadership principles. So we don't summarize them. We don't use synonyms for them. You'll be in a meeting with a senior leader and you'll do something great.

And they'll say, you know, Jeff, you showed great bias for action on this. And we love the fact that you did a dive deep on this particular aspect of the subject matter. So we try to use the exact phraseology so that it is reinforced. It does sound a little bit cult-like, but it is a shared set of principles. And one thing I find really interesting about these leadership principles is that once you've absorbed them into your brain, you'll use them in work situations, you might use them when you're out and about. And if you're not careful, you might end up using them with your own family, with better or with worse results sometimes. The Amazonian leadership guide to parenting, I'm sure, is just around the corner. Exactly.

So getting back to the things that make the lights blink, lately there's been a lot of focus at Amazonian events to, I guess, larger industry trends. The first and most obvious is serverless, but trailing closely behind that is IoT. How are you seeing those manifest in, I guess, the real world? It's neat to see on stage and all, but it's also, with respect to the wonderful Amazon marketing apparatus, this worked really well for this one company, and we're going to demo that on stage, is in some cases not as straightforward when you're attempting to implement it yourself at two in the morning. Well, I would hope that it is either as straightforward as we showed, or if it isn't, that someone needs to let us know,

and we will do our absolute best to make it better and better. One of the things that we focus on a lot here, and if you were able to attend any of the planning sessions for reInvent, reInvent is all about training and education. It's all about making sure that our customers understand the services in great detail, make sure that they understand what the services are, what they do, how to put them to work, what are the best use cases for those. So focusing on serverless, we're seeing customers really of all types, from startups all the way up to enterprises, really trending to serverless

very, very quickly. They love the fact that they can focus on their product versus thinking about all the infrastructure. They're tired of thinking about servers. They don't want to worry about operating systems or runtimes or load balancing. They simply want to build code. And then, to my way of thinking, you grab it in both hands and you throw it up into the sky, and the sky grabs it and says, I've got it from here. I'll take care of the mundane aspects.

Just go run your business. So to me, that's the serverless side. I think we're seeing adoption in all different spheres. We're seeing lots and lots of growth. I've got some metrics here. Let's see. So at this point with Lambda, we've got hundreds of thousands of customers that are making use of Lambda. I think we saw somewhere around 300% growth year over year

with Lambda usage. I think the future is looking really, really bright there. We continue to listen and to learn and to add additional features to Lambda based on our customer requests. I think that Lambda is one of those transformative technologies. I know Simon Wardley is very bullish on the entire concept, as well as other thought leaders of industry, as it were.

And having dipped my toes in the water to experiment with it a lot myself, it feels in some respects to be reminiscent of somewhat early days EC2. In that back then, it was challenging to work with. it feels in some respects to be reminiscent of somewhat early days EC2. In that back then, it was challenging to work with. There were partners who launched whose entire premise was making it easier to manage. Whereas today, launching something on EC2, even at scale, requires a couple of mouse clicks or a Terraform or CloudFormation script. And it's become straightforward and simple.

In the early days, it wasn't like that. And it still feels like there's a bit of technical complexity learning curve that needs to be well understood before people see success in the serverless space. Is that something that resonates at all with what you're seeing? Or is that more to do with the fact that I'm secretly a terrible coder and I just haven't realized it yet? Well, I haven't seen your code, but I'll be happy to check it out later if you'd like. But I do think that people are getting it. And given the amount of users that we're seeing, and the blog posts, and the how-to articles,

absolutely for sure people are figuring this out. With that said, things can never be too simple. And I think that what is not always understood about simplicity is that you don't start from zero and then put one feature in place and say, okay, we are simple. Quite often what happens is that you start from zero, you put a lot of different things in there, and then you need the feedback, you need the experience, you need to be able to observe metrics, and you need to see how things are being used to really give you that guide to actually building in simplicity. So simplicity is not often the first step. It's the result of a lot of observing, a lot of iteration, a lot of understanding to finally get to that point where we say, okay, now it is as clean and as straightforward and as directed as possible.

So you have to do that while you're addressing just an ever-broadening set of customer use cases. So just last week, we gave our customers the ability to use the simple queue service to trigger Lambda functions. And so people have been asking for that for a while. There were, from what I understand, some really interesting technical challenges to be solved to make that work as we wanted it to, to make that really easy and straightforward for our customers. But we knew that the demand was there. We iterated internally

with a number of different possible models until we got to the point where we said, this is the one that works and this is the one that we'd like to share with our customers. We're very, very careful that we never want to give something out to customers and say, this is the best way to do it. Write lots of code, and then later say, you know, we changed our minds, delete everything, start fresh with a different model. So as much as humanly possible, we strive to keep everything future-proof. And we ask ourselves in our planning process, we'll always say, as we're putting this new feature into place, does this create any one-way doors that once we step through that one-way door, would we end up in a regrettable situation where we need to undo and step back and change something?

And if we're going through a one-way door, we will make sure that we explicitly recognize it, call it out, and make sure that we understand fully the implications of that one-way door. Have you seen any interesting tie-ins between serverless and IoT themselves? As far as, for example, earlier on one of the episodes early in the evolution of the show, we had Ben Kehoe on from iRobot. And he talked at some length about how Roombas wind up using IoT embedded, but also have a lot of Lambda-side server processing. And that was a fascinating interplay that hadn't really occurred to me in that way. Well, I was just about to tell you all about iRobot, and it sounds like you kind of jumped a little bit into the future or the past

there. But I do think that that is a great use case. One of the interesting things about their model that blends in really well with IoT and then really with serverless is they go out and they'll sell massive numbers of devices on an unpredictable schedule. So I think it was the first Amazon Prime Day. They sold 14,000 or so iRobots on Prime Day. Customers received those, plugged them in, hit the button to say, go off and clean my house.

And so you get that sudden surge of traffic, which is absolutely a great use case for serverless. You don't have to think ahead of time about the scale. If every customer says, I'd like to clean my house at 3am in Pacific time, no big deal. Everything will scale up in order to accommodate. And if all the robots shut down and go back to their docking stations to recharge, the load subsides, and then your infrastructure costs go down correspondingly.

So I think that's a neat use case where you can deal with both the surge as you bring in new customers, and then deal with the unpredictability of when customers are actually going to be making use of those devices. One of the most valuable aspects to me of working with Lambda-driven architectures, as I have been myself for the past six months or so, other than the native hilarity in exposing

my terrible code manifesting into terrible architectures, has been the complete freedom of only being charged exactly when your code runs. It turns out I don't tend to go viral nearly as much as I'd wish. So effectively, many of my Lambda charges for some of my functions round up to one cent over the course of a month. And that is an incredibly powerful economic angle. And by the time it starts to get really expensive, you're either doing something at massive scale, or you've built something that winds up manifesting in such a way that it doesn't need to be written the way that it is. I think it's nice to see it getting more into an on-demand approach than the traditional reserved instances, which tend to come from a different model of predicting what your

on-demand usage is likely to be over the next one or three years. It completely cuts the cord from the data center past and into when it runs, while it's running, and that's all that you care about. So from a billing model perspective alone, I find that to be just a spectacular evolution. Certainly, it is. And the neat thing is, to me, not just the cost savings. I think those are really important. But when people understand this flexibility and they say, I can build things and it's only going to cost me when it runs. And they get that into their thought process as they start to think about the applications they can build. And you might think of applications that are only busy once a day or once a week or once a year or only under emergency conditions, let's say. And you can build those and they can be there and they're effectively latent and ready to run. When the need comes in, you do them, you activate them and away they go. And you spend your penny or two pennies or your dollar. And so once you start understanding that,

I think it really opens the door to being used in a lot of ways. And like anything brand new, we've barely scratched the surface of what's possible. It takes years and years and years before the model is so deeply burned into people's thought processes that the incredibly cool use cases start to emerge. We've seen great ones, but at some point we're going to find ourselves actually surprised by the use cases that come out.

I think you're probably right on that. Well, think of how long it took when PCs were out before the power of the graphics cards were fully exploited. The computers were there for a while, the video cards were there for a while. No one thought you could do that level of graphics and action on the screen. And this real-time 3D and nice shadows and lighting and so forth, that was simply impossible given the technology of the day until people saw, oh yeah, that actually can be done. But that was exploiting things that had already been there for a couple of years. And I think a lot of the technologies that we're talking about today are going to be the same way. It's going to be a little while before people fully push the edge and push it so far that we suddenly look at that and say,

we could have done that years ago, we just didn't know that we could do that. I think that part of the challenge is that the services at launch are generally not fully featured. In many cases, they bake over a period of years and gain capabilities. And at the same time as they're gaining features, I think that customers need to get exposure to these services and what paradigms they create. And in turn, they start shaping their use patterns to it. So in many ways, it's a meet-in-the-middle type of situation

where the service becomes more fully baked as customers begin to mature their understanding of these services. That's true. And I think one thing that's not always understood is that launching with a minimal feature set is really an important part of our model. A lot of the work that goes on before the launch is getting the right infrastructure in place, making sure that when we launch something that on day one, if hundreds or thousands of customers go and activate the new service, that we've got the scaling, the monitoring, we've got the capacity in place to deal with all of those. You want to make sure that you understand how you're going to be connecting

with and listening to customers and then iterating very, very quickly after the launch. So it's almost like an iceberg kind of a model where you always think that most of the iceberg is beneath the surface and then they always say, well, only the top 10% is visible. You think of a lot of what happens in the time leading up to the launch as really building that infrastructure and saying, we're putting this infrastructure in place so that we can innovate very, very quickly

after the initial launch. And we're going to do that really in response to great customer feedback. So if there was a customer responsibility, I would say, if you are a customer of one of these early services, talk to us, let us know what we're doing right. Let us know what we continue to need to do for you. Don't be shy. Don't think, well, I'm just a small customer. They won't listen to me. Reach out, write a blog post, tweet about it, share it with us in some way, post it on the forum, hunt us down at reInvent and corner us and say, I've always wanted to talk to you and and here I am, and here's my ideas. Or if you come to visit us as a corporate customer and you're meeting with us in one of our executive briefing centers,

come with your comments, your questions, your ideas, your suggestions, the small features, the big features, and everything in between. We absolutely just live and breathe from all of that customer data. From my own experience, having done every means of feedback you just listed, I can echo that in the sense of I've been told before why I'm wrong in my assessment of a product, but I have never yet been made to feel like a jerk for having asked the question or having asked for a feature that wasn't aligned with Amazon's vision of a service. And that's a powerful thing. As a company, Amazon makes it very easy to ask questions and deliver feedback

in a way where even if it's not actioned immediately, it feels like it's being appreciated. To that end, I'm known as something of a vocal critic of AWS. We love you for that. Which I appreciate. You're not sending the hit squads for me. But if you do dig into my criticisms, they all tend to be very tactical. They're related to a feature or a positioning of a specific offering. Holistically, though, I don't see a whole lot that

AWS is getting wrong. There's a possible counter-argument to be made there that maybe the breadth of product offering is too vast, but it's really difficult to frame actionable criticism around the idea of, you offer too many things that solve specific needs for specific customers. You offer too many things I can use is pretty crap as far as criticisms go. Do you see anything that I'm not seeing with respect to AWS failing to address the needs of its market in the larger context rather than the implementation tactical side? Well, I would certainly hope not. And I would really hope that just the number of eyes and ears that we have listening to customers is going to counteract that and make sure that we don't

miss anything that is big. And our customers are just so good at coming to us and sharing with us the challenges that they have. And sometimes it's something that can be addressed by a point feature, but sometimes they really come to us and saying, here's a whole business opportunity that we think that would be appropriate for Amazon to get into. And what is actually interesting in respect to what you just told me, I was in the Nordics just last month meeting with customers there. And one of them said,

you're launching stuff so quick and we can barely keep up. And then they said, and here's all the ideas for other things that we really need you to launch as well. And it was this really interesting paradox that I pointed out to them of they were complaining about the pace of innovation. And then they said, speed up that pace of innovation, if at all possible. Jeff Bezos famously had a quote that Amazon is willing to be misunderstood for long periods of time. In the microcosm of AWS, do you see any ways in which the platform is being misunderstood today in ways that are likely to clear up in the future? I would hope not. So interestingly enough, this morning as I was walking to the office,

I was listening to a podcast. You'd interviewed somebody from Lucidcharts. And in that podcast, I saw that there was a little bit of confusion about the way that some of our services were priced and worked. And I was taking some mental notes to make sure that the relevant product managers were going to listen to mental notes to make sure that the relevant product managers were going to listen to that podcast and make sure that they had those pieces of our documentation and pricing information properly explained.

So I take it pretty personally if we've put something out there and it is explicitly confusing. I will go back to Teams time and time again. And if they give me something that doesn't sound right, or if I'll think, you know, there's actually no way that computers work like that, that can't possibly be the right way.

I will go back and just insist on as precise information as possible. And once or twice, they may have actually asked them to let me look at their code so I can fully understand what's up. So at the feature level and service level, I don't think we're doing anything that would be thought of as being misunderstood. Now, I do think back to the very early days of AWS, when the first service that we launched was the simple queuing service, or SQS. We launched that, and I'm pretty sure that customers looked at that and said,

it's fairly bizarre that my online bookstore, which is how most people thought of us at the time, why exactly would a bookstore be selling message queuing to me? This just makes a negative amount of sense. And I just don't get it. We could have at that point chosen to lay out a vision of, well, here we are. And here's where we think we're going with cloud computing, and here's how we expect it to take off over the next years and decades. Because we certainly had done the analysis and we've done lots of projections, but we didn't do that. We simply launched SQS. We put it out there, named it, described it, identified some use cases, showed the APIs, showed the pricing model, and really just invited developers to have at it if they found it at all useful.

And there's other ways we could have done that. We could have laid out the roadmap. We could have said, this is just the first of 100 things that we hope to do. But we were just willing to just really put that service out there and let it speak for itself. And then we went on from there. We launched S3. We launched EC2.

I think at that point, people started to really get the idea that we were now revving up to do this set of on-demand self-serve web services. But we never really had to call that out explicitly. We never had to make some gigantic announcement that says, Amazon is now trying to revolutionize the future and lots of smoke and mirrors and stuff like that. Just really straightforward matter of fact, here it is. We sincerely hope that you find it useful kind of announcements.

I think that it's become apparently clear that Amazon plays the long game. But Mike, one of my questions for you is, how does customer feedback feature into that? Some of the moves that Amazon is making are pretty obviously aimed at 2020 and beyond. Whereas customer feedback in many respects tends to manifest itself as, here's what I would like about 20 minutes ago, please. And there's a certain time horizon difference between those. How does customer feedback shape what Amazon is working on? So customers are actually getting good at sharing not just what they want, but their own roadmaps and timeframes for doing it.

And especially when we bring them into our briefing center, we start every day, we start with a session we call the voice of the customer. So before we say word one, other than, well, welcome, and here's the bathroom, and here's your breakfast, of course, we welcome them, and we turn the table over to them. They start to present, and we listen to the customer first, and we get a sense from them. They'll often say, here we are. We're about to embark on this digital transformation.

We're trying over the course of the next, let's say, one, two, three years to make some sweeping changes to our company and the way we think and the way we act and what we do. So we use those timeframes to really inform what it is that we are up to. And one of the things I've noticed as I watch the various general managers and product managers in action is that there's a real art to the timing. There's really not value in launching things too soon. And I have seen that quite frequently as we listen to our customers and as they tell us what they want to do,

that the GMs will aggressively reprioritize based on what customers are actually telling us. So if we would propose a set of features and a roadmap to customers, often under NDA, we might say, here's our development agenda for the next 6 to 12 months. Customers might say, you know, these are all great, and the tech part of me is just salivating over these. But the reality is that the business side can use these things more quickly than these other particular things. And if we see a trend there, then we will aggressively reprioritize to make sure that we're delivering the right thing at the right time. And this is part of the reason why we're very, very reluctant to share the longer-term roadmaps. There is definitely a sense that we

don't want to spill the beans to competitors, but I would never, ever want to make some kind of a promise, which is really what a roadmap is. The roadmap is a promise, but then if we end up reprioritizing because the world changed, I wouldn't want to disappoint a customer in any way because of a roadmap change. Because you share the information and you say, here's where we are, but it's all subject to change. But as that gets shared throughout the organization, the caveats tend to disappear and the possibilities turn into facts more quickly than than you might imagine so i i would rather just delight people with launches rather than to

tantalize them with roadmaps in many cases i would agree it tends to lead to a much better experience when instead of talking for two and a half years before something launches about how great it's going to be surprise here it is we think you'll like it exactly getting something a bit more light-hearted there have been a few interesting Twitter hashtags over the past couple of months. AWS drinks, which I have the shame of having started, and dogs of AWS, which due to Amazon's excellent hiring practices, I don't work there, so my dogs don't count at the current point in time. How do those tend to be received internally at Amazon? Well, let's see. So the dogs of AWS, there was no deep strategic thinking behind that. time. How do those tend to be received internally at Amazon?

Well, let's see. So the dogs of AWS, there was no deep strategic thinking behind that. My dog, Luna, had just had her summer haircut. I just had picked her up from the groomer, and I thought she looked really, really, really nice. And my wife was out working, and she said, send me a picture of Luna as quick as you can. I carefully posed Luna, got a great shot, and I thought she looked so nice that I said, you know what? I think it was a Friday. I said, why not tweet this and just share it? I invented the hashtag on the spur of the moment. And it was just so cool to see a lot of my colleagues just chime in with their own dogs.

It was actually really, really touching to see that among all the current dogs, there were memories of dogs past that had unfortunately passed on. And it was really just super neat to do. And despite the fact that they were dogs, I think it was a very humanizing kind of a moment to realize that there are people and there are dogs behind the scenes. And I think that's important to remember about a lot of this technology. It's not just bits and bytes. It's about the organic life forms, I guess might be the right way to put it. Now, on the drinks of AWS, that was the most hilarious hashtag ever. And I think the lesson from that is that sometimes the thing you do incidentally or spur of the moment or guided by an intuition that's so deep you don't even know it was there,

you do something that actually has this long-term interesting value. And I think that that ability to take either a feature or a challenge or an out-and-out problem with AWS and to summarize it very succinctly and to come up with a memorable name for it, I think there was considerable value there. And I will tell you that those were shared extensively internally and that people saw the humor in it. And they also saw the truth behind the humor that says,

oh, very, very interesting that there was one that you did about cloud formation, I think, that said, well, 30 minutes to get your drink, and then you reject the drink, and then 20 minutes to pour the drink down the drain, something like that. And it's fascinating to see the outside view. Because we always see this nice idealized view from inside the organization. And to see what does it look like from the outside is helpful and entertaining to us as well. Yeah, I believe that

was someone else's. I don't want to steal credit for things I didn't do. Hey, but you started it. Uh-oh. So last question before I let you go. reInvent is on the horizon. Are there any, or as from years past, as some of us like to call it, Amazon's complex queuing service,

can you disclose anything about the plans you have coming up for the conference that people should be aware of? I'm not asking for information on service launches. That timing is always an interesting thing, and I'm not asking for anything embargoed. But I am curious to know, what should people plan for? How will this differ from last year? And what should people do to get the most out of their experience?

Okay, so I just checked this morning. There's a site, I think it's called daysuntilreinvent.com. And there are a scary 140 days left, which always sounds like a big number until you hit the panic button. And then you realize you should have actually panicked quite some time ago. So we're thinking and acting a lot on terms of dealing with scale. Last year, we had 43,000 people at reInvent. And every year we say, how can we make this more efficient and smoother and better for our attendees? One of the interesting things I'm seeing this year is that a lot of the same scaling principles that work for cloud architectures, we're now applying to the

physical and communication challenges of reInvent. We're looking to optimize the campus shuttle system. Last year, you probably noticed that we had buses that went on routes, and they would go from A to B to C to D. So that's really one way to run a network. But we found that a better way, and we're going to put this into practice this year, they're going to be point-to-point routes. So you'll get on a bus, it will have a particular destination, and you're not going to have to be on the bus as it transits, or not. Instead of buses, we're supposed to say shuttles. You'll be on the shuttle from

A to B, and you're not going to have to wait while it stops at the other locations. We're adding multiple pickup and drop-off points for the shuttles. We've got some surprises around ride-sharing and monorails. We are trying to get a teleportation system in place, but the quantum physics are still not cooperating in that regard. Oh, of course. It sounds like you're upgrading from token ring to full mesh. Yeah, that's a good way to put it. We are working to make sure that as many customers as possible can get access to the sessions. We're going to make sure that the sessions are replicated, essentially horizontally replicated across the different venues.

So we'd like customers to not have to spend as much time traveling from point to point. We are working to make the mobile app more lively and make it more location aware, help you to find sessions, tell you what's happening around you. As far as what customers should do, they should register. I get emails every year from people I have not heard from for many years, just begging to be let in after reInvent inevitably sells out. We have some webinars that are called How to reInvent. People should spend some time looking at the session catalog, which I think will be published really, really soon.

Spend a lot of time prepping. Make sure you bring good shoes. Make sure you are physically able to walk miles and miles and miles per day. And then arrive with an open mind and ready to just listen and learn. Meet lots and lots of folks. I would ask people, if they see me, never, ever, ever hesitate to stop and say hello. I'm never too, never, ever, ever hesitate to stop and say hello. I'm never too busy. I'm never too rushed to stop and say hello. Selfies are always free. I will have some brand new Jeff Barr stickers and always happy to give those out. And I absolutely love to meet people. And it really, really brings to me a lot of... It's just very, very gratifying to meet people that have in some way benefited from the work that I've done. So please stop and say hello.

And Lord knows there have been a lot of those people out here. I consider myself one of them. Jeff, thank you so much for taking the time out of your schedule to speak with me today. It's been my pleasure, Corey. Thank you again. I'm Corey Quinn, and this is Screaming in the Cloud. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at Screaminginthecloud.com or wherever fine snark is sold.