Does Amazon has some standards/conventions for inter-team APIs, i.e. something like Google's AIPs (API Improvement Proposals) [1,2]?
The “API Mandate” memo at Amazon
61–70 of 136 posts
Re: The “API Mandate” memo at Amazon
#62Always 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…
> But making something a platform is not going to make you an instant success. A platform needs a killer app. Which is a big ask, since > The problem is that we are trying to predict what people want and deliver it for them. You can't do that.
Pretty much the hardest part about SaaS as a business, described in just two sentences.
Re: The “API Mandate” memo at Amazon
#63>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 feel like Google's approach is more popularized
I mean, the engineering architecture being described in this memo is, basically, microservices. That's certainly an extremely popular -- I would go so far as to say even vogue -- pattern for solving the problem of building software at scale.
Re: The “API Mandate” memo at Amazon
#64Does anyone know who else was involved in constructing this memo? "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" Was Bezos deeply enough involved in Amazon's engineering to set those rules himself, or was the text of the memo influenced by a senior engineering group that he was worki…
My favorite is the control theory anecdote (point 2 here: https://gigaom.com/2013/10/10/5-fun-and-terrifying-facts-abo... ). Some people are just able to grasp the core of a large number of topics really fast, and born-in-1964-Jeffrey seems to be one of them. It’s fairly clear he would be very well versed at various tech architectural designs even if he didn’t have a CS background, I’ve worked with several people (os…
> It’s fairly clear he would be very well versed at various tech architectural designs even if he didn’t have a CS background
He does have a CS background.
Re: The “API Mandate” memo at Amazon
#65Does Amazon has some standards/conventions for inter-team APIs, i.e. something like Google's AIPs (API Improvement Proposals) [1,2]? [1] https://google.aip.dev/general [2] https://google.aip.dev/
There’s an API bar raiser system for APIs called by many teams.
Re: The “API Mandate” memo at Amazon
#66How 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.
Re: The “API Mandate” memo at Amazon
#67How 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…
Amazon has created lot of these "things" (for the lack of a better word) that should be taken with a sack of salt. Door Desk, 2-Pizza Teams, Press Release and Frequently Asked Questions (PRFAQ), API Mandate, AWS as utilizing spare capacity, just to name a few. It's made out to be as if these are religiously practiced at Amazon but that's definitely not the case.
I worked at one of the first remote dev centres of Amazon working on an extremely ambitious AWS service. The mandate was imposed with a hammer in the earlier days, to an extent even the code repository was segregated. We couldn't access any internal service, no tools (such as pager-duty). So we ended up building half-ass version of everything ourselves. People at the HQ built a web-service to access customer information but within a few months it languished with no one to maintain. Half the time we would be blocked for someone to give us access to a service. Whenever we raised an issue the answer from HQ was oh yeah use this and this service, they were oblivious to our limitation. We would then play the broken record and they would then go oh, well let's see what we can do. Eventually someone higher up noticed the massive inefficiency and said fuck it and opened up all the access for us. But then everything had to be migrated from half-ass services to the mainstream ones.
During my time there I never heard of this API mandate. Now that AWS has gotten massively successful this API mandate gets paraded as if it was all a grand plan. No, it wasn't. It was an experiment that sometimes worked and sometimes didn't.
Also there's this troupe about AWS you keep hearing. The story goes that someone realised all the un-utilized server capacity and decided to rent it out. That's absolutely not how it began. That's a typical Amazon marketing speak. Amazon's retail took a very very long time to migrate to AWS. In fact I'm not sure if they are fully on AWS either.
Re: The “API Mandate” memo at Amazon
#68Earlier 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…
You have it upside down. Everything else is authoritarian, except for (some) governments, because governments truly have the power of life or death over you.
But everything else? Highly undemocratic.
Re: The “API Mandate” memo at Amazon
#69Thanks for the information keep sharing https://www.walgreenslistens.biz/
Re: The “API Mandate” memo at Amazon
#70>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 feel like Google's approach is more popularized I mean, the engineering architecture being described in this memo is, basically, microservices. That's certainly an extremely popular -- I would go so far as to say even vogue -- pattern for solving the problem of building software at scale.
No, they're just services - a service per team.
Microservices usually overdoing it, when you have multiple microservices per team, and sometimes even per developer.
Also, microservices sometimes implemented incorrectly, where they're still communicate via shared databases, instead of encapsulating them and exposing them via service APIs only.
This Memo was born because of the real business need, while many modern microservices deployments are the result of cargo-culting GAFAMs/FANGs.