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

The “API Mandate” memo at Amazon

chrislaing.net

Post reply on HN
Print view View original

31–40 of 136 posts

Re: The “API Mandate” memo at Amazon

#31

Post by pushrax »

macintux wrote: post #26

I wish GitHub under Microsoft followed this philosophy. So much of their repository management can be done through their APIs, but you hit some painful brick walls around things like enterprise security where you could really use centralized management. My business area uses around 200 repositories. APIs aren’t really optional at that scale.

There are multiple large Rails services (I'd guess GitHub included) that internally have a majority of contributors in favor of an API first approach, but it's not mandated absolutely.

Shopify has a component boundary interface in Ruby that can be reflected into with GraphQL, and a lot of features are built for GraphQL first anyway. First party client side apps demand it. A lot of internal services use GraphQL to talk server-server as well.

However, there's still a good chunk of monolithic logic left that hasn't been refactored yet. Refactoring efforts are mostly JIT when demanded.

Re: The “API Mandate” memo at Amazon

#32

Post by markwkw »

It's interesting and often missed that this strategy implies a view of human collaboration and organization. Note that the memo says: 'All teams... Teams must... ...another team’s data store...'. It seems that someone figured out that a (5-10 person?) team is the right human collective size to design and build useful stuff, but that collective shall expose what they build to other teams via APIs. It's fine for the team to do things in a tightly coupled way - internally! In a way, tight collaboration between teammates can be reflected in tight coupling of internal components of whatever they build. But across teams the coupling shall be more formal and via APIs, reflecting looser and less powerful collaboration possible across teams.

Re: The “API Mandate” memo at Amazon

#33

Post by smcameron »

mmahemoff wrote: post #5

Always worth reading Yegge's insider take on this - https://gist.github.com/chitchcock/1281611 . The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything." You can't just bolt it on later. Certainly not easily at any rate -- ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it'll be t…

I kind of remember reading this shortly after joining Google in 2015 (have since left), and thinking yeah he's got a point, esp. regarding point 1: "All teams will henceforth expose their data and functionality through service interfaces." and point 5: "All service interfaces, without exception, must be designed from the ground up to be externalizable."

It's like, if we hit upon something useful, it better be available as a network service with a well defined interface from the start. And I do remember looking around at how things were, and thinking, yeah, Google could definitely use some of that philosophy (without, all these years later being able to cite any specific examples). It definitely felt like it hit home at the time.

Re: The “API Mandate” memo at Amazon

#34

Post by 8note »

nn3 wrote: post #9

So Amazon has no teams that write simple libraries for other teams? I imagine now that somewhere in amazon there is a "qsort" REST API that does all the sorting.

There's some frameworks, but libraries are generally under a "community support" model where if you're using the library, you fix the bugs you find.

If you want a team supporting that qsort function,you want it behind a rest api

Re: The “API Mandate” memo at Amazon

#35

Post by adolph »

markwkw wrote: post #32

It's interesting and often missed that this strategy implies a view of human collaboration and organization. Note that the memo says: 'All teams... Teams must... ...another team’s data store...'. It seems that someone figured out that a (5-10 person?) team is the right human collective size to design and build useful stuff, but that collective shall expose what they build to other teams via APIs. It's fine for the te…

That someone would be Bezos and his pizza person.

in time, two-pizza teams evolved into single-threaded leader (STL) teams, a term borrowed from computer science that means to only work on one thing at a time

https://www.inc.com/jeff-haden/when-jeff-bezoss-two-pizza-te...

Re: The “API Mandate” memo at Amazon

#36

Post by adolph »

meowface wrote: post #29
bogwog wrote: post #25

If every part of Amazon is really like that, then it'll make the task of breaking them up much easier!

That's actually quite possibly true, if they were indeed broken up. But a hypothetical breakup might also forbid certain (or any) kinds of collaboration between any of them, which might include calling each other's APIs.

Otherwise: Later versions of the Hydra story add a regeneration feature to the monster: for every head chopped off, the Hydra would regrow two heads.

https://en.wikipedia.org/wiki/Lernaean_Hydra

Re: The “API Mandate” memo at Amazon

#37

Post by not2b »

meowface wrote: post #29
bogwog wrote: post #25

If every part of Amazon is really like that, then it'll make the task of breaking them up much easier!

That's actually quite possibly true, if they were indeed broken up. But a hypothetical breakup might also forbid certain (or any) kinds of collaboration between any of them, which might include calling each other's APIs.

It would mean that if two split off pieces of Amazon want to call each others' APIs, other companies could also do so under the same terms (if there is a charge, everyone pays the same rate). This could work.

Re: The “API Mandate” memo at Amazon

#38

Post by CameronNemo »

leishman wrote: post #30

> All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. I wonder how this is accomplished for event driven architectures built on shared event buses.

In that case, the bus, producers, and consumers would all be treated as separate services, no?

The memo does mention pub sub, FWIW.

Re: The “API Mandate” memo at Amazon

#39

Post by fake-name »

leishman wrote: post #30

> All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. I wonder how this is accomplished for event driven architectures built on shared event buses.

Presumably, you expose the ability to inject events onto the bus, and the ability to listen for events on the bus?

Re: The “API Mandate” memo at Amazon

#40

Post by mcintyre1994 »

I wonder how an example from the article like the API to post new listings to Amazon works in practice with the requirement to be designed to be open to outside developers. It seems like that’d force some sort of review process (and I’m not really sure who can review all new listings) between API call and public availability that might not be there if you eg. had a private API for approved employees.
Post reply on HN