1. Internal Jeff Bezos memo from around 2002 that everything should be a web service, which eventually can be externalize: http://apievangelist.com/2012/01/12/the-secret-to-amazons-su...
"Anyone who doesn’t do this will be fired. Thank you; have a nice day!"
2. AWS started in 2006 with EC2 (provision service through API) and S3 (some file storage). Simple, but primitive building blocks.
Google entered game early in 2008 with App Engine. Very powerful, but restricted Platform as a Service. It pretty much requires to rewrite whole application from scratch and doesn't let you do tons of stuff.
Eventually AWS is keep adding services with more functionality (SimpleDB, DynamoDB, SQS), while it took quite a while Google to realize that it needs to provide bare servers too. So both approaches converge, but Amazon capture magnitude more revenues from cloud infrastructure.
EC2 was, in some capacity, a tech borrowed from the Alexa (analytics) acquisition, which teams in Cape Town built upon.
SimpleDB (worked upon since 2005, and managed by people acquihired from Junglee.com), morphed into DynamoDB (started 2009-11) pretty immediately as they realised that it was going to be no where near enough.
Bezos personally pursued Werner Vogels to lead the web services initiative sometime in 2003. A lot of folks from the Retail Org, who solved problems of enormous complexities for Amazon.com, the website, got together to create AWS.
[0] Side note: Amazon's top hierarchy meets once every year and decides to invest in two new buinesses Amazon has never been involved in, or markets it can transform due to its involvement in multiple sectors... that's why there's so much happening at any given point in time at Amazon. It's really an incredible place if innovation is what drives you.
I also don't think that EC2 was borrowed from Alexa at all. There were political reasons why that development happened in Cape Town (it insulated them from Seattle politics and in particular from the VP who was over my head who hated the whole idea).
I think Alexa led to the Amazon search engine -- which i thought was called something like a6 (kind of like i18n is short for "internationalization" but with a6 being short for "amazon" -- but that doesn't quite sound right and I think I'm thinking of an Audi -- it was something like that though). They were in SF and setting up a satellite there to hire engineers away from Apple and Google. I also recall them doing some good work on SEO and fixing our URLs and such to get better search placement on Google which drove significant revenue. I don't think they had anything to do with EC2, but there could be some kernel behind the scenes that I wasn't aware of -- however it all smells wrong to me.
...
6)Anyone who doesn’t do this will be fired.
7)Thank you; have a nice day!
Ha, ha! You 150-odd ex-Amazon folks here will of course realize immediately that #7 was a little joke I threw in, because Bezos most definitely does not give a shit about your day.
#6, however, was quite real, so people went to work...
According to the original source, this is incorrect; Jeff Bezos never told people in this memo to have a nice day.
Empirical observations show that Google never managed to (or never tried to) make App Engine meet the general customers' needs for building their applications. Of cuz, that does not include Snapchat.
Is it because Google did not invest enough, or Google failed to educate and/or engage developers, or Google made a wrong assumption that App Engine would eventually catch up, there is no clear answer.
So overall, I do not think App Engine is 'powerful'. Sure, it has fancy feature and advanced designs. But that does not make something powerful. A powerful tool is one that help users do more with higher efficiency, or enable users to do things that otherwise is impossible or too costly. App Engine might be able to do that, but it was not proved to be true in general.
Actually SQS was the first service.
Such business philosophies require companies to unselfishly give up developed competitive advantages and provide that as a service to the entire industry. Imagine if this same philosophy was implemented at other companies: the past-time heavyweights would be serving a far higher calling today. And entire industries of innovations of would have picked up and developed on where the old left off.
Examples like Intel offering the capabilities of its foundries or Kodak offering its patents to filmmaking or Microsoft offering others to build on its Office Doc format would have prevented both their fall and promoted the industries to greater heights.
Such strategy could also work well for others - if Intel offers fab services but doesn't sell to pc/server competitors ?
Higher calling? It's a business dude, plain and simple.
Of course this depends on the type of startup you are building, a video startup is gonna be crazy expensive on AWS, Non-media heavy SAAS it may not matter.
Of course you can always build on AWS and place a caching layer in front of your bandwidth heavy media using DigitalOcean boxes to save big.
- 2x 1GB instances (one free, one $10/mo)
- Free ELB to load-balance between them
- Free 1GB Postgres RDS
Then I spend less than a buck or two a month when I spin up a c4.large for a few minutes to compile a new AMI periodically. This would all cost at least 3-4x on something like Linode or Digital Ocean.
I don't love any of the AWS APIs, but they got them out the door faster than anyone else (often by several years)...and they work. They can be clunky, but if you make the right incantations, you get the results you need and a limitless pool of resources, if you have the money.
But, more importantly, they've led rather than followed...because they knew what a service-based architecture needed to work, because they'd built one of the largest ones in the world before anybody else. So, as companies have grown on AWS, they've always found that Amazon had already thought of the growing pains they were going to run into and had already engineered solutions. So, Amazon is reading your mind, because they've been there and shared that particular pain. So, when you get to that crossroads, there's already an outpost with a note saying, "We went this way, here's a map and some supplies."
Yegge's rant on the subject is enlightening, but probably could have mostly been deduced from the outside without prior knowledge. Someone high up had to make the proclamation that Amazon would become SOA, at all costs, and someone had to make the call that it would be built to share, from the beginning. And, it's why so few companies have been able to catch up; only Google and Microsoft have come close, I think, and it's because they have tremendous resources, and some of the same internal forces at work.
http://www.forbes.com/sites/laurengensler/2016/05/27/global-...
(It might depend on metric used :-) )
Somehow this sums up many of the frustrations I've had working in software. I point out to people when they're making these kinds of decisions, and I call them on it when they romanticize it into an unhappy accident instead of a form of insidious, latent neglect.
I find it infinitely amusing when software developers become homeowners and complain about the exact same sorts of myopic shortcuts and idiotic decisions made by the former owners, without a hint of dissonance.
They put full descriptions of their products, very comprehensive, out on full display, including pricing.
Not only is pricing transparent, but it's not profit maximizing in the short run ... prices go down over time.
You can sign up with a credit card and get going.
Most companies, like Oracle - would have put this product behind a wall of idiot sales people and obfuscation.
I've been using AWS since the start and I've never needed support - not a bit.
This part of their operating paradigm should not be overlooked. It was a very gutsy decision to just throw everything over the fence and let 'whoever' use it.
We take this for granted now, but it could have been another way entirely.
Many other established companies still have not gotten the memo.
This can be really important. I've often had conversations that went something like:
"How much will this cost to run?"
"On AWS, $76US/month plus something under $5/month in bandwidth"
"How much if we run it no Telstra's cloud"
"No idea - the webste says 'call your account manager'".
"Have you called them?"
"No. I don't have a Telstra account manager. Let me know if you want to sort that out - or if we should just get it all running this morning on Amazon."
Layers and layers of business people in between the actual product, nobody really sure what's going on... many of them are on 'cost plus' programs so they are incented to drive up cost.
I worked for (then) Spar aerospace, making the Space Shuttle robot arm, paid for mostly by NASA and Canadian gov. We paid through the teeth for everything. And then collected 10% on top. It's a perverse system. That said, it keeps a lot of people employed.
Oracle spends much more $ on sales than they do R&D, about 1/2 of their operation costs are 'sales' - meaning, that guy sitting there telling you about how great Oracle products are? 1/2 of your purchase price goes towards paying his salary.
'Business people' and 'sales people' are important components of the process, but when there is massive institutional gestation around these projects, it gets unwieldy very quickly.
AWS is a move in the right direction and should help drive efficiencies in a lot of places.
It's a great company, but you need to understand the business and understand what Wall St expectations are.
They're not attempting to provide the definitive history, just some new info from Jassy
As other commenters and the article noted, when AWS was launched, it just provided simple, primitive building blocks like compute (EC2) and object storage (S3). At the time, AWS's value proposition was entirely around elasticity of infrastructure and its archenemy was data centers. In the process, they created a new market that came to be called Infrastructure as a Service.
Since then, AWS has gone up the stack steadily, adding infrastructure application services like RDS, ELB, etc. These infrastructure applications have made it easier and faster to deploy applications on AWS, but unlike pure infrastructure, they come with a degree of vendor lock-in. But developers didn't blink at all because it was so much more convenient than upgrading your own MySQL or setting up an HAProxy.
And now, AWS is squarely in the applications business. Last year, they announced Quicksight, signaling to the world that they are going to squeeze out business intelligence vendors. Few know that Amazon has Microsoft Outlook/Gmail for Work competitor called WorkMail. Slowly but surely, AWS is trying to swallow the entire enterprise software stack. I noticed that most people no longer describe AWS as "IaaS" but as "cloud infrastructure." I.e., their scope and market is expanding.
Key to this success is their strategic prescience and marketing execution, both for the developers and the suits. They knew what made developers happy (free/cheap to start, great API and documentation, scales well) and took the time to build solid infrastructure. For the suits, they created a clear vision of "old v. new" and used customers like Netflix to convey how the new world is going to run on AWS.
As a keen observer and practitioner of enterprise software marketing, AWS's rise to dominance is a textbook example.
I think most big tech companies know "what made developers happy". Microsoft did, Oracle did, Google did. The difference is that Amazon decided that they want to shared with the developers their secrets, and apparently many other companies do not think in that way.
Have a look at the AWS page from 2005, pre-S3:
https://web.archive.org/web/20050504101424/http://www.amazon...
I'm one of the few crazy people trying to do it.
http://www.theymadethat.com/things/dd846efa-9679-4c16-ad96-6...
Feel free to join me =)
(Constructive criticism is also welcome)
Tap on "read full article" - NOPE, you just clicked on an ad instead.
('cause it relayouts at some point after the page loads and right around the time you want to tap on that)
The book…helped to crystallize the debate over the problems with the company’s own infrastructure. If Amazon wanted to stimulate creativity among its developers, it shouldn’t try to guess what kind of services they might want; such guesses would be based on patterns of the past. Instead, it should be creating primitives — the building blocks of computing — and then getting out of the way. In other words, it needed to break its infrastructure down into the smallest, simplest atomic components and allow developers to freely access them with as much flexibility as possible.
