Ben Gilbert: evaluation

Transcript context

…It's funny. We thought a lot about it in this episode. How do we tell this story for non-technical members of our audience without getting too much into technical weeds? This is all pretty technical now, but I don't think we can avoid it. This is so important. The context here is let's zoom back out from service-oriented architecture, APIs, and all this. What's really going on here? What's really going on here is this is the beginning of focus on what makes your beer taste better. All of this junk we're talking about, all this technical junk, it's technical junk from the perspective of what actually matters as a business. What matters as a business is the customer experience, new features, customer satisfaction, revenue, and profits. All of this junk was getting in the way. This is where Jeff has this realization of none of that makes the beer taste better. Let's standardize, get rid of all communication, API-assize, all of it, and then everybody here can spend all of their time just focusing on new features to make the beer taste better on amazon.com. Yup. The other thing that it is is a very Amazonian concept of documentation. Of course, they start all these meetings with the six-pagers and the PR/FAQs. We're not doing PowerPoint slides. We're just working backwards from this document of what the customer will actually experience. APIs are a heavily documentation-oriented way of computing. When I'm hitting your API endpoint, there is a strictly documented set of requirements of things I can send you and ways in which you send information back. Whereas if I'm allowed to communicate directly with your database, you and I can have a little conversation, you can tell me like, oh, yeah, that field, we stopped using for this purpose and started using for this other purpose, so just keep that in mind. There's no keep that in mind in APIs. There's, when you hit this thing, you will get that thing back. It brings this true precision hardened belief in the way in which that thing will respond when I hit it that is documented and you must keep the documentation up to date with the way it actually performs. All right, we're in story number three at this point. (1) The apocryphal got some extra hardware lying around. (2) This idea that Tim O'Reilly brings up web 2.0 and APIs, so they start working on the Amazon Associates API. (3) This idea of, okay, the organization is moving too slow, and a way to speed it up internally just for our own step one internal use case, is make it so that the teams communicate with each other via API. Once they start doing that, and obviously, before Steve Yegge writes his rant and publishes on the Internet, they start realizing, okay, they are parts of this where it may make sense to start being external-facing, because once we get this stuff right, and we've toiled around in the darkness so much trying to get this stuff, right, and I don't think it's helping our customers at all, maybe there are other people out there who are experiencing the same blunt force trauma just trying to keep their infrastructure up and modern. There's one more small compared to the big ideas but inevitable as things were going. One more leap that we should talk about that happens here. everything we just described so far in AWS origin story number three, is related to software engineering and the amazon.com codebase. What AWS is is abstracted hardware IT infrastructure. And software, too. But the core like S3, EC2, that's IT infrastructure. How do you get from transforming your software architecture to, oh, now I need cloud IT infrastructure? It's the same problem. It's an inevitable outcome. When you transition your software architecture to the service-oriented architecture and no longer a monolithic codebase, IT used to centrally plan, like we were talking about. We can ship these features at these times, we need a code freeze at that time, we need X capacity, we can forecast that, and we can look out into the future. Now with this, you've got all these distributed teams doing God knows what without talking to anybody, IT can't centrally plan anymore. What Amazon realizes is they need to do the same thing with IT that they did with software engineering, which is transform it also into an API-accessible pool of computing resources, versus I'm giving you this server and that's what you got.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.