41–50 of 136 posts
APIs (and opaque modules, in general) are key to the way I develop software. It works well.
(0) https://littlegreenviper.com/miscellany/evolutionary-design-...
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 attention to detail, leveraging their integration and their ability to move in ways they do because of their thorough integration across their whole hardware/software stack. They've recently been in the press because of just how much they were able to tune their integration to the problem with their first desktop computing chip. Again, we credit their success with some causality due to this strategy, which (to me) is very different than the Amazon strategy.
Is it because Amazon is a cloud company and Apple is a hardware company that they have these different approaches to product development and each enjoy success? Or at the end of the day, are these "do it this way" less responsible than we'd like to believe?
> Teams must communicate with each other through these interfaces.
I read that as interfaces to the team, instead of interfaces to software the team is responsible for. Something like Mechanical Turk(https://www.mturk.com/) but for internal team communication. I'm not sure if that was what was meant but that sounds interesting.
Things like these are taken as dogma or a religion -- and are applied to all things in an organization, for better or for worse. When there's a case for tighter coupling and less services, (and yes, there are cases for it), this memo gets brought up and microservices win the argument.
What is an organizational case for tighter coupling and fewer services? Downsizing with an intent to not grow in the same direction again?
Each of my APIs is a self-contained project, with its own lifecycle.
That can, potentially, add a lot of overhead, and “concrete galosh”[0] to the project.
And I am not a fan of dogma, in general. I like flexibility, and dogma is anathema to flexibility.
[0] https://littlegreenviper.com/miscellany/concrete-galoshes/
Does 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…
“graduated from Princeton University in 1986. He holds a degree in electrical engineering and computer science”.
Of course he’s more known for his decision-making ability as an executive but he clearly has a solid understanding of computing fundamentals as his memo on Amazon S3 characterized it as “malloc for the Internet” [0][1].
0: https://aws.amazon.com/blogs/aws/eight-years-and-counting-of...
1: https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-...
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…
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.
CORBA is quite close to direct linking, with a network in between. The developer does not see it as a service or protocol, but a library call, which is rather the point. And it's not very compatible with the next one:
> 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.
CORBA/COM never played well over the internet.
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…
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.
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…
Background - Oct 12, 2011: > Google engineer Steve Yegge was trying to start a robust internal discussion, not post a viral hit, when he published a 4,570-word self-styled rant about what he sees as the company’s greatest flaw to Google+. Unfortunately for Yegge, he didn’t check the settings and shared his view on Google’s failure to grasp platforms over products — including Google+ — with everyone. > He later pulled…