The “API Mandate” memo at Amazon • Hacker News Board

Re: The “API Mandate” memo at Amazon

#71

Post by jkepler » Mon, Jun 21, 2021, 8:31 AM UTC

yosamino wrote: post #53

xyzelement wrote: post #20

Earlier quoted context omitted.

It's really easy to be a nice guy by reacting the way you did, but if the quote above is real, it should be studied and celebrated. Let me break it down for you - Amazon bet the farm on this strategy and it worked out amazingly. Not following this strategy is equivalent to sabotaging the most important thing the company is doing. While I suspect this quote is tongue in cheek, it SHOULD be a fire able offense for some…

How did we end up in a place where we demand the system of government be democratic, with all the emotional language of freedom, self-determination and so on. And then we carved out an exception and made it so our places where we work are run as oppressive dictatorships... Dont agree with what the bossman said?: "You're fired!" And the people love it so much, they even democratically elected the poster child of that…

> How did we end up in a place where we demand the system of government be democratic, with all the emotional language of freedom, self-determination and so on. And then we carved out an exception and made it so our places where we work are run as oppressive dictatorships...

Private enterprise rests on property rights. Thus Bezos, as owner, was free to write that memo, including spelling out the consequences of sabotaging the company's strategy through insubordination or incompetence.

The only way this is dictatorial is if people are coerced to work there without a legal right to quit at any time. Their employment contracts given them that right (I assume) and they spell out the consequences of quitting without giving proper notice---which one could do. Thus, they're employees, not slaves in a dictatorship.

That's not to say that Amazon or other large corporations don't have problems with mistreating workers. In fact, thinking of businesses as machine systems may encourage a mindset among management that risks dehumanizing the people who do the work. And this problem is far broader than amazon.

However, dehumanizing workers isn't inherent in private property and owners' rights to run their firms as they see fit (within the constraint of law). Look at the Guinness company - privately owned, yet a pioneer in treating workers really well, and people have tasted the quality of their work round the world. Guinness believed people have inherent dignity (as a Christian he knew they were each made in God's image), so as a business owner he knew it was good for them and for his business to treat them well.[1]

Dehumanizing employees is often a result of misaligned incentives in the legal system, of unjust laws that don't fit with reality, or more fundamentally a result of the deep levels of brokenness that exist in every human being. No one is perfect, and no human system is flawless. The distortion of private property and resulting authoritarianism in business that you ask about is a sad result of what the Bible calls sin.

[1] https://www.amazon.com/Search-God-Guinness-Biography-Changed...

Re: The “API Mandate” memo at Amazon

#72

Post by raverbashing » Mon, Jun 21, 2021, 8:31 AM UTC

jayd16 wrote: post #54

>It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. So how does Amazon manage this btw? I don't find AWS SDKs to be all that consistent or inconsistent. They are usually good _enough_. Is that all it takes? By contrast, Google seems to spend a lot of time on their single repo, build the world, approach. For the most part it seems beloved, or at least people try to recr…

For real, if AWS internal APIs are as good as their outside-facing ones I fear the complexity.

Their APIs are... correct. But have things like usability as a last concern. You also find some things not behaving exactly as you would expect and some things that are barely explained.

Re: The “API Mandate” memo at Amazon

#73

Post by mxz3000 » Mon, Jun 21, 2021, 8:40 AM UTC

mcintyre1994 wrote: post #40

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.

In my experience, most APIs my teamed designed/built were not meant to ever be publicly available. That is, we never considered public availability as a design factor. So I think this rule doesn't actually apply anymore.

Then again, I don't know how public availability would change the API design really...

Re: The “API Mandate” memo at Amazon

#74

Post by nivertech » Mon, Jun 21, 2021, 9:03 AM UTC

mxz3000 wrote: post #73

mcintyre1994 wrote: post #40

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.

In my experience, most APIs my teamed designed/built were not meant to ever be publicly available. That is, we never considered public availability as a design factor. So I think this rule doesn't actually apply anymore. Then again, I don't know how public availability would change the API design really...

API design concerns for public availability (just to name a few):

  - security
  - preventing abuse
  - API Anti-Corruption Layer
    - sanitizing inputs and outputs
    - i.e. not exposing DB IDs/PKs, or pagination cursors directly
  - versioning, backward- and forward- compatibility, deprecation strategy
  - usability, DX, Documentation
  - reducing bandwidth use:
    - caching
    - eliminate over-fetching
    - efficient wire format

Re: The “API Mandate” memo at Amazon

#75

Post by kpmah » Mon, Jun 21, 2021, 9:03 AM UTC

I've worked at a place where this was cargo-culted and it worked horribly. All the worst aspects of 'services-first' design.

I think this works much better when each team is working on what could be regarded as a complete end-to-end product e.g. a database. It works poorly when each team is working on part of a product.

Re: The “API Mandate” memo at Amazon

#76

Post by ratww » Mon, Jun 21, 2021, 9:03 AM UTC

YetAnotherNick wrote: post #66

travisgriggs wrote: post #42

How far does this principle scale? I've heard of this strategy and thought "that's kinda cool." Amazon is obviously successful in its domain, so it would be easy to assume some causality. And yet, there's another big tech company, fruit symbol I think, that has played the long game of continually fine tuning the interaction points to make the integration of their parts more than the whole. They get credit for attenti…

Which thing exactly are you talking about apple which is not an API(except for esoteric thing like kext and all). All their programming model is based on API AFAIK.

Amazon's API mandate is clearly not just about having things "based on APIs", but rather about how teams collaborate and how tightly coupled they are. This goes way beyond "just having" APIs.

Re: The “API Mandate” memo at Amazon

#77

Post by augustl » Mon, Jun 21, 2021, 9:07 AM UTC

> no direct reads of another team’s data store

This reminds me of how App Store used to ban game emulators interpreting ROMs downloaded from the internet, while at the same time allowing XML parsing.

Does it really matter if the interface you're talking to over the network is code written by another team, or data written by another team? I suppose implementation details are often hidden away in data stores, but does it have to be that way?

Re: The “API Mandate” memo at Amazon

#78

Post by shaicoleman » Mon, Jun 21, 2021, 9:09 AM UTC

jayd16 wrote: post #54

>It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. So how does Amazon manage this btw? I don't find AWS SDKs to be all that consistent or inconsistent. They are usually good _enough_. Is that all it takes? By contrast, Google seems to spend a lot of time on their single repo, build the world, approach. For the most part it seems beloved, or at least people try to recr…

I don't work in Amazon, but from everything I've heard and read Amazon values autonomy more than consistency.

I think there's a saying there: "it's better to have two of something than none".

This can often result in inconsistency and duplication.

When that happens, a team would later be formed to unify things if needed.

Re: The “API Mandate” memo at Amazon

#79

Post by dragonwriter » Mon, Jun 21, 2021, 9:11 AM UTC

augustl wrote: post #77

> no direct reads of another team’s data store This reminds me of how App Store used to ban game emulators interpreting ROMs downloaded from the internet, while at the same time allowing XML parsing. Does it really matter if the interface you're talking to over the network is code written by another team, or data written by another team? I suppose implementation details are often hidden away in data stores, but does…

> Does it really matter if the interface you’re talking to over the network is code written by another team, or data written by another team?

Yes, because it means the depedencies between systems will consistently be API dependencies, not a mix of API and datastore structure dependencies, which means that the other team will only have to reduces the constraints on change.

Re: The “API Mandate” memo at Amazon

#80

Post by draw_down » Mon, Jun 21, 2021, 9:11 AM UTC

augustl wrote: post #77

> no direct reads of another team’s data store This reminds me of how App Store used to ban game emulators interpreting ROMs downloaded from the internet, while at the same time allowing XML parsing. Does it really matter if the interface you're talking to over the network is code written by another team, or data written by another team? I suppose implementation details are often hidden away in data stores, but does…

Well, it isn’t really like that at all I would say. The reason for the Amazon rule is to prevent unseen coupling between teams. Explicit boundaries are critical for this to scale.