Comment by teddyh
7 years ago
I am reminded of the "API" decision made by Jeff Bezos at Amazon, as famously described by Steve Yegge:
So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion -- back around 2002 I think, plus or minus a year -- he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses.
His Big Mandate went something along these lines:
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) 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. The only communication allowed is via service interface calls over the network.
4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
5) 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.
6) Anyone who doesn't do this will be fired.
This sounds "great", but how exactly does your team that works on say, a matrix library for computer graphics, expose its data over the network?
Perhaps instead of it being "all teams" it should be "all cpu processes"?
They don't, they write a library and others consume it.
It's not a "you must find some data or service to expose". If you have data and someone wants to use it, they do it via service.
ala tell, don't ask.
https://martinfowler.com/bliki/TellDontAsk.html
I'd also like to point out that with all design decisions there are trade offs. Bezos made these trade offs specifically with Amazon's scale in mind and likely would not make the same trade offs with a team of 5 devs or even a team of a thousand devs that had good habbits around adhering to data boundries.
Clearly the dev culture at Amazon had a habbit of abusing those boundries or it wouldn't have gotten to the point where such a black and white mandate made a net positive change to the status quo.
1 reply →
The Sql services started without any data. The service started with empty tables. But yet they have an Sql service.
2 replies →
This is how Bezos built AWS, so he meant services that are needed to build websites, such as databases, servers, containers, queues, caches, storage...
Bezos built AWS like Hadrian built a wall; both ordered that something be done, and it was left to tens of thousands of others to implement it. If you want to credit them with a lone vision, that’s fine if a bit unlikely given the reality of advisors and boards, but let’s not buy into the level of myth making required to say they built things.
3 replies →
> This is how Bezos built AWS
Bezos didn't build AWS, people who worked for him did. They also didn't do it as part of the normal day to day at Amazon, no matter how much Amazon pushes the "it's the tech we use already" narrative.
2 replies →
In that example they'd expose it through the source control system and through the build system, though that's really stretching the meaning.
What it really means is that if you're building something that you run on your teams hosts it needs to be exposed through services. For most of the services at amazon that means using the common service interfaces that everyone uses and not just giving out DB credentials (which I've seen happen it took (think it's still in progress 5+ years later)) to untangle.
That seems fair. Any team that was already using the network to communicate should change to a public service architecture.
That's a weird example. A team that makes a library probably doesn't share too much data with other teams. I think this directive is more like, don't share a spreadsheet of your quarterly stats.
It's supposed to be a weird example. We could think of lots of things that don't belong as services. Bezos's post doesn't offer guidance on what should be a service - only that you'll be fired if your team doesn't have one.
The non-sarcastic answer is either:
- you build a matrix math system as a service... or
- you build cloud rendering (as they have done several times)
What matrix library for computer graphics was Amazon working on back in the early 2000s? Genuinely curious since I don't hear much about things like that from Amazon.
Advertise schemas and accept functions over that schema.
Curious, do you have examples of this working well? It sounds like SOAP, which in my experience ends badly. Yes because, well, SOAP, but also because sharing your schema means you're stuck with it along with any internal assumptions about design that result from it.
I'm assuming you're more likely talking about something like GRPC/protobuf which I have similar gripes about.
1 reply →