Hacker News Reader

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.

The “rumor” I know is that Amazon internally had a system broadly similar to S3/EC2, where a centralized infrastructure team made hardware resources available to the other teams through API.

Then Amazon realized that they could use a similar system with external customers. They built S3 and other services in a way similar to their internal infrastructure, but completely separate.

Only years later Amazon started using AWS for their internal services.

It's sort of hard to compare these approaches, since it's not like Amazon and Apple only have 1 principle that they follow. I'll try to analyze them in a generic way. Disclaimer that I don't have experience in marketing or executive leadership.

Apple's focus on design allows it to charge higher for its products and to build new high-margin products that people end up buying. It allows them to "scale" revenue by entering new markets with new products.

Amazon has a similar focus on the customer which is centered around customer support. This approach also gives them the "brand reputation" to build new services (that businesses will pay for). You may note that Apple's approach works better for customers who pay without much planning/budgeting (like consumers/households), scales better with the number of customers (again like consumers/households), and scales more poorly with # of products (making it a worse fit for SaaS).

Amazon's API mandate value is felt in how it allows them to make software development more efficient. Customers do not feel the impact directly. Instead, since data is exposed through well-defined APIs, new service (or product) development can be done with far less human communication, as mentioned in the article. However, while this makes inter-team efficiency better, it reduces intra-team efficiency by forcing developers to build things that they don't need. If services are too small, the APIs are not high-quality, or the service boundaries change too frequently, then it's possible that this approach doesn't make software engineering more efficient at Amazon.

> Amazon has a similar focus on the customer which is centered around customer support

Except that for AWS, paying for the service(s) doesn't get you any support at all. So this idea about Amazon's behavior on its marketplace doesn't really map to AWS. Customers there have to choose to receive customer support, and pay for it separately.

> How far does this principle scale?

I think this principle scales most to platforms, in this case web ones.

There's an interesting thing called the "Bill Gates line": https://stratechery.com/2018/the-bill-gates-line/ (third sub-heading in the article). Basically: "A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform."

From your example, the Fruit Company is a platform, but not really. I'm not entirely convinced that others capture more value from the Fruit Company ecosystem. Yes, for the AppStore they only get 30% of the value of third party sales, but they also sell the hardware and have their own extras. The Fruit Company is a platform company primarily by virtue of creating hardware, which generally makes one a platform, but other than that, they definitely look like they don't want to be a platform with the way they control everything, break stuff, etc.

AWS is for sure a platform.

Typical Apple products and services are fewer, more complex, and with enormously longer development time than Typical Amazon "products", so they could find processes that target great quality at high cost (e.g. "ask Steve Jobs") more useful than processes that target good enough quality at minimum cost.

> 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.

There was a recent article about another concise memo making the case to Steve Jobs for an iOS App Store, which Jobs quickly approved.

So I think the same kind of systems thinking and understanding technological ramifications of decisions at the very top, also played a large role in Apple's success.

I think you're trying to compare and contrast things that don't contradict each other. Having APIs is one thing (and Apple has lots of APIs about many things), and integrating the whole experience is another. Amazon and Apple do both.

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.

You say it yourself at the end, but it's really a case of comparing apples (eh) and oranges.

You can't build an OS or a chipset the same way you build AWS or a warehouse.

> it’s probably the most important single memo in the history of business

Maybe that's what you disagree with? I also find it a bit overblown. The memo worked wonders for Amazon, I'm sure it would work wonders for many other companies, but the world is more diverse than that.

Italy, France, and Portugal are playing a 4-3-3 at the Euros. Germany is using a 3-4-2-1. Hungary is playing a 3-5-2.

They can all be successful if you have the players executing their roles well. The structure and plan is necessary but it is not sufficient for success.