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
Full Episode Transcript:
Corey: This episode is sponsored by IOPipe. IOPipe is the best way to instrument your serverless applications 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 if you care about that, tracing where they spend most of the time, and profiling to give you incredibly insightful perspective in the functions that 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 functions API, 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 lessen, is the brutal truths about ourselves in our code quality that we learned along the way. The first months 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.
Corey: 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.
Jeff: Hey, Corey, how's it going?
Corey: Not too bad, thanks for fitting me into your schedule. I know it's sometimes challenging especially as the drumbeat of re:Invent 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?
Jeff: I like to think of my career as a long series of improbable events. Since I was very young, I was always the tech guy in the family. When I was very young, I was the one that would take apart lamps and put new wiring in them, and replace electrical sockets.
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 1985 before most of your listeners were actually born.
In the early part of my career, I would always be in the backroom, I'd be building tech, and I was always sure that myself, and my team, we were doing our job as––we liked building something really cool and awesome. I quite often find myself a bit frustrated by, we 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 build something awesome, only to find ourselves frustrated.
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. I found myself really at home with effectively one foot on the tech side, the other foot on the marketing side, using my computer science background to understand complex things.
Over the course of years and really actually decades, I figured 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.
Corey: I would agree with that. What's interesting is you’ve been at Amazon for well over a decade now, and if we 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?
A minute or two ago, I felt vaguely silly introducing you. If someone's listening to the show and doesn’t know the name Jeff Barr, I'd question whether or not they've been paying attention.
Jeff: 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 appreciate 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 orchard and if you look at some of the more traditional VPs, they're running organizations with often hundreds or maybe even thousands of folks in those organizations, and they have let me carve my own path and just say, "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 businessy things." They simply said, "Do what you do best, really exploit your superpower of explaining tech in ways that people can understand it."
It's been really gratifying to know that I have that unique path and I've had quite a few colleagues come up and talk to me in the last couple of months that actually said, "We're really encouraged by the fact that you were able to find this nontraditional 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 years. I'm super honored to have that happen, and really happy that that did happen.
Corey: Well, I can't think of too many people in the AWS ecosystem who is 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. As it turned out for the 4th of July week, I was on vacation in rural Wisconsin, so far out in the boonies that techs make fun of it.
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 catalogue that you think people either don't realize exists, or take too lightly?
Jeff: That's a big question. 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. This is not of interest to you, this is an enterprise corporate thing."
Corey: Absolutely, when you gave a talk about this a week ago, I expected it to be a story of, "Here's Amazons attempt at putting lipstick on the same pig." The experience did not match up to that expectation at all.
Jeff: 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.
I started using workspaces as a user for the purposes of writing a blog post, really liked what I saw, found myself more and more working within the workspaces environment after I launched a blog post, and then within not that long of a period I said, " I can actually be 100% in this workspaces environment."
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 switch over to what's called a zero client which is this really small lightweight box it's essentially a display processor, some networking and a whole bunch of different ports.
I have no rotating hardware on my desk, there's no fence, 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'd pick up where I left off. 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, "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 is the file?" You're simply reconnecting to the same environment. It just takes away a lot of mental overhead and mental friction. 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. That's a very quick overview of my workspaces experience.
As far as hidden gems, as you discovered using workspaces while you travel, 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, massive bandwidth, low latency, and well connected all over the world. 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 IoT, your workspace is going to run at AWS speed which is going to be better than anything you can get on your own.
Corey: Yeah, a published metric for AWS internal network transfer is fast.
Jeff: I think that's the number that we try our best to use. 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 built so much of this in response to customer questions, and customer request, and customer feedback. It 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.
Corey: Absolutely, and even uncle simple DB's are still invited to Thanksgiving dinner.
Jeff: That's right. Classic Thanksgiving dinners, those are always a lot of fun for me at my house because of the way that we have to schedule re:Invent, and we've got the different venues booked out so far ahead for re:Invent. 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.
Corey: Absolutely, I remember last year I ran into you briefly at Replay and you start with an apology that you were so drained by the rest of the event. I didn't expect more from you in a way, the fact even have 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 the privilege of working with let alone at AWS. The hard hitting journalism questions, why are you such a nice guy? No one ever asked that.
Jeff: Good question, so one thing I've noticed 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 let down articles that says, "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." That's the story, and I would never want to see a story like that emerge about me.
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 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." Naturally I love to meet people. I go out of my way to say hello to people. I love it when I'm at Re:Invent and people stop me and say hello, and likes to take selfies, that's 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. 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've actually improved the quality of my life and 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. 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. I find that super gratifying.
Corey: 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. It took me sitting in front of you giving a demo of workspace before that finally clicked in my mind. 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. Amazon machine images.
Jeff: You mean AMI right?
Corey: That's exactly the point, there are two pronunciations, there are people who pronounce it as A-M-I, 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?
Jeff: I think we always choose our names with care, and one thing that you learn when you work at Amazon, and you see naming discussion start to come up, you almost always want to run the other way because if you look at the 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 meanings 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, AMI was definitely one of the first AWS names we emerged with. In hindsight, could we have given a pronunciation guide? Probably could have.
One of the things I find interesting about this is that, I have ran into customers that actually pronounce AWS as “OS.” 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. 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 it out by context, and suddenly it all dawns to you, they're talking about AWS when they saw “OS.”
I would never correct them, I would let them and let them use their own chosen pronunciation and let them go about their merry way with that. I have heard that pronunciation of AWS, I've definitely AMI and A-M-I, it's reader's choice.
Corey: 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.
Jeff: Cool, okay but that would also mean pay no attention to the man behind the curtain which wouldn't result right?
Corey: Exactly. Other things that are distinct to Amazon culture, let's address one of the best parts about it, namely the dogs. 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 allergic issue I should let them know so 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 interviewed me, none of them were dogs, and that just felt like a real let down I wasn't quite prepared for it.
On a more serious note, what is it about the Amazonian DNA that makes it such a dog friendly workspace, 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 risk that no one wants.
Jeff: Back in the early days of Amazon, one of the early employees brought in a dog named Rufus, and for quite awhile 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.
What I found when it 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 want to work with him but he had 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. I went from super fearful to accepting, to now I think dogs are incredible creations. I really just enjoy seeing them around. I have to say that seeing my coworker's 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 coworkers 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. 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.
Corey: It's one of the more interesting and I would argue unique aspects of Amazonian culture. The other if I had to pick from the vast field of things that Amazon does would probably be the leadership principles. How have you seen that differentiate Amazon from virtually every other company on the planet?
Jeff: 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 back to that time. I think at that point we probably had eight or nine.
Over the years in response to the changes in the workforce, and changes in the company's requirements, we've updated, and consolidated, introduced new leadership principles, we call them LP's for short. There's currently 14 different LP's.
What I've found is that as the company grows, and as we hire people from all over the world, I know that it is a part of our hiring process that we're always interviewing candidates with respect to the different leadership principles.
You always know that when you're working with a colleague in the same office, in 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, there's really a I 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?"
Regardless of who they are, again from strangers up to my own family members, I'll simply say, "You need to study the LP's, 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 LP's."
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. I did an interview last week, and I was asked to check on earning trust and on learning and being curious. I style my questions to really measure the candidate against that pair of leadership principles.
Corey: 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?
Jeff: 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, 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 leadership principles.
We don't summarize them, we don't use synonyms for them. You'll be in a meeting with the 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."
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 absorb 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.
Corey: The Amazonian leadership guide to parenting. I'm sure is just around the corner. Getting back to the things that make the lights blink. Lately, there's been a lot of focus at Amazonian events to larger industry trends. The first and most obvious a Serverless, but trailing closely behind that is IoT.
How are you seeing those manifest in the real world? It's neat to see onstage 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, in some cases not as straightforward when you're attempting to implement it yourself at two in the morning.
Jeff: I would hope that it is either as straightforward as we showed, or if it isn't, that someone needs to let us know, we will do our absolute best to make it better and better. One of the things that we focus on a lot here, if you're able to attend any of the planning sessions for Re:Invent. Re:Invent 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 this?
Focusing on Serverless, we're seeing customers really of all types, from startups all the way to enterprises, really trending to Serverless 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 run times, or a load balancing. They simply want to build a code, and then it to my way of thinking, you grab it with both hands, and you throw it up to 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." 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. 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 bright there. We continue to listen, and to learn, and to add additional features to Lambda based on our customer requests.
Corey: 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 dip 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. Back then, it was challenging to work with, there were partners who launched this entire premise, it 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 cloud formation script and it becomes straightforward and simple.
In the early days it wasn't like that, 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?
Jeff: I haven't seen your code, I'll be happy to check it out later, if you'd like. I do think that people are getting it, given the amount of users that we're seeing, 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. 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.
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 clean, it’s straightforward, and is directed as possible." You have to do that while you're addressing just an ever broadening set of customer use cases.
Just last week, we gave our customers the ability to use the Simple Queue Service to trigger Lambda functions. People have been asking for that for awhile. 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.
We knew that the demand was there, we iterated it 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 would like to share with our customers.” We are very careful, we never want to give something out to customers and say, "This is the best way to do it." Lots of code, and then laster say, "We changed our minds, delete everything and start fresh with a different model." As much as humanly possible, we strive to keep everything future proof.
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 door?” So that once we step through that one way door, what we end up in a regrettable situation where we need to undo, and step back, and change something? 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.
Corey: 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 from iRobot, and he talked at some length about how Roombas wind up using IoT embedded, but also a lot of Lambda side server processing. That was a fascinating interplay that hadn’t really occurred to me in that way.
Jeff: I was just about to tell you all about iRobot, and it sounds like you've kind of jumped a little bit into the future or the past there. 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 with Serverless is, they go out and they’ll sell massive numbers of devices on an unpredictable schedule. 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." 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 3:00 AM in Pacific time." No big deal, everything will scale up in order to accommodate and if the robot shut down and go back to the docking station to recharge, the load subsides and then your infrastructure cost go down correspondingly.
There are use cases where you can deal with both the surge as you bring in new customers, and then deal with the unpredictability of when the customers are actually going to be making use of those devices.
Corey: 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 and exposing my terrible code, manifesting the 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 wish so effectively, many of my Lambda charges for some of my functions round up to $0.01 over the course of the month. That is an incredibly powerful economic angle. By the time it starts to get really expensive, if 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 reserve 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 datacenter past and then into when I runs, while it's running, and that’s all that you care about. For a building model perspective alone, I find that to be just a spectacular evolution.
Jeff: Certainly, it is, and the neat thing is to me not just the cost settings, I think those are really important, but when people understand the 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.
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. 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 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.
Corey: I think you're probably right on that.
Jeff: Think about 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 they people saw that actually can be done.
That was exploiting things that had already been there for a couple years, I think a lot of the technologies that we're talking about today are going to be the same way where it 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."
Corey: 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.
In turn, they start shaping their use patterns to it. In many ways, it's a meat in the middle type of situation where the service becomes more fully baked as customers begin to mature their understanding of the services.
Jeff: 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 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 quickly after the launch.
It's almost like an iceberg kind of a model where you always think that that most of the iceberg is beneath the surface and then they always say only the top 10% is visible. You think a lot of what happens in the time leading up to launch is really building that infrastructure and saying, “We're putting this infrastructure in place so that we can innovate very quickly after the initial launch,” and we're going to do that really in response to great customer feedback.
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, "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 Re:Invent and corner us and say, "I've always wanted to talk to you 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 absolute just live and breathe from all of all of that customer data.
Corey: 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. That's a powerful thing.
As a company, Amazon makes it very easy to ask questions, and deliver feedback in a way where it's 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, which I appreciate that you’re not sending the hit squads for me.
If you do dig into my criticisms, they all tend to be very tactical. They're related to a feature or a positioning of the 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 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 could view as 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 this implementation tactical side?
Jeff: I would certainly hope not and I would really hope that just the number of eyes and ears that we have listed to customers is going to counteract that and make sure that we don't miss anything that is big. 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're really coming to us and saying, "Here's a whole business opportunity that we think that would be appropriate for Amazon to get into."
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 say, “Here's all the ideas for other things we really need you to launch as well.” It was this really interesting paradox that I point out to them of, they were complaining about the pace of innovation, and then they said speed up the pace of innovation if at all possible.
Corey: A famous Jeff Bezos quote was 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?
Jeff: I would hope not. Interestingly enough, this morning as I was walking to the office, I was listening to a podcast you interviewed somebody from Lucid Charts. 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 we're going to listen to the podcast and make sure that they have those pieces of our documentation and pricing information properly explained.
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, “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 I may have actually asked them to let me look at the code so I can fully understand what's up. At the feature level in and service level, I don't think we're doing anything that would be thought of as being misunderstood.
I do think back to the very early days of AWS, 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 API, showed the pricing model, and really just invited developers to have that and if they found it at all useful.
There's other ways we could have done that, we could have laid out the roadmap, we could have said, "This is the first of 100 things we hope to do." But we're just willing to just really put that service out there and let it speak for itself. 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 served web services.
We never really had to call it 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 you find it useful" kind of announcements.
Corey: I think that it's become apparently clear that Amazon plays the long game, but 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." There's a certain time horizon difference between those. How does customer feedback shape what Amazon is working on?
Jeff: Customers are actually getting good at sharing not just what they want, but their own roadmaps and timeframes for doing it. 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. Before we say word one other than, "Welcome, here's the bathroom, here's your breakfast." 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 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." We use those time frames to really inform what it is that we are up to. 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 and launching things too soon.
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 re-prioritize based on what customers are actually telling us.
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, "These are all great and the tech part of me is just salivating over this." But the reality is that the business side can use these things more quickly than these other particular things.
If we see a trend there, then we will aggressively re-prioritize to make sure that we're delivering the right thing at the right time. This is part of the reason why we're 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 re-prioritizing because the world changed, I wouldn't want to disappoint the customer in any way because of our roadmap change because, you share the information and you say, "Here is 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 you might imagine.
I would rather just delight people with launches, rather than to tantalize them with roadmaps and in many cases.
Corey: 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 or how great it's going to be, surprise, here it is. We think you'll like it.
Getting somewhat a bit more light hearted, there have been a few interesting Twitter hashtags over the past couple of months, #AWSdrinks, which I have the shame of having started, and #dogsatAWS 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?
Jeff: The #dogsatAWS, there was no deep strategic thinking behind that. My dog Luna had just had her summer haircut, I just had a picture from the groomer and I thought she looked really nice. 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, I thought she looked nice, and I said, I think it was a Friday, why not tweet this and just share it.
I invented the hashtag spur of the moment. It was just cool to see a lot of my colleagues just chime in with their own dogs. It was actually really touching to see that among all the current dogs, there were memories of dogs that passed, that had unfortunately passed on. It was just really super neat to do.
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 scene. I think that’s important to remember about a lot of these technology. It's not just bits and bytes, it's about the organic life form, I guess, the right way to put it.
On the #drinksofAWS, that was the most hilarious hashtag ever. I think the lesson from that is sometimes the things you do incidentally, or spur of the moment, or guided by an intuition that is so deep, you didn’t even know it was there, you do something that actually has this long term interesting value.
I think that that ability to take either a feature or a challenge or an out problem with AWS and to summarize that very succinctly and to come up with a memorable name for it. I think there was considerable value there. I will tell you that those were shared extensively internally. People saw the humor in it, and they also saw the truth behind the humor.
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. It's fascinating to see the outside view. 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.
Corey: Yeah, I believe that was someone else, I don’t want to steal credit for things I didn’t do.
Jeff: But you started it.
Corey: Last question before I let you go. Re:Invent is on the horizon, are there any or from years past, as some of us like to call it, “Amazon’s complex killing 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, timing is always an interesting thing, and I'm not asking for anything in barcode. 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?
Jeff: I just checked this morning, there's a site I think it's called daysuntilreinvent.com and there are 140 days left which always sounds like a big number until you hit the panic button, then you realize, you should have actually panicked quite some time ago. We are thinking and acting a lot in terms of dealing with scale. Last year, we had 43,000 people at Re:Invent, 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 things, scaling principles that work for cloud architectures we’re now applying to the physical and communication challenges of Re:Invent. 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.
That’s really one way to run a network. We found a better way, we're going to put this into practice this year, they're going to be point to point routes. 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, instead of bus, 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.
Corey: It sounds like you're upgrading from token ring to full mesh.
Jeff: Yeah, that’s a good way to put it. We're 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 travelling 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 re:Invent inevitably sells out. We have some webinars that are called How to re:Invent. People should spend some time looking at the session catalog which I think will be published 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 per day.
Arrive with an open mind and ready to listen and learn, meet lots and lots of folks. I would ask people, if they see me, never 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. I absolutely love to meet people. It's very gratifying to meet people that have in some way benefited from the work that I've done. So please stop and say hello.
Corey: Lord knows there have been a lot of those people out there, I consider myself one of them. Jeff, thank you so much for taking the time out of your schedule to speak with me today.
Jeff: It's good to talk to you Corey.
Corey: Thank you again. I'm Corey Quinn, and this is Screaming in the Cloud.