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
"Developers are like artists" is exactly what these primadonnas needed to hear. No, developers are nothing like artists. Creating something that didn't exist before doesn't make you an artist. Builders create something new every day. Developers are more like inventors if you give them a free hand in what they develop, but most of the time developers are very much like builders: They create what you ask them to create.
Or maybe I got you wrong and you meant that developers are like artists: Poor, starving, living for their work and only valued once they are no longer available.
...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!
Yes.
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?
This interview, while I'm sure sincere on the part of the CTO, comes across as a recruiting pitch. Obvious fallacies:
"Developers themselves know best which tools make them most productive and which tools are right for the job."
This sort of development mishmash depends on the developers never leaving (which most do after 2-3 years). Maintenance is, at best, nightmarish and leads to a patchy (with apologies to Apache) mess. FWIW, most developers seem to jump into coding right away with no thought for architecture or design.
"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."
Hmm, so the developers manage themselves. What a great job being a manager must be there.
"Developers are like artists; they produce their best work if they have the freedom to do so"
In my experience, most developers are nothing like artists and more closely resemble petulant, undisciplined children. Often they ignore the most basic principles of good software development (like version control, automated build and test suites, documentation, etc.) because "those are boring".
"I think part of the chaotic nature--the emerging nature--of Amazon's platform is that there are many tools available"
Wow, CTO speak at its finest to explain the disorganized nature of the organization.
"As a result of this principle, we have many support tools that are of a self-help nature."
See my point above about documentation being boring.
Comments I've heard from people who work at Amazon:
Your mileage may vary.....
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.