How Amazon Web Services Reinvented the Internet and Disrupted the Economy

Amazon Web Services has become the leading provider of cloud services in the world. It's leaders' realized that there were services which businesses and consumers might purchase from a third party and, that despite concerns about Amazon's power, they would be willing to buy from Amazon because of its reputation for competence. This has exponentially extended the power of the internet and those who use it.  . 

As a model for innovation, the concept was not a sudden stroke of genius or a calculated strategic initiative. Rather, it was based on iterative experiences which generated questions about what could be done better at scale, for an acceptable price. JL 

Jake Swearingen reports in New York Magazine:

'None of the key components of the internet operating system had been built, and when we thought about what we were good at, we realized we could build all of those missing key components for that internet operating system. Could (there) be a business in building a technology infrastructure platform that would allow any company to build out their applications on top of it? If successful, can it be big? Do we have a differentiated approach? Is it being well-served today? The major debate was: “why don’t we build a storage service, and see if anybody will use this from Amazon?'

Amazon Web Services (AWS) is a web platform that powers everything from Netflix to Slack to NASA. Launched in 2006, AWS is a suite of storage, database, and other services that allows anyone to build an internet application without ever purchasing physical hardware. (If you’ve ever heard about “cloud computing,” Amazon Web Services was one of its pioneers.) AWS has also turned into a cash machine for Amazon, generating billions in pure profit. AWS CEO Andy Jassy talked to Intelligencer about the early days of AWS, the debates and fears within Amazon about whether anyone would pay to use it, and why you should never be afraid of asking a dumb question.

We started to consider what became Amazon Web Services between 2000 and 2003. We were adding a lot of software development engineers, and yet software projects were taking just as much time as they had been before. Development teams had been telling the leadership that if they had more people they could deliver so much more quickly, but we weren’t seeing that actually play out.

I was working for Jeff Bezos as his chief of staff, and I went and talked to product development leaders. They’d say, “Look, you guys think these projects should take two to three months total, but we’re spending two to three months just on the storage solution or the database solution or the computing solution.” They felt like they were reinventing the wheel with every project. That was an interesting realization for us at Amazon; there was this real thirst internally for reliable, scalable, cost-effective infrastructure services. Even if we had never built AWS as a business for third-parties to use, we would have built all of those services to enable our own business to move more quickly.

In the summer of 2003, there was an off-site meeting at Jeff Bezos’s house. We were doing this exercise, looking at what we thought our core competencies were as a company. We started off with fairly obvious things, like we were good at having a lot of selection in retail, and we were good at fulfilling that selection.

But when we looked into it more deeply, we realized that in building Amazon’s consumer business as fast as we had in the first eight years, we’d gotten really good at operating infrastructure services, things like computing and storage and database. And because our retail business was a very low-margin business, we had to get really good at running reliable, scalable, and cost-effective data centers, and then run them at the right scale and at the right price.

During this exercise, we had a couple of columns up on a whiteboard. The first column listed all the businesses we were building for consumers. And in the second column were sellers — we were looking at how we were letting sellers offer their products on Amazon or providing e-commerce technology. But as we thought about the confidence we had in the infrastructure side, we added a third column: developers and enterprises.

We asked ourselves: If you believe that companies would build applications from scratch using infrastructure services, then wouldn’t the operating system become the internet? And if you believe there might be an internet operating system, what would the key components of that be?

When we looked at that in the summer of 2003, we realized that none of the key components of that internet operating system had been built, and when we thought about what we were good at, we realized we could build all of those missing key components for that internet operating system. So we decided to explore whether or not there could be a business in building a technology infrastructure platform that would allow any company, including ours, to build out their technology applications on top of it.

The major debate that we had was, some of us said: “This is so different from the rest of our business, why don’t we just build something like a storage service, and see if anybody will use this capability from Amazon? If they do, we can think about building other services.” But the AWS team felt really strongly that we should either build a platform, or not build it at all. Virtually every application requires compute servers or storage or database or messaging or analytics, and we felt like, if we wanted to enable the end goal — letting developers build applications much more quickly than they had before — then providing just one component wouldn’t solve the problem. We also felt that if we waited to gauge response, then it would likely delay getting the right building-block infrastructure services to our customers by probably a couple of years.

This whole debate happened in this four-hour senior leadership meeting, where we had to review the proposal for AWS. The debate played out in that conversation, and at the end of the day there was enough of a consensus that if we were going to make a bet, we might as well bet big.

I will tell you that after we made the decision in that meeting to really pursue the platform, it took us two to three years to actually launch the first service. And there were lots of times afterward where we would question ourselves and say, “I don’t know. Will people buy storage from us? Will people buy compute from us? Will people buy database services from us? Or should we just focus on developing the e-commerce tech we know people will use?”

But we believed that if we wanted to have a chance at having the leading infrastructure technology platform in this new medium, we had to be first to market. People weren’t expecting that to come from Amazon. I think most people, if it was going to come, expected it to come from old-guard, longer established technology companies.

I was one of the few people who was always convinced that we should either build a platform or not build it at all. But I will say, there were many times in the first couple of years when I’d come home at night and my wife would ask me how my day was, and I’d say, “I feel like I’ve spent a lot of the day listening to really smart people question whether we should narrow the scope of our ambitions, and I spent a lot of the day saying we should go after the broader opportunity.” And she would say to me, “Are you sure it’s gonna work?” And I would say, “I have no idea. I really don’t know.”

I don’t think anyone can know when you are pursuing something that is really different, like AWS. What I did know from having started businesses before Amazon, as well as from my time at Amazon, was that when you are trying to do something new, it’s really a waste of energy to spend a lot of cycles wondering whether it’s going to be a success or not. We just tried, as much as we could, to stay focused on what we were building instead of wondering whether it would work.

We modeled what could happen with AWS every which way to Sunday. At Amazon, with new initiatives, we don’t look at something and say, “Okay, it needs to hit this certain metric.” Because it’s impossible to know whether somebody’s going to respond to something really new and innovative.

Instead, we ask the following questions of ourselves: If we’re successful, can it be big? Do we have a differentiated approach to the space? Is it being well-served today? And do we have some competencies that would allow us to be knowledgeable in this area?

If we like all the answers to those questions, then we assign a single team to work on it, one that’s not encumbered with having to run any other part of the business. Otherwise, if you encumber an already busy team with a new initiative, the new initiative will always lose out time-wise and priority-wise to the existing, sure-bet initiatives.

We liked all the answers to those questions. But we also modeled out what the exposure would be if we were completely wrong and nobody used AWS. We’d hired 57 people, and we had to put some capital down, and we would have considered that cost not well-served if we had gotten nothing out of it.

But we knew there was a lot of need for this. We knew internally at Amazon that this was a real problem for builders, and if we had this issue, it stood to reason that others did, too. So there was some idea here, and even if we didn’t get it right initially, we could probably iterate our way into finding something that was valuable.

At Amazon, we are very careful about what big strategic bets we place, but the ones we make, we keep iterating until we find something that we think has resonance with customers. So AWS wasn’t just going to be a test and if nobody used it early on, we’d be done. We always were convinced that something was there, and we were going to keep iterating on it for several years until we found something that people found useful.

We learned a lot of things from building AWS, and we are still learning more every month. One of the best lessons was just how important it is to have the right people and the right leaders. It’s one of those things that people always say, but when you see what it’s like when you don’t versus when you do, it just makes a gigantic difference.

On a related note, a lot of time you know early on when you don’t have the right people, but it almost always takes you a lot longer to make that change than it should. That’s human nature, because you care about people and you are hoping you can change them. But most of the time when you don’t quite have the right people, you often wait six or twelve months, sometimes longer, to make the change. And that change is right for the business and for everyone involved. Talented people want to be in the positions where they are best set up for success.

In the early days of AWS, I often felt like I would have questions or catch a whiff of something that didn’t seem quite right, but I’d be hesitant to say something out of the fear of asking dumb questions. Then, later in the process, we’d find that these were indeed problems, and I could have saved the team a lot of time. It was a good lesson for me to not worry about asking dumb questions. Sometimes teams are so close to what they are working on that having somebody that is not as close to it asking innocent questions — if there are obvious answers, they get answered in 30 seconds and you move on. But sometimes those questions can allow you to catch something that a group of people who are thinking alike and working together for many hours out of the week might not have thought of.