Werner Vogels Quotes

Amos Vogel was a mentor, a guiding light for me. In his presence, you always rose. But his importance to me is of minor significance. What is significant is that with him an entire epoch ends. The Last Lion has left us. I am still not capable – or rather unwilling – to understand the fact that Amos passed away, because a man like him cannot be dead. His traces are everywhere. (on the passing of Amos Vogel, his friend for more than 45 years)

2006 interview by Jim Gray, Amazon CTO Werner Vogels recalled another watershed moment: We went through a period of serious introspection and concluded that a service-oriented architecture would give us the level of isolation that would allow us to build many software components rapidly and independently. By the way, this was way before service-oriented was a buzzword. For us service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interface. No direct database access is allowed from outside the service, and there’s no data sharing among the services.3 That’s a lot to unpack for non–software engineers, but the basic idea is this: If multiple teams have direct access to a shared block of software code or some part of a database, they slow each other down. Whether they’re allowed to change the way the code works, change how the data are organized, or merely build something that uses the shared code or data, everybody is at risk if anybody makes a change. Managing that risk requires a lot of time spent in coordination. The solution is to encapsulate, that is, assign ownership of a given block of code or part of a database to one team. Anyone else who wants something from that walled-off area must make a well-documented service request via an API.

According to Werner Vogels, CTO of Amazon, in 2014 Amazon did 50 million deploys to individual hosts. That’s about one every second.

In a 2006 interview by Jim Gray, Amazon CTO Werner Vogels recalled another watershed moment: We went through a period of serious introspection and concluded that a service-oriented architecture would give us the level of isolation that would allow us to build many software components rapidly and independently. By the way, this was way before service-oriented was a buzzword. For us service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interface. No direct database access is allowed from outside the service, and there’s no data sharing among the services.3 That’s a lot to unpack for non–software engineers, but the basic idea is this: If multiple teams have direct access to a shared block of software code or some part of a database, they slow each other down. Whether they’re allowed to change the way the code works, change how the data are organized, or merely build something that uses the shared code or data, everybody is at risk if anybody makes a change. Managing that risk requires a lot of time spent in coordination. The solution is to encapsulate, that is, assign ownership of a given block of code or part of a database to one team. Anyone else who wants something from that walled-off area must make a well-documented service request via an API.

Amazon, for its part, has a couple of other easy suggestions for you if the advice “write a hypothetical press release” doesn’t quite work for your situation. Their CTO, Werner Vogels, suggests trying to write an FAQ for this product you’re developing. (That way you can address, in advance, potential user issues and questions.)9 Or try to define the crucial parts of the user experience by making mockups of pages, writing hypothetical case studies so you can actually start to see what it would look like and who it would work for and how. Finally, try writing the user manual, which as Werner explains usually has three parts: concepts, how-to, and reference. (Defining these means you understand your idea in and out from the customers perspective. Also, he says, if you have more than one type of user then write multiple manuals.)

Werner Vogels of Amazon notes that this approach—where you’re knowingly permissive of duplicated work—is often a nonstarter at traditional companies, which tend to feel it’s out of control or chaotic. “It’s so counterintuitive for them because they’re all about efficiency,” he explains. “They’re used to having top-down control, and in essence the hierarchy becomes more important than moving fast.