Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The 2002 mandate for internal communication systems at Amazon

sametab.com

Post reply on HN
Print view View original

101–110 of 187 posts

Re: The 2002 mandate for internal communication systems at Amazon

#101

Post by wil421 »

jrd259 wrote: post #99
rb808 wrote: post #78

Earlier quoted context omitted.

4. A couple of years later you want to stop an obsolete interface but you can't because a handful of systems use it and they dont have budget to change.

True this happens, but you're still better off that if you had tight coupling. In the absolute worst case you can make a shim implementation to support the obsolete use case. You can not do this when callers are directly reading your database/memory structure.

Yep, I’ve implemented new ticketing systems that have to talk to the ancient ticket system for certain things or vice versa. The ancient system had direct DB connections that had too many down/upstream dependencies and not enough budget or political backing.

Re: The 2002 mandate for internal communication systems at Amazon

#102

Post by function_seven »

morelisp wrote: post #96
ineedasername wrote: post #85

The article mentions this as dog fooding, but does that really apply here? Did they do this with the idea in mind that they'd turn this stuff into a product? It struck me as Bezos wanting things built for the future, reducing technical debt, and the product-ification was an excellent byproduct, but perhaps not intentional.

At the time Amazon was building out their merchant portal as a white-label-ish service for other large retailers to sell products online. The 'customers' in the memo would be other merchants, and the early AWS offering (e.g. SQS) reflect this. "Elastic" clouds weren't really on the menu yet but obviously part of the point is that you can offer it to customers regardless of where the architectural fad goes.

I remember the early days of target.com and (I think?) toysrus.com being thinly skinned versions of Amazon.

Re: The 2002 mandate for internal communication systems at Amazon

#103

Post by drclau »

blub wrote: post #64
solarengineer wrote: post #45

Earlier quoted context omitted.

An ex Netflix person, who has since moved to Amazon, spoke at a client place three weeks ago. He casually mentioned things such as "we forgive the first time, and we fire the second time". From how he spoke, we felt that this may be the norm in Silicon Valley and related places. I have much respect for what he has achieved, so I didn't interrupt to question such a fear-inducing mindset.

I remember reading that their head of HR was very supportive of this firing policy and she was herself fired: https://www.fastcompany.com/3056662/she-created-netflixs-cul... :)

Thanks for sharing this article.

The part about McCord firing an employee is sad and funny at the same time. To begin with, it looks like a page from Vonnegut’s Player Piano:

“McCord mentioned letting go a product testing employee who “was great,” but eventually lost her job to automation.”

It isn’t mentioned if the employee contributed to the automation that eventually replaced her, but it may as well be so.

Nevertheless, her depiction of the conversation is a rare mix of sad and funny:

“So I called her up. I’m like, what part of this is a surprise? … And she goes, yeah, but, you know, I’ve worked really hard; this is really unfair. I’m like, and you’re crying? She’s like, yeah. I’m like, will you dry your tears and hold your head up and go be from Netflix? You’re the–why do you think you’re the last one here–’cause you’re the best. You’re incredibly good at what you do. We just don’t need you to do it anymore.”

Re: The 2002 mandate for internal communication systems at Amazon

#104

Post by lifeisstillgood »

ozgune wrote: post #86
Twirrim wrote: post #2

Yegge's post was very interesting reading, and I took similar learnings away from it. I was at Amazon at the time, however, and there were things that certainly weren't true any more: >3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service inte…

(Former Amazonian, part of the team that drove the change to SOA at the time) > Now I think that this internal email is what has actually stuck with me the most. Bezos realized that he had to change the internal communication infrastructure [..]. > He understood that a radical organizational change was required to arrange the internal dynamics in a way that would allow the creation of something like AWS. This is quit…

>> making informed bets on market fundamentals and enabling teams to deliver on them.

Given the recent 20,000 startup ideas post, this is the perfect algorithm to cut through the noise

Re: The 2002 mandate for internal communication systems at Amazon

#105

Post by BenoitEssiambre »

kokey wrote: post #100
BenoitEssiambre wrote: post #65

Earlier quoted context omitted.

Elon Musk did this fairly recently at Tesla: "There are two schools of thought about how information should flow within companies. By far the most common way is chain of command, which means that you always flow communication through your manager. The problem with this approach is that, while it serves to enhance the power of the manager, it fails to serve the company. Instead of a problem getting solved quickly, whe…

Information doesn't have to flow through managers specifically and it certainly doesn't have to flow up the management chain and down again, but there ideally should be preferred funnels for the communication and breaking out of it should be an exception, or pre arranged, and not the norm. Otherwise you'll have, say, a particularly useful person on a team see his time filled with requests coming from a lot of differe…

If you have smart employees respectful of other's time it shouldn't be a problem. I would tend to agree with Musk on this one. Processes are often put in place to counteract poor hiring. If you need inefficiency raising processes to defend your business from your own employees, maybe you don't have the right employees.

Re: The 2002 mandate for internal communication systems at Amazon

#106

Post by throwaway122kk »

thaeli wrote: post #10
leoh wrote: post #5

Earlier quoted context omitted.

How do services talk to each other without an API? Is it something like "put a non-well-documented object into a queue?"

Some methods I've commonly seen in Enterprise Duct Tape: Screen scrape the other service and do data exchange via a Selenium script. Directly interact with the other service's database. CSV files and nightly batch jobs.

I raise you a service which gets it's configuration from a table on confluence page

Re: The 2002 mandate for internal communication systems at Amazon

#107

Post by gowld »

xyzzyz wrote: post #40

> While the third point makes all the difference in the world, what Amazon really did get right that Google didn’t was an internal communication system designed to make all the rest possible. > Having teams acting like individual APIs and interacting with one another through interfaces over the network was the catalyst of a series of consequent actions that eventually made possible the realization of AWS in a way tha…

A protocol buffer is a serialized data object, not a service API. It doesn't (and didn't) prevent anyone from using shared memory, shared database, or shared flat files to communicate.

Also, 2002 is time immemorial. Google was founded in 1998.Protocol buffers were invented in 2001.

Re: The 2002 mandate for internal communication systems at Amazon

#108

Post by gowld »

kylek wrote: post #41
cm2012 wrote: post #7

I love some of Amazon's executive policies. From what I've read, everyone has to write a multi-page paper before executive meetings, and everyone has to read it, so the meeting goes smoothly with everyone understanding the issues. I hate how no one reads anything in most organizations.

Not sure about execs, but this happens in engineering meetings (regarding new features being implemented or other semi-major changes). Whoever is initiating the meeting writes up a paper describing the terminology, the nature of the change and why it's needed, how it will be implemented etc. The entire dev team (+ maybe other dev teams within the group), management (the initiator's boss + 1 level above, maybe other d…

It happens with Jeff, which is why it happens with the execs, which is why it happens with the eng teams.

It doesn't happen at many other companies, even ones stocked to the gills with Amazon refugees.

Yegge has another famous blog post about presenting to Jeff.

Re: The 2002 mandate for internal communication systems at Amazon

#109

Post by gowld »

function_seven wrote: post #102
morelisp wrote: post #96

Earlier quoted context omitted.

At the time Amazon was building out their merchant portal as a white-label-ish service for other large retailers to sell products online. The 'customers' in the memo would be other merchants, and the early AWS offering (e.g. SQS) reflect this. "Elastic" clouds weren't really on the menu yet but obviously part of the point is that you can offer it to customers regardless of where the architectural fad goes.

I remember the early days of target.com and (I think?) toysrus.com being thinly skinned versions of Amazon.

Yep. Also one of the large British retailers and a few others.

Re: The 2002 mandate for internal communication systems at Amazon

#110

Post by jhallenworld »

leoh wrote: post #5
Twirrim wrote: post #2

Yegge's post was very interesting reading, and I took similar learnings away from it. I was at Amazon at the time, however, and there were things that certainly weren't true any more: >3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service inte…

How do services talk to each other without an API? Is it something like "put a non-well-documented object into a queue?"

IBM has an appliance for you:

https://www.ibm.com/products/datapower-gateway

It's a middleware appliance that allows any API to talk to any other API and handles just about any data format. You can script it with javascript or XSLT. It can handle ad-hoc things like ftp polling.

It has the added benefit that you can add security for outside facing clients.

Disclaimer: I helped develop this appliance (but I no longer work for IBM)

Post reply on HN