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

91–100 of 187 posts

Re: The 2002 mandate for internal communication systems at Amazon

#91

Post by morelisp »

jrochkind1 wrote: post #74
akhilcacharya wrote: post #58

Earlier quoted context omitted.

I'm assuming Yegge was referring to the RPC framework.

"an internal communication system" does sound like something like an "RPC framework", but Yegge's paraphrase actually says "It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care." I read this as saying different teams/services don't have to use the same thing either. That doesn't sound like an "RPC framework" or "an internal communications system" at al…

In my experience with much smaller teams (5-50 programmers) the main challenges are three-fold:

1) getting developers to talk about formalizing (to any degree) cross-system responsibility at all rather than just hanging code where it's easiest at-hand;

2) getting developers to think about external inputs/outputs at all and everything that entails, e.g. namespacing, versioning, forwards and backwards compatibility, validation, access control, ...

3) teaching developers to pick the right kind of interface for their data and processing, i.e. more or less queue vs. pubsub vs. RPC vs. REST vs. query language; of the three this is the only "technical" one, the others will be harder sells.

Once you have done these, the question of _which_ queue/etc. you take is largely irrelevant; there will be some natural pressure to standardize and even "unnatural" pressure from CTOs/management will be straightforward to implement.

Re: The 2002 mandate for internal communication systems at Amazon

#92

Post by huherto »

lmm wrote: post #88
mav3rick wrote: post #72

Earlier quoted context omitted.

I have to ask. Isn't this just microservices ? Also isn't this terrible for latency and debugging ?

> Isn't this just microservices ? Yeah it is (though not so "micro-": it's really one service per team, which is the scale that actually makes sense IMO). This is kind of a "seinfeld is unfunny" case: this memo was in 2002, and predated (arguably helped create) most of the modern microservice approach. > Also isn't this terrible for latency and debugging ? When two codebases are owned by different teams (and potentia…

Agree. The "Micro" prefix is very miss leading. It should be one per (pizza) team. Otherwise you end up with too many, and it becomes a mess.

Re: The 2002 mandate for internal communication systems at Amazon

#94

Post by astura »

Waterluvian wrote: post #4

> 6) Anyone who doesn’t do this will be fired. So I've never worked at a company over 150 people. Is this... a normal thing for an email? Maybe I'm just one of those softies but an email with that line would throw me off my day and cause a serious hit to my morale and confidence of working there.

I've worked at ~250 person company, a multinational conglomerate you've definitely heard of, and everything in between.

No, that sort of overly forceful yet flippant language it's not normal.

Re: The 2002 mandate for internal communication systems at Amazon

#95

Post by seph-reed »

BenoitEssiambre wrote: post #65
Waterluvian wrote: post #4

> 6) Anyone who doesn’t do this will be fired. So I've never worked at a company over 150 people. Is this... a normal thing for an email? Maybe I'm just one of those softies but an email with that line would throw me off my day and cause a serious hit to my morale and confidence of working there.

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…

Heh. Threatening the managers. I love it.

Re: The 2002 mandate for internal communication systems at Amazon

#96

Post by morelisp »

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.

Re: The 2002 mandate for internal communication systems at Amazon

#97

Post by jrd259 »

wayoutthere wrote: post #32
inimino wrote: post #6

Earlier quoted context omitted.

This is Yegge's over-the-top style of humor, none of these are actual quotes from the email.

To be fair, "do this or you're fired" is just assumed of every request at Amazon, because they follow through on it often.

In my five-year experience at Amazon that has never been true.

Re: The 2002 mandate for internal communication systems at Amazon

#98

Post by morelisp »

akhilcacharya wrote: post #34
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…

Was Amazon the first major company to invest fully in SOA for internal use like this?

The critical decision here is not SOA for internal use, but SOA designed for external use, for internal use. This is still uncommon.

Re: The 2002 mandate for internal communication systems at Amazon

#99

Post by jrd259 »

rb808 wrote: post #78
sputknick wrote: post #13

I worked at an organization that had a similar declaration. Here's how it played out: 1. Everyone is super excited for other teams to share their data 2. Everyone wants an exception from sharing their own data because it's too hard or too sensitive to share. 3. Eventually everything gets shared, but it takes 3-4 times longer than it really should.

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.

Re: The 2002 mandate for internal communication systems at Amazon

#100

Post by kokey »

BenoitEssiambre wrote: post #65
Waterluvian wrote: post #4

> 6) Anyone who doesn’t do this will be fired. So I've never worked at a company over 150 people. Is this... a normal thing for an email? Maybe I'm just one of those softies but an email with that line would throw me off my day and cause a serious hit to my morale and confidence of working there.

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 different directions and he then has to also manage the priorities and communication around this too, and then he becomes a bottleneck for the entire organisation.
Post reply on HN