Presentation: Platforms at Twilio: Unlocking Developer Effectiveness

I'm a senior director of engineering for our platform. Twilio is comprised of 100+ different engineering teams. We share the same engineering DNA as Amazon and Netflix, so we have smaller autonomous 2-pizzas teams that are responsible for a subsection of our overall puzzle. There are vertical teams and horizontal teams. Vertical teams take a subset of our customer-facing communication platform. For instance, the product that is known as the voice of Twilio is really comprised on the back-end of nine different engineering teams. For instance, recordings and transcriptions is an engineering team that's just responsible for saving the bits of voice phone calls or video chats. Then providing an API for our customers to retrieve them. We have a strong DevOps culture, so teams own and operate their own services. As a result of that, Twilio has been a leader and a pioneer in this space because we've been doing it for 8+ years of DevOps microservice architecture. As a result of that, we all have our horizontal teams which are platform teams and the platform teams provide common services for the vertical teams. And so my responsibilities are five platform teams. Two of the teams are edge infrastructure, the federated console gateway and API.  100% of console and API traffic comes through these teams. Then I’m responsible for some back-end teams that are the orchestration teams, and they provide the tooling and orchestration necessary to manage a global distributed microservices.

One of our engineering platform tenets is declarative over imperative. When we were building out our platform we really wanted to build a declarative platform over an imperative one. What does this mean? Declarative is emphasizing the what over the how. We want our engineers to specify their end state of the world, but not necessarily how to go about to get to that. And then our platform makes sure that we do the hard lifting here to go and do this. This parallels with what we've done with our customer facing platform. It enables us to be able to apply the best practices for that and not impose that onto our end users. I've got various examples that will demonstrate that, how our API has a declarative representation of our APIs which facilitates a proxy layer, ensuring that we have a safe front door for APIs. How we generate helper libraries automatically from this declarative API, or how we can safely refactor microservices on the back-end through this declarative representation. Also on our deployments front we have a declarative way that we specify our deployments and we have very complex deployments that we've removed the complexity from our end engineers. We've automated away so that the engineers don't have to think about it. All of this is about reducing the context for engineers.