Amazon Enterprise Lessons
The Enterprises we admire are those that stand the test of time; those who do great things with leadership and ability. While Amazon is not very old, they have done some very dramatic things from inception. Whether it’s building the biggest cluster on Earth (AWS) or the biggest store, Jeff Bezos and company have been kicking butt. It’s true that Amazon runs at what I would describe as “Vanishingly thin” margins, but they have built what looks to be a sustainable business that anyone would be proud to own. It was not always this way, particularly when we talk about software development at Amazon.
Once upon a time…
Amazon was growing, like nothing ever grew before to be honest. With this rampant evolution, engineers spent more time making stuff work than making stuff optimal, a perfectly natural consequence of a quick pace of innovation, but one that inevitably creates technical debt. What is Technical Debt? Well, when you build things quickly, you do it in a way that may not be optimal long term; it was just the quickest answer that worked. Rich Hickey, founder of Clojure and Lisp enthusiast, has a great presentation called Simple made Easy which discusses software design choices. I won’t spoil Rich’s lecture, but there’s one slide from his presentation that really stuck with me (you should definitely go watch that presentation by the way. It’s awesome). Anyways, here’s the slide I’m talking about.
You can see that in this picture, Easy gets you to market faster, but Simple increases your velocity over time. In some projects, an easy fix is acceptable, but for the majority of projects, doing things in the easiest manner will create problems down the road. Thus, Simple is better than Easy, but Simple doesn’t mean uncomplicated, in fact quite the contrary. Simple actually means the complexity is hidden from the user, which is the real value of APIs.
Ok but what does this have to do with Amazon?
Amazon was growing really fast, and doing a lot of things the easy way. As Amazon grew and services evolved to be bigger and badder, the easy fixes started to break at an alarming rate. It was clear to the management team (I credit a lot of prescience here) that if something didn’t change, Amazon was going to eventually stop growing because of Technical debt. Jeff Bezos set out a series of rules that were going to change his Enterprise, I like to think of this as the origin of Modern Service-Oriented Architecture. The rules were:
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- There will be no other form of inter-process 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.
- It doesn’t matter what technology they use.
- 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.
- The Mandate closed with: Anyone who doesn’t do this will be fired. Thank you; have a nice day!
Jeff set out to re-architect his Enterprise. The point of APIs is simple: services evolve dynamically, but their methods of access should be static. That means that it doesn’t matter what you use to deliver the service, I will always make the same request to you and it’s your job to figure out how to answer this request.
Situation: A performance engineer needs information about how fast amazon.com is loading.
Problem: The Web Analytics team just changed from MySQL to PostgreSQL.
The old way of doing things: The performance engineer will run the SQL query he’s been given and it may or may not work depending on how the database migration was done.
The new way of doing things: The performance engineer makes an API request that the Web Analytics team has to fulfill.
Under the old way of doing things, interoperability between services was hit or miss depending on who you knew in that department or how much you knew about their systems. Under the new way of doing things, the Web Analytics team can’t deploy a new database without first ensuring that database can respond to API requests from other teams. The old way creates software fiefdoms and the new way creates services anyone can consume.
Modern Enterprise Software Development
The truth is nobody wants to wait anymore. Your board doesn’t want to wait, your customer won’t wait and your employees won’t wait either. Business has to evolve to respond to the demands of modern commerce. When you expose the capabilities of your business as services, everyone wins, which is why we’re working so hard to expose Telecom as a service in ours. At 2600hz, we see a competitive advantage in exposing Telecom services to the Enterprise, not because everyone needs telecom, but because when you do you don’t want to have to go outside your walls to get it.
Traditional, and manual, database integrations are irrational in modern software development. Exposing your technology via API speeds the pace of software development and prevents the Silo’ing of data (putting data into a warehouse never to be heard from again). This is a more sensible way of exposing data and it is how all modern software companies operate.
Service Oriented Architecture is here to stay. If your business provides services, it would be wise to at least consider exposing those services via API; you might be very surprised by what people do with your technology.
Are you working on a product or service that could use some telecom attention? We’d love to chat with you! Contact email@example.com today to learn more about our platform and how you can put our APIs to work!
Joshua Goldbard is a VP at 2600hz, the Cloud Telecom company. He’s a complete geek, loves beer and electronic music. Occasionally, find him at Toronado in San Francisco debating the merits of audio codecs..