Slashdot Mirror
The Amazon Technology Platform
Don420 writes "Jim Gray has an interview with Amazon CTO Werner Vogels for ACM Queue. It is filled with a lot of details about the Amazon architecture that we have not seen before: 'If you hit the Amazon.com gateway page, the application calls more than 100 services to collect data and construct the page for you.' But also quite a strong statements about developing software at Amazon: 'Developers of our services can use any tools they see fit to build their services. [...] Whatever tools are necessary, we provide them, and then get the hell out of the way of the developers so that they can do their jobs. [...] Developers are like artists; they produce their best work if they have the freedom to do so, but they need good tools.'"
I wonder if the actual developers/coders see it that way themselves. Sadly, CxO's often have a warped view of how things work "on the floor".
Black holes are where God divided by zero
...but at the end of the day it's the developer's talent and experience that tell most of the picture. It sounds like Amazon do let their developers decide (to a large extent) how their products are going to work.
The transition from the monolithic Obidos to the current SOA makes me wonder how exactly that part of the system works. Though it's not (that I could see) explictly stated, it certainly seems that adding scalability was a long and painful process. Planning for future developments like this is something that developers tend to be much better at than managers - so I wonder whether the developers didn't think about including scalability hooks in their initial efforts, whether they decided (back in the early days) that it wasn't worth it, or whether they wanted to but were told not to bother.
All said, I do applaud the public stance that Vogels is taking in his attitude. If more CxOs shared it, we'd likely have beeter-designed systems all over the shop. You hire the developer because (s)he's good at developing - so let them go to it!
My, that was a yummy potato!
Developers of our services can use any tools they see fit to build their services.
I wonder how they avoid the maintenance nightmare which is having multiple application components done using various obscure technologies/tools and the person that did it leaving the company and somebody else having to maintain/extend those application components?
Do they standardize their build tools, require good documentation on the service implementations or just overwork the poor sods that have to do maintenance to death?
I worked at amazon for two years. I never saw any use of Haskel, SML or any other functional language. 90% of all work at amazon is some combination of C++ and Perl, with a few groups trying to transition to Java.
Wow, troll much? Working at Amazon currently, I'll comment on a few of these things:
1. Low pay - it's a great place for budding "artists" fresh out of school to build "experience" that has to be unlearned at a more organized shop.
Not at all. I'm making 15% more here than I did at HP last year. I make more than devs with equal experience at MS. The pay is pretty good.
2. Dot-Com mentality - Lots of excuses for your desk being a door on two filing cabinets as well as the lack of organization.
THe door desk is aq culture thing. THere's a whole story behind it. Think of it like a tradition a sports team has. In the end, it works well- its not pretty, but its sturdy and does its job.
3. Turnover rate - as soon as people get experience, they leave for better paying jobs; Amazon is *always* hiring.
Amazon is also growing- we have more developers than the year before. Yeah, there's turnover. Welcome to the IT industry- its rare for anyone to work at 1 place for more than 3-4 years. A lot of it is people staying just long enough to vest their stock grant (thats right, our sign on bonus is a grant, not an option) and then leave for another bonus elsewhere. Moneywise its the smart thing to do at any company.
I still have more fans than freaks. WTF is wrong with you people?