When eWorld walked in for a chat with the CEO of a small company three years ago, the latter, during a casual conversation, proudly said he was saving more than Rs 50,000 a month after outsourcing his payroll processing. Asked who was doing it for him, he said, “Amazon”. Wait a minute. He couldn't be serious, could he? — Amazon was an online books (and music) vendor. Sure, but Amazon's S3 service was also helping this CEO store all his payroll information in servers on Amazon's cloud. So, his systems manager could focus on other work, his servers could be redeployed elsewhere and, not to mention, his savings on air-conditioning and accompanying costs!

The man responsible for Amazon Web Services, which give you computing and storage services on the cloud, among other things, is Andy Jassy, Senior Vice-President of Amazon Web Services and Amazon Infrastructure. With Amazon for 14 years, he wrote the business plan for Amazon's music business and AWS. To eWorld , he explains how AWS blossomed:

Between 2003, when you wrote the business plan for AWS, and 2006, when it was launched, what happened?

We had to hire people; we spent a good amount of time defining the products before we started building it. We have a philosophy at Amazon where we don't write a line of code until we fully define the product. We call it the working backwards process. We first think about what the customer wants and then move backwards from there. We define when it would be launched, what it would accomplish, what benefits accrue to the customer, what its features are… At the same time, we write an FAQ (a frequently asked questions document). Before we get down to writing the code, we have all the arguments and debates about what the product is, what features it should have and how we should go about building. Because, if you are clear about what you are trying to build, then once you get the engineering team working on it, they don't have to stop and rejig this or rip that out. It's much more efficient if you take time upfront to define it all clearly. We were lucky because we had a lot of internal development teams inside Amazon who were willing to use the product and were excited about it. We got a fair bit of production testing from the crews inside Amazon, who built Amazon applications, before we built the service.

If you were to go back further, to 2001-02, what triggered this business idea?

It did seem surprising to a lot of people, because there were a few things going on that didn't make it. We had been working on this business for nearly ten years without really realising it. To grow www.amazon.com, which at the end of the day is a massive Web-scale application, we had to run services deep in stack and we had to also run reliable and cost-effective data centres, since online retail demands this. We built a competence internally in running deep infrastructure services and data centres efficiently scalable in the first ten years of building Amazon.com.

Second, we were doing these deals we called ‘Merchant.com', in partnership with companies like Target, where we would provide all technology for their Web site. In delivering the solutions so quickly, we saw challenges emerging from pieces of the platform that got entangled. That created the shift mentally inside the company, of building in a service-oriented-architecture fashion. And we decided that from then on, all services would be built that way. That was a big shift in the way we thought about our services.

Third, around 2002-03, we were adding a lot of software development, the company was growing fast. And this was the time I was shadowing Jeff (as executive and technical assistant); we just couldn't understand why it was taking so long to get projects done. Jeff asked if I would do some investigation, and when I talked to product development leaders they said ‘I know you guys think this whole project end-to-end should take 2-3 months, but we are spending 2-3 months just on storage solutions, or hosting, or database solutions and none of what we are building scales beyond our project'. And I know Ron on the third floor is doing the same thing, and Bob on the fifth is doing same thing and it's frustrating because we all feel like we are reinventing the wheel and it is slowing us down. That was very interesting for us; it made us realise there was a thirst for reliable, scalable, cost-effective infrastructure services.

Finally, what we did with our data also helped. A part of our retail business is the affiliates program. We have about one million third-party Web sites that merchandise Amazon products. In addition to sales, they earn five per cent commission. And this team was trying all kinds of things to get more placements on those million Web sites. And one of the experiments they tried was — they took all the product data, name, price, customer reviews, etc and they exposed it in API. What we found was that the sites that used the API versus those that didn't saw 30 per cent better conversion rates. Surprisingly, we didn't promote the APIs, but thousands of developers still flocked to it. They started giving us a lot of feedback.

We believed that the operating system became the Internet, which was really different from what was going on at that time. None of the key products of the Internet OS had been built. Amazon has always been a technology company — one that applied it to the retail space. We realised we can contribute a lot of the key components of the Internet OS space. That kicked off this decision to pursue a broader business plan. On the face of it, you look at Amazon as a retailer and say “well, how on earth are they providing computer storage, database... if you think about the fact that we have been running infrastructure for ten years because of how fast we had to grow and then we had never exposed AWS to external parties, we would have (anyway) built all these services just to allow Amazon to run faster.

What kind of feedback did you get once you exposed the APIs?

People wanted us to expose more of our infrastructure, something that they could use for storage or giving them server space for computing, etc. People said things like, it would be great if almost every application has some messaging component, a notification component. Developers often spent a month building Notification themselves. Then came the demand for a database solution. It was really hard for them to maintain relational databases, they said, ‘maybe you can think of a database solution for us'. Amazon is a pretty strong technology company. And if we were having challenges solving these problems for our own use, we figured others were as well.

How did you decide on per-use pricing?

People don't like being charged a fix price, whether they use the resource or not. They only want to pay for what they consume. So, that was the underpinning concept behind our pricing model. Nobody really told us to charge that way, but that's what we interpreted the customer needs to be. Nobody really expressed that exact desire, but we heard people saying they didn't like that when they had a peak event they have to do provision for the peak and then sit on all that waste for a couple of years until, and if, they ever saw that peak again. So, that's what we do with all our services, we were lucky that we had primary and secondary customers' input for the product, but then we tried to interpret what the broader need was and then do some inventing on our customers' behalf.

Did business theory ever bother you? Did you consider barriers to entry from competition when you wanted to create AWS?

A new business at Amazon needs to have a few characteristics for us to get excited: The space has to be big enough; we have to believe that the space could be better served in a way that matters to customers; we should have some competence in that area we pursue; and, we have a differentiated approach. One of the things we have learnt in Amazon is that me-too approaches aren't very successful on the Internet. And so, in this space, this had all four of those characteristics. Also, I think that Speed is highly underrated in business. In the last five years at AWS, we have moved pretty fast. We believed that in time, almost all computing would move to the cloud.

Since 2006, you must have had a certain idea about how the market will play out. Has it, to your expectation?

Well, this is another aspect I have learnt a lot about in Amazon over 14 years. I have never seen a projection for a business or a new product at Amazon or elsewhere that is remotely accurate. It's so difficult to predict customer response to something new. At Amazon we look at the four characteristics I mentioned earlier, but we don't overemphasise what the market projection is going to be. I can now tell you that it has grown and accelerated a lot quicker than what any of us imagined. We obviously thought it was a very significant opportunity, or we would not have invested as aggressively as we have. But, I don't think any of us predicted it would have this broad an adoption across all segments — from startups to enterprises, to government entities — as quickly as it has!

Did the recession help you in any way?

It did. I think there are a lot of things that have driven it, moved it faster. (In addition to the recession), services have done well. If these had done poorly, I don't think people would have got excited about this cloud as a movement; two, so much has been written about it, so much media attention around it, it has really captured people's imagination and I don't think any of us predicted it would get this much public attention; I think the economy struggling the way it has over the last few years has accelerated enterprises trying to look at the cloud to be more efficient and to spend their resources in ways that differentiate their business instead of having to operate the infrastructure.

What is the response from emerging markets? We see a lot of news/media attention, but when it comes to adoption, what patterns do you see?

Very fast. I would say the movement, it probably grew the quickest in the US, the first couple of years that we had the services, some of it was self-prompted proxies; we didn't have a geographic footprint beyond the US for the first year and a half or so. Over the last few years, the adoption in emerging markets, particularly Asia, has grown very quickly; India is one of our largest markets, growing very quickly, same thing in Japan. And it's not surprising, if you think about it. Take India as an example, you know this market as well as anybody am sure, there is so much technology expertise here and so many engineers and so much technology development going on — both larger companies as well as start-ups, there is a vibrant Internet community here as well. If you have the opportunity to get access to storage compute database functionality, all the building blocks that we offer with no upfront commitment, no long-term commitment, low prices, it is very appealing. It is one of the things that has been most interesting to us and gratifying just how much it has levelled the playing field.

In the original business plan I wrote, one of the things we talked about was starting with a model that a college kid in his/her dorm room would be able to build with the same scale and same cost structure as the biggest enterprise structures in the world. And with AWS, that's the case. Somebody with an idea does not have to lay out all that capital for data centres and hardware, they get to pursue that idea, they can then lay out more plans, raise money later; and so, it has changed the amount and degree to which companies — both start-ups and enterprises — can innovate.

One interesting point when we talked to engineers at enterprises both at Amazon and external customers was, if you asked the simple question of how long does it take you to get a new server, the answers ranged from 6-20 weeks.

That is super-frustrating for engineers, and at some point if it takes that long to get a server, he'll just stop thinking about new things. Why bother? And you know, in AWS, you can spin up to hundreds or even thousands of servers in minutes. Any company that does a lot inventing will tell you that the two most important things are: being able to try out a lot of experiments; and, when the experiments fail (and most would fail when you are pushing the envelope), not having to live with collateral damage.

This is really changing the quantum of new development inside enterprises; new projects and things that teams believe are possible. A lot of times, you find that enterprises are using AWS more bottoms-up than top-down, so it is teams that have had ideas for years, that have been told ‘No' because they can't get resources, they can't get servers… are now finding it easy to find those very resources.

How do you plan for capacity, and has it changed over the years?

I would say that one of the less understood parts of our business is the scales we are at; it is a tremendous logistics challenge. Because, if you think about it, we are in five regions — we have the east coast US, west coast US, Singapore, Tokyo, and Europe. In our EC2, or computing services, alone, there are all kinds of instance types, they have different memory, CPU, network configurations, sizes, and so we have to forecast and then order hundreds of SKUs across many data centres, across many regions. It is not easy to do that, to make sure you don't run out of capacity, or over-order and sit on excess capacity. I wish I could tell you there was a silver bullet for it; it is just hard work and refining what we have been working on over time. We have a number of people working on forecasting demand.

When you ask about barriers for entry in this space, it is in the scale that there are a lot of barriers. To be able to operate across hundreds of thousands of customers in 190 countries at a scale like that is not easy to operate 24/7/365. And to handle the operations, the logistics and supply chain, capacity at that level is not easy. And to have a cost structure, we passionately believe that over time the prices for customers and our costs will go down. We have lowered our prices 12 times in four years, with no competitive pressure to do so. If you have the mindset of a high-volume, low-margin business provider, you are constantly thinking about how you take cost out of your own structure and give them back as lower prices to the customer.

Related Topics