Supporting 10 Million Developers
Ep. 13: Phil Nash, developer evangelist at Twilio.
Moesif’s Podcast Network: Providing actionable insights for API product managers and other API professionals.
Joining us is Phil Nash, leading developer evangelist at Twilio, a Google Developer Expert and a member of the Live Coders team on Twitch. He’s a regular conference speaker where he sometimes writes code on stage and hopes everything just works.
Derric Gilling, Moesif’s CEO, is your host today.
Listen to the episode on SoundCloud above, watch it on our YouTube Channel or download it on Apple or Google.
Table of Contents
- 1:00 Developer Evangelism Evolves with Growth
- 3:40Twilio Scales Through Acquisitions
- 6:55Language Varies From Product to Product
- 8:38Make APIs Standard
- 12:17OpenAPI Aids Library Creation
- 14:19Devs Want CLIs
- 18:00Offer a Serverless Platform for Local Dev
- 21:50Customers and Developer Platforms Share Best Practices
- 25:18Segment Data to Ensure API Privacy
- 27:20Developer First Equals Developer Empathy
- 30:19Supporting Developers Requires Community Building
- 35:25Remote Access Enables Diversity at Conferences
- 38:04API Success is More Difficult Than Ever
Derric Gilling (Moesif): Welcome to another episode from Moesif’s Podcast Network APIs over IPAs. We provide analytics for API product managers and other API professionals. Joining me today is Phil Nash, from Twilio. He’s one of the earliest developer experience professionals at the API-first pioneer. Twilio focuses on communication SMS and now is getting into video and a lot of other things. Super happy to have you here Phil.
Phil Nash (Twilio): So good to be here. Thank you for the invitation. I want to point out that I’m one of the earliest developer experience professionals still at Twilio, but I joined in 2014, and we’ve been going since 2008. Some of the earliest hires were on the evangelism team and I get to build on top of a lot of the work they did in those first six years. It’s a pleasure to be a part of the team and carry on their work.
Developer Evangelism Evolves with Growth
How do you support developers as your product becomes more successful? Twilio split the original evangelism team into two: education and docs, to handle devs at scale.
Derric: I would love to hear a little bit more around that story. Twilio was a couple hundred people when you joined them, building out the developer evangelism team, and now Twilio is up to 4,500 people.
Phil Nash (Twilio): It’s something like that. I think we probably just released bigger numbers recently, but we’ll stick with 4,500 for now. We just keep buying companies at the moment and that number goes up fast. It’s been an incredible journey really. When I joined Twilio, there were about 300 people in the company in 2014.
It was the biggest company that I had worked at, at that time, which is a weird thing for me. I’d gone from a company like an agency that had never gotten bigger than 50 people into this 300 person company. It felt like a big place to me. Now that it’s into the thousands it’s overwhelming at times. It’s been nice for me because I worked initially in the London office and now I’m down in Australia. Always sort of part of the satellite teams, just always felt like a bit smaller and a bit more like family for me. It’s incredible to know that there’s this huge sort of machine behind me to do the work and produce the product we do.
When I joined the evangelism team, it was just in the process of actually splitting into two teams, which was the start of our journey into building what we now call our developer network team. Which encompasses all sorts of facets of the developer kind of experience with Twilio and the community experience at Twilio as well. At that time we were considering what became our developer education team, which is a team solely focused on the documentation, platform for the documentation and building that kind of thing into a practice that we could focus on. I think that over the last seven years, the building of Twilio and certainly building the experience of Twilio has been a case of more and more focus of things. Like I said, we’ve gone from that original evangelism team, and then two guys split out from there to do the education team and built out the docs platform. Since then they’ve built a game-they built TwilioQuest. Have you seen that?
Derric: I don’t think so, but it sounds interesting, I’ll have to check it out.
Twilio Scales Through Acquisitions
In order to best serve their customer base during growth, Twilio continues to add additional products via acquisitions. At a certain size, Twilio needed to develop more products than they could handle internally, leading them to purchase companies like Segment or SendGrid to offer their customer’s more capabilities.
Phil: Yes, please do. We’re coming up to a fancy new release sometime soon. It’s a game, a full 2D top down kind of RPG adventure that also teaches you how to code and how to use the Twilio API, as well as introductions to other programming languages at the moment. We’re just working on it and it’s possible now to actually build your own levels for that as well, so we’re hoping to see a lot more stuff coming out of that. We’ve built that and then we have a sort of more community focus team, which has kind of been in and out of things that used to handle social and things like that. Now it’s focused on forums, champions programs and things like that. Meanwhile the evangelism team continues to try and go out to where developers are in the world or where they are online. More likely in the last 18 months, in order to take the word of Twilio to them, but also bring that experience back.
In the meantime, we’ve also grown enormous numbers of products. When I started there was voice and SMS. You could make phone calls from a browser and mobile apps on the devices. Since then we’ve added chat, video and all sorts of other additions that has spread the knowledge quite thin. And then, of course, brought in other companies. So we brought in Auth0 and added two-factor authentication and verification. We brought in more recently SendGrid, then Segment, and I’m still catching up. I have no idea how you use Segment yet, but I’ll get there. Getting better at SendGrid though; email delivery ability is not as easy as one might think, when you do so many emails during the day. So yeah, there’s been a lot of that. I think the nice thing is the product and everything at Twilio has always remained developer first. That allows us to support and help developers along the way, all the way from seven years ago to today.
Derric: Well it’s funny that you mentioned acquiring all these different companies. We’re SendGrids’ customer, we’re Twilios’ customer to power some of our learning features, and we’re partner with Segments, so it’s really intertwined with Twilio over there.
Phil: Seems that way, I think that’s what we’re trying to do. We noticed that these things fit well together. I think SendGrid is fairly obvious that it’s a communications channel that we didn’t have and getting SendGrid involved was picking the best company out there on the market. It was doing it to become part of Twilio. Segment might seem a little bit weird but at the end of the day, behind all of the communications thing is customer journeys and customer data that you want to expose the way you then communicate with people. I think it’s an exciting feature for how that all ties together.
Language Varies From Product to Product
The term “API” may feel like a buzzword without proper documentation and explanation. Twilio’s messaging comes together because they keep their products under one roof.
Derric: Has that made developer evangelism a challenge? Going from just talking about SMS and how to send a message, versus SendGrid and all these different ways about thinking about marketing to developers. Is it a common process or common language that you have or is it all different to each product or each area?
Phil: That’s a good question. I think it’s become more difficult in sort of the elevator pitch, when you used to be able to say, “You can send or receive text messages, make or receive phone calls. Go have at it, it’s an API; go!” Now it’s this wide expanse of things that you need longer elevators for that kind of thing.
It’s difficult to say, the expense of the marketing team and getting the message out for this has been an important part of it as well. On the other hand, we are still working to integrate some of these purchases. Segment, for the most part, continues to look after itself and continue its own messaging and reach out to people. So that’s been easy for now. It’ll be interesting to look to Signal, which is our conference in October, for how that messaging comes together because that’s everything Twilio under one roof at that point. We’ll see some interesting things there I think. Nothing I can give away right now, as far as I’m aware.
Make APIs Standard
How does Twilio make life easier for developers? Twilio’s developer experience and relations teams are focused on making sure APIs are standard and have consistent quality across the business.
Derric: I would love to hear more around how you structure developer relations. We’ve got so many different roles these days: developer advocate, developer experience, developer relations itself. How was that sourced at Twilio and what have you seen work well in terms of responsibilities?
Phil: That’s a good question and I will be upfront with you. Let’s step one step back to developer experience. I think developer experiences are important to all of Twilio, right? If the API teams aren’t producing great products for developers, then everything falls down on that. Everything else becomes layers on top of that, to make life better, easier for developers. There is a developer experience team that is not within the developer relations team. This is what we call our teams, they are focused on making sure those APIs are indeed standard and have consistent quality across the business, now there’s so many parts of it. Like I said, in the sort of developer relations side of things, we have this development network team, which deals with evangelism. That’s going out to communities and developers out there, education, building the docs platform and TwilioQuest as a game. The community is looking after the forum. We also have within there, an enterprise evangelism team which is a relatively new addition to this.
We’re taking the tactics and practices of regular evangelism and community events to larger businesses. Enterprises, effectively take them through hackathons, innovation sessions and give those businesses the opportunity to share a problem with their developers that hopefully, communications and the joy platform can help solve. Having Twilio experts on hand. Just set them going for a day or two, to try and build their own solutions and solve their own problems. We find within enterprises that tends to be a place where developers maybe don’t get that decision making opportunity that often. But when you put a problem in front of them with a tight deadline, in a small team to work on it, the developers have a great time building and finding this out, even if it’s their first experience with the API.
That’s what our enterprise evangelism team does, it takes Twilio out to those companies like that. Like I said, it’s that same kind of experience as regular in the Community kind of thing but moved to see that enterprise experience and it makes those developers a lot happier, it’s amazing. What else do we have? The startups team as well, that’s certainly fostering those newer and smaller companies where everybody in the team, everybody in the company could be a developer, or is at least a builder. Somebody who’s wanting to produce something in the world and the support, a little bit of funding, some credits go into the Twilio startup program, kind of helps them get off the ground and that’s great. There’s so many parts of this.
OpenAPI Aids Library Creation
Before OpenAPI spec library generators existed, Twilio wrote libraries against their own specifications, which was a tedious endeavor.
I’ve been talking about and working on the Twilio CLI. for example. That itself as a project came out of the developer education team, so the team that’s working with the docs. We were like, “we think we should have this as well”. That now, I think, has been taken over by a developer experience team, actually, which is good. It’s funny that some of these projects just came out of people wanting them to exist in the world. Then turning that into something we can call GA or generally available, is a different matter, it’s not just a version one on the NPM module sadly. When you won’t be able to deal with it, there are those developer experience team things there and a developer interfaces team as well, which works on all the helper libraries and other stuff like that.
The helper libraries themselves are written by a program that looks at our specs so the developer interfaces team deals with the bits around the edges of that, as well as the program outputting it as well. I think before OpenAPI spec library generators existed, we sat down and wrote against our own specifications. That’s got its own interesting things to deal with as well, it’s a big Python program that writes all our libraries. It can be a pain if you want to change the javascript library, you have to change to Python writing javascript in order to fix it. But for the most part, it doesn’t need that much fixing anymore, it just generates stuff and that’s nice. There’s lots of details, lots of things going on that specifically focus on this experience side of things. That structure is ever growing as we find other places to focus on.
Devs Want CLIs
The Command Line Interface (CLI) itself came out of a desire of the developer education team. Twilio’s CLI was created to help customers interact with a Twilio account that isn’t just through the UI in the console.
Derric: So what motivated creating the CLI and how do you measure the experience of it? I mean, it’s not like a web app where you can just install Amplitude or something.
Phil: That’s true, and like I said, the CLI itself came out of a desire of the developer education team to build. I think as developers we don’t necessarily like to get away from the keyboard that often and giving people an option to interact with a Twilio account that isn’t just through the UI in the console was one of the plans there. Also, the idea that maybe you can use this CLI as part of a build process or build pipeline as well. Those are the two things that they wanted to solve for. They built that and some of the early ways they got feedback on it was actually at our Signal conference back in say 2018 perhaps, where we would take people off and have proper user experience testing sessions with them. Like sit them in front of a keyboard with the early version of the CLI, and say “just go try achieve this with it and how did you get on with that?”. That was really good for early learning on that, but then, how you measure like CLI usage after that? It’s hard, you’re right, you can’t just whack analytics in it. Although, I think we are working more on that.
The rough thing is, CLI is published as both a NPM module and package on Homebrew right now. We are trying to add more packaging options to that so you don’t need to have Node installed in order to run it on most systems, we’re getting to that. The NPM install is a blunt kind of tool to ask if people are using? Are people getting involved in this? Following that we are working on ways to work at people who are using it so we’ve had to rearrange our user agent strings for our helper libraries, so they all report a little bit more on where they’re being used. Which we think is going to be really useful because ultimately the CLI is using the Node package, but not all calls from the Node package are obviously from the CLI, there’s plenty of people who have installed the Twilio node package elsewhere. So finding out which ones are going from where, and if that is growing usage, that’s going to be really interesting but we haven’t quite got there yet.
Then we have layers on top of that, there’s plugins to the CLI, some of which call the API, some of which don’t need to. Being able to tell if the call came not just from the CLI, not from the Node but from a plugin that was on top of the CLI is also going to be part and parcel of that as well. Measuring this is ongoing, but we definitely know from our user interviews and talking to customers that people are using it and using it for various things so we know that it is useful at least. We’re pretty happy with that. Personally, I don’t normally work on the core of the CLI myself but on one of the more bigger plugins, which is our serverless plugin, serverless toolkit we like to call it.
Offer a Serverless Platform for Local Dev
Where does development actually happen? Customers wanted to develop on their own computers rather than via tunneling and ngrok, requiring Twilio to create a lightweight serverless platform.
Stepping back again, one of the things we released at Twilio was a lightweight serverless platform as well, like Twilio Functions and Twilio Assets. Which allow people to host javascript and static assets in our infrastructure and use them by functions. The javascript can be called, like an AWS Lambda, a thing like that. We decided that was a good thing because this is another developer experience thing really, in working with web hooks, whilst probably the simplest way you could deal with real time interactions, with a phone call for example, was still something when you start developing and you want to do it on your own computer, suddenly it becomes difficult.
We’ve always pushed, like tunneling things and ngrok to us as part of that to make that easier. Even then people still find it hard, so we decide if you just write javascript, write something inside the Twilio console and have that deal with your incoming web hooks, that’ll be easier. Of course people wanted to do that, but then you find people wanting to turn that into a more development focused thing. Our first version of that was literally a text box, with a bit of syntax highlighting and validation inside the console. You want to be able to source control that and not just every time you save your redeploying something, your source control and then set up other deployments.
We built a second version of that which had an API. Meanwhile, myself and one of my colleagues, Dominic Kendall, had been working on various different tools. Dominic had worked on a tool called Twilio Run, which allows you to basically mimic the functions environment locally. So, we’ve gone all the way from “we need this remote environment, you can just use on the console”, to, “but I want to develop my own laptop with that”, so he built this Node wrapper for that. He built that and then I could never remember how to set up a project that would work with it, so I built a project generator for that, and that was the first two bits to it. Then the serverless team added an API. So we added an API set to that, Twilio run became able to deploy it, and then we packaged it all up into a Twilio plugin, a Twilio CLI plugin.
After all that, like I said, all of this becomes layers upon layers of what are people doing right now, where would people like to getto, as we’re building the little tools for it. I think we do actually get to improve that experience. Once again, I’m looking forward to having a bit more data from wherever those API calls are coming from to know how much this is being used. I know some of our customers are definitely using these things, particularly the serverless plugin, I’ve had to support them at times. We got an interesting bug a few months ago, which was based on what we now deem as a breaking change that happened in one of our dependencies, but not at a major version which caused us some problems. Semantic version everyone, it’s a great thing. Having supported those teams that this bug caused issues for meant I definitely know that people using this and it’s exciting to see that. It’s going to be exciting to see more data as well.
Customers and Developer Platforms Share Best Practices
How do you ensure that SDKs are robust and trackable? Twilio put the CLI into the hands of a team that is dedicated to improving the customer experience given customer feedback.
Derric: Definitely, and I’m glad you brought up the user agent string concept which is always important to track, all the different SDKs and different plugins that are using these APIs and get that uses data. You talked about multiple different layers on top of the CLI. What are things that people can be doing to the SDKs in different things, using these APIs to get the right metrics and just make sure that they’re able to figure out whether there’s bugs or not? Sometimes it could be a single SDK or a single weird use case that you never saw before.
Phil: Not quite sure what you mean by the question.
Derric: Is there anything else in terms of best practices that a customer could be doing or a developer platform can be doing with the SDKs to ensure they’re robust, and to ensure they’re trackable.
Phil: Right, I get you. That’s a good question. As you say, if you had a web application, you can stick some error tracking in there and things like that. I don’t think we have that kind of thing, we don’t phone home with our CLI, for anything other than actual API calls. Not to say that we might not do that in the future. That kind of thing is interesting. But I think if a bug occurs, if something goes wrong then the thing will stack trace on the terminal. I’m not sure that’s a bad thing, when you consider it, the product is for developers, the CLI is for developers and seeing a stack trace hopefully understandable for that. We encourage you to raise that as an issue in the repo.
Developers for the most part, are very willing to raise issues and tell you what’s wrong with the thing, almost too willing, at times. I think it’ll be interesting to see where we go with this and as we put the CLI into the hands of a team that is dedicated to it and dedicated to improving things like that.
I’m always wary of the idea of more tracking and things like that. If there are CLIs where you have to pass a flag or a command in order to turn off sharing that data and maybe if you don’t know about the command or flag, you’ve been sharing your usage of it without knowing and that’s potentially privacy encroaching. I’m not a huge fan of that kind of tracking. I’m comfortable with the user agent stuff because knowing where something came from is a good thing but any more than that, like looking after the usage is, I think there’s that line between making a better product and encroaching on other people’s work, their privacy and their data. I don’t want to see that much more tracking like that, I prefer it to be opt in rather than opt out as well. We’ll see about that.
Segment Data to Ensure API Privacy
How to be privacy conscious around APIs? Twilio has recommendations on what data is appropriate for various channels, along with protections on how customer data is stored within Twilio to ensure HIPAA and GDPR compliances.
Derric: When it comes to tracking API calls or logging API calls, is there anything that you do to be privacy conscious? Being careful of your customer data, I’m sure some of that data is very sensitive nature.
Phil: Oh absolutely. This is communications data between businesses and their customers.
We have recommendations on what data should and shouldn’t be sent over to various channels, of course, you don’t text in your credit card number. It’s not a good idea. We do have strong protections on how that data is kept and looked afterwards within Twilio. Many parts of the business, HIPAA compliant now and there’s a lot of work to deal with GDPR compliance back when that was a huge lift for the company at the time. I think one of the important things here is, we are as open about that and about how we look after the data as we possibly can.
To the point that it’s part of our API definitions and that gets generated into our documentation to say which properties on a resource, for example, are deemed personally identifiable information and then how long we intend to keep that for. When that’s going to expire, when it’s going to go out the system and that’s all in the docs. It’s all there at your fingertips, as you’re looking through that kind of thing. I think that’s really important and anything going through the CLI is also just calling those API endpoints. It is handled yet centrally, as far as I can tell.
Developer First Equals Developer Empathy
How do you ensure a successful customer experience if you’re “developer first”? When developers are your predominant customer base, being empathetic to their needs is a must for developer onboarding and customer retention.
Derric: Definitely, and taking a step back and discussing more around developer experience. What does developer empathy mean over at Twilio? How is it used or how do you think about it across different functions? Whether it’s the developer experience team or as a developer relations team, and so on.
Phil: Yeah I mean, I said at the start, everything in Twilio is developer focused, because they’re the first customer. We have a bunch of company values at Twilio and again company values, coming from a small company. Before I joined, Twilio was something I’d never seen before; they have a list of company values, one of which is to wear the customer’s shoes. That’s really important to us because it’s not just developer focused, of course, it’s empathy for all of our customers. Including the fact that, increasingly we have people who are not developers signing up for Twilio accounts and trying to work out what they can do with a platform that they told is really useful for communications. Having empathy for that non developer persona has also been really important. But the empathy for developers is very much the way that we deal with our products as developers ourselves, we try and use it ourselves. I think it’s really important and useful.
I think the business to have this developer network, developer relations team, that is not working on the core products themselves but tends to be or can be like those first users of the products and be that voice of the developer within the company, voice of the external developer, at least. Because we don’t know how it’s made, we just want to hear that we’re building a cool new product, we want to hear that experience and use it ourselves. A lot of feedback, early feedback we can give like that. At the same time, it comes from the top as well.
Jeff Lawson, the CEO, is still a developer. He doesn’t write production code for Twilio anymore, at least not that I’m aware of. But he is always building. I think in the last year he’s been producing, I think, zoom cube. It’s a whole different set of buttons that you can press to make different things in your video chat occur; 10 years on and off, mute, and a big button to hang up that kind of thing. It’s good to see that he is finding time to continue to be a developer, and a builder, and that filters down through the rest of the company as well.
Supporting Developers Requires Community Building
How does Twilio support their large range of developers at various experience levels? By engaging with their community of citizen and professional developers alike, Twilio is able to share information that helps developers create better applications.
Derric: That’s an interesting point and speaking on both supporting customers and developers, at the same time, and wearing their hat or wearing their shoes. Nowadays developers are not a single persona, right? We have some folks who are expert developers, we also have folks who are just learning to code for the very first time or using maybe a no code solution. How do you support all those different developers at the same time?
Phil: It’s increasingly hard to do that, you’re right. We have a whole range of developers using or trying to use the platform. We are actually trying to support that from the ground up. I mentioned TwilioQuest earlier and a lot of the TwilioQuest team are doing work to add more early stages of how to develop content. I believe there’s a lesson coming out on working with APIs, not specifically the Twilio API but like what is an API and how to work with one as a new lesson for the game. We’re trying to get TwilioQuest into universities starting in the US, to try to help out and teach people who are new to programming. And need to get on board with that because it’s such a useful skill for almost any role these days, so we’re working from there. We also did a lot of work in the last couple of years to produce and sample usable applications that people can build and install into their Twilio account without having to know what the code is. Although, there is a sort of code behind it, this is what we call the Twilio code exchange.
The code exchange itself is a sample project, and then there are quick deploy apps within that. Like when you hit a button, fill in a couple of details and you now have a functional Twilio application that you can go and use. We’ve released a couple recently that have been around notifications and information for vaccine hesitancy kind of stuff. As usual, Twilio has a bit of a plan to try and help as many people get vaccinated as possible during this pandemic. We have samples for that, but we have simple ones for one click just to get a voicemail thing going as well. Those one click and instant applications, quick deploy applications, they’re there for what we’re calling citizen developers, people who aren’t necessarily professional developers but want to achieve something.
The code is there behind it as well, and if you do deploy it and you want to change it, you can get a developer involved and update that. You mentioned low-code tools and Twilio Studio has been that kind of low code, I say. In order to do a few things, a couple of widgets within the drag and drop interface that can either call a Twilio functional or send off an HTTP request.
But, really like being able to build an entire communications flow in drag-and-drop has been enormously good for unlocking product managers and other things on the customer side to achieve a lot, not even just the basics, but a lot of the communication flow before having to get developers involved. That is really useful because as developers we don’t want to be doing the same thing over and over again, so just being able to build the interesting parts of those systems, I think has been really good, too. We’re also fully happy to support expert developers. They’re the ones that want the API references, they want the libraries and want to be left to go about it as well, and that’s exciting. And this is where I think we’ve now got more focused on our community team these days as well. We have forums and beta, which is kind of weird to think Twilio is a thirteen, fourteen year old company that hasn’t really had a forum for the community, at least a first party one for all that time.
I think we haven’t had one a different time but we’re going to renew our focus on that so that people can lead, come together, help each other, get a bit of help from people at Twilio and then we take that out as well. You’ll rarely find or I plan for it to be rarely found, that a stack overflow question tag Twilio doesn’t have an answer from one of us as well. We’re there to support people wherever and however they want to build with Twilio and there’s many more ways than that, but those are the ones that come to mind.
Remote Access Enables Diversity at Conferences
How has the COVID-19 pandemic impacted DevRel given the lack of in-person events? The transition to online conventions has led to a unique opportunity for event goers and companies alike: the ability to take part in events from any part of the globe, which allows for a far more diverse attendee group than possible before.
Derric: Definitely. I love the one click install or those types of installation processes. The example of batteries included but optional, you can modify as needed but just get started as quickly as possible. You mentioned COVID and how you’ve been thinking about that. I’m just curious, how has DevRel changed since COVID hit, especially with events no longer happening in person. And has it been accelerated? Has it been beneficial in a way, in terms of reaching developers?
Phil: Yes and no. The difference for me, certainly is I’ve been right here for a lot more of my time, rather than out and seeing people in person. We’re definitely missing in person, talking to people and getting people excited about things. On the other hand, I think it actually has led to reaching a whole bunch of different people in different places as well. The way events, meetups and other communities have gone online, has led to people from all over, being able to take part in them. Not just people who live in the right place or can afford to get there at the right time. I think that’s what has democratized things a lot. For developer relations, it makes it a little bit more difficult, I think I’ve yet to see an online event that has the same sponsor experience as an in person event.
I think that’s understandable, when you have a bunch of talks and a gap in the middle, and people are at home watching it. They’re going to go make a cup of tea or coffee in that break, they’re not going to hang out at the virtual booths and that’s fine. We have to work on better ways to engage with people. I think we still are but that’s an ongoing thing to work on within events as well.
Derric: That was a really good point around the events. The fact is that it’s hard to network, right? Going to a conference or something, one of the easiest ways to meet new people is by hanging around the booths, the happy hours and all the other activities going on, like hackathons and such.
Phil: Exactly, I do all my best work at the after party.
API Success is More Difficult Than Ever
Breaking into the world of APIs is no longer about providing an answer to a problem but rather a complete solution package as an API platform. But, for API developers, toolkits will continue to provide flexibility in building applications thanks to the plethora of tooling available.
Derric: Funny enough, right? My last question is around the future of APIs and DevRel. What do you see next and where do you see API’s going?
Phil: That’s tough, I think within the bigger API companies a lot of consolidation right now. I’m obviously saying that from the point of view of Twilio, where we buy in the occasional other API company, but there’s a bit more of that going around. I feel like more recently there’s been a bunch of more back to basics, things like databases and other connectivity things are new and exciting, which is sort of a surprise to me. I guess there’s new and better fundamental technology that’s driving this. Though of course anybody trying to do a completely fundamental thing like a database is fighting against your big three cloud operators regardless. So, you really have to have a very impressive reason to exist. I haven’t managed to play with many of them myself but I’m excited to do so at some point.
What’s the future for it though? I think it’s getting more difficult to enter the API space because there’s so many things you need to provide to bring the same experience that somebody who’s been doing it for a decade or more has been able to provide. Of course, there are open source tools that have come along with this kind of thing, which make it easier to get there but there’s just a lot to think about. One thing that even we have shied away from is sort of providing UI kits to deal with that kind of thing as well. I think Stripe is very good at providing actual UI for things as well, but being able to do that across not only browsers.
Being able to provide UIs across, not just browsers and javascript front ends and the kind of frameworks that are there. But then the necessary native applications, their framework, then their cross platform frameworks, your flutter and react native that kind of thing. There’s a lot to maybe produce when you come out with this. I kind of wish anyone well, who is building new things in APIs basis because there’s a lot to consider and a lot to think about. Even though as a developer, I think it’s a wonderful time to be building products and building applications because there’s such a lot of tooling available to you to build the way you want to. As an API company, being able to provide everything for those people is kind of difficult though.
Derric: There is a lot of tooling out there, and a lot of new API first or developer first companies coming about, that requires a very critical skill set right. Well, thank you very much Phil for joining us today on our podcast and looking forward to seeing what’s next over at Twilio and over at Signal.
Phil: Thank you very much.
Derric: Have a good one.
Make Your API Platform Successful With Moesif
14 day free trial. No credit card required.
Learn More
Related Articles
API Analytics and Monitoring
Introducing AI Explain
We are thrilled to introduce our newest feature to Moesif - AI Explain - a powerful conversational tool that lets you interact with your API analytics data l...
API Analytics and Monitoring
Monitoring Cost and Consumption of AI APIs and Apps
Discover how Moesif can help manage and optimize your AI-driven APIs with powerful observability tools that track costs and usage efficiently.
API Development
Unlock Deep API Insights with Moesif’s HTTP Body Analytics
Learn how to use Moesif to analyze HTTP bodies.
API Analytics and Monitoring
How Moesif API Observability Compares to Treblle
Learn how Moesif’s API observability platform compares to Treblle.