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.

To share how Twilio does platforms, lessons learned over the years, and some philosophical choices that we have taken as well. All of this is geared towards making our engineers successful and we treat other engineering teams as paid customers. For instance,  we have NPS reports that we do quarterly so that we can measure ourselves, how effective we are at enabling our customers. We've seen a very positive upward trend on enabling our customers. I just want to share how Twilio does this. Twilio is about platforms and enabling our customers. Internally, our engineering platform is a parallel of that but we are enabling our engineers to be able to own and operate their services and we aspire to be Twilio for Twilio if you will.

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.

I feel that the trend right now is organizations are moving to microservices and DevOps, and this now is almost commonplace and common practice, and even major Fortune 500 companies are adopting these principles. I believe that there are enterprises that are either looking to adopt DevOps or have adopted DevOps, and they want to learn how to do it better. I want to be able to share how we've done it at Twilio, so we can help the broader community become better at this.

I want people to take these learnings and feel empowered, and ideally to be able to bring them into their respective organizations and apply them.