Presentation: Platforms at Twilio: Unlocking Developer Effectiveness

Track: Developer Experience: Level up Your Engineering Effectiveness

Location: Broadway Ballroom North Center, 6th fl.

Duration: 4:10pm - 5:00pm

Day of week: Friday

Level: Intermediate

Persona: Architect, Developer

Share this on:

What You’ll Learn

  1. Find out how Twilio embraced microservices and DevOps with some of the lessons learned doing that.

  2. Learn how Twilio built their platform so it can be used even by their developers like they are customers.

  3. Hear how and why a platform can be built in a declarative not imperative way.

Abstract

What does the DevOps tooling look like at your organization? A result of the mainstream adoption of microservice architectures and DevOps culture is the increased burden of complexity and responsibilities for software engineers. Since Twilio’s inception, it has adopted a DevOps culture of “You build it, you run it”. Learn how Twilio’s internal Platform has evolved to reduce their engineer’s cognitive load by providing a unified self-service, declarative platform to build, deliver, and run the thousands of global microservices that make up Twilio. This talk will discuss the evolution, tenets, and lessons learned of Twilio’s internal Platform.

Find out how Twilio's Platform Engineering team takes the learnings acquired from Twilio, uses those developer-centric values to boost productivity and reduce cognitive load for Twilio's R&D organization, and strives to achieve their mission to be “Twilio for Twilio”.

 

Question: 

What are you doing today?

Answer: 

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.

Question: 

What's the focus of the talk?

Answer: 

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.

Question: 

You mentioned about treating your internal engineers like a customer. Can you share some of the lessons that you might mention in your talk?

Answer: 

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.

Question: 

Who is the core audience that you're talking to?

Answer: 

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.

Question: 

So key takeaways are lessons learned. Any other key takeaways that you want to highlight?

Answer: 

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.

Speaker: Justin Kitagawa

Senior Director Platform Engineering @twilio

Justin Kitagawa is a Senior Director of Engineering at Twilio. He has been building and using clouds for over a decade.  Justin leads Platform Foundation at Twilio, a platform organization responsible for cloud orchestration and edge infrastructure. A third-generation builder, he loves architecture, distributed systems, and platform development.

Find Justin Kitagawa at

Similar Talks

Staff Infrastructure Engineer @travisci
Author of Effective Java, Lead Design of Java Collection API & Carnegie Mellon Professor
Lead Data Architect, Risk and Compliance Management Platform @PayPal
Senior Software Engineer, Operational Insights @Netflix
Engineering Leader @Netflix, previously leading architecture teams @eBay & @Sun

Tracks