The democratization of APIs

Joyce Lin: Okay. So the title of this talk is democratization of APIs. My name is Joyce. I am a developer advocate at Postman. That's my dog, Lucy.

So a lot of us do are familiar with Postman. It's an API development platform. And for developer relations folks, you might use Postman to demo your own tech, share documentation for your APIs. Currently, there's over 11,000,000 developers using Postman today. So most of the metrics that I'll be showing are from the Postman community.

We'll be looking at self reported information during onboarding, anonymized usage, and we also survey the Postman community every year to see who is working on APIs and how they're doing their work. In this report, we cover hard hitting topics like how do you pronounce API. You can see the vast majority, 82%, do pronounce API API. But I think the 12% might be coming from Latin America, or I think folks in Western Europe might say Appy. So if you're going to one of the API conferences, they're like Appy Days or Appy Strat or Appy, like, conference.

So we have, also have deep academic research, like Star Wars versus Star Trek. I'm not sure if this is correct, but this is what the data shows. So the title of this talk is the democratization of APIs. And I actually hope I'm using that word right. The first thing I did when I was preparing for this talk was I googled what is democracy, and now Google thinks I'm stupid.

For this talk, what I mean is control by the common people. This is driven by growth in APIs, both on the production and consumption of APIs. It's driven by an increasingly diverse group of people doing both the consuming and producing, and also making APIs and all the surrounding tech more accessible to the masses. So let's start with growth of APIs. APIs, if you haven't known, they're kind of a big deal right now.

So Postman's founder and CEO, Abhinav Asana, said, every piece of software built today either uses an API or is an API. And I'm not sure if he said this publicly, but I've heard him say APIs are a decade defining technology. So APIs are continuing to grow because of primarily three shifts. We see a consumer shift like mobile, so there's more clients and platforms to support. There's an architectural shift, like with microservices, with organizations trying to scale more efficiently.

And you have an infrastructure shift moving from on prem to cloud. So cloud native, serverless, infrastructure as code, buzzword, buzzword. Any hot topic you can think of probably falls under one of these three trends. So all of this stuff is driving an exponential growth in APIs. So there's lots of APIs being consumed and produced.

Who works with APIs? Who are these people? So when Postman, people create Postman accounts, we ask for their job title, and this is what the breakdown looks like. You can see that the vast majority are actually back end developer, but the second biggest category is other. These are people who don't identify as any of these other categories.

So let's take some time to look at some of these other roles. It's not just people building APIs, but it's people testing them, setting up the infrastructure, and teaching other people how to use APIs. And, actually, if we look at this graph and compare it year over year, out of all the job functions, we actually see a 12% decrease in folks who do identify as developer. So it's not fewer developers because, overall, everyone's growing, but the rate of growth is slower than nondevs. So let's dig a little bit deeper into who is working with APIs by looking at one very specific group, one that works with API specifications.

So an API spec is like a blueprint for your API. Typically, it's, bigger organizations who are wrestling with a ton of APIs. And my hypothesis on who is working with API specs is that it's gonna be API architects or people who are responsible for designing the API. So let's see. Yes.

So most of the people who are working with API specs are developers, and I see architect. But you also see other folks getting involved here. You see ops, data science, QA tech writer. And all of this makes it makes sense, and it fits my hypothesis. My colleague, Ken Lane, told me that at one point, the people that were making one of the most popular API specification formats, the open API specification, they added YAML as a supported schema, before it was just JSON because they thought YAML would make it more inclusive to nondevs because those curly braces just throw everyone off.

So for most of us, we work for tech companies. We're developer relations. Most of us work for tech companies or companies with a large enough tech component that they're investing in developer relations. So a lot of us take APIs for granted until we talk with other industries who are undergoing digital transformation. And, yes, I said digital transformation unironically.

So you can see that most of us are in tech, but there's a bunch of other industries working with APIs. So Europe. Europe is, mandating open banking rules, so you see some pressure to towards APIs coming from regulations. Some folks in DevRel are helping an entire industry shift. One comes to mind.

Cisco is helping people shift from hardware defined networks to software defined networks. And I see huge, huge companies building out new API infrastructure side by side with their legacy infrastructure. So when you take a look at all of these industries in total and the people now working with APIs, how much experience do these people have? Like, what would you what would you guess hypothesize in your mind? Again, who are these people working with APIs?

Let's see. Okay. So this is not a surprise. You can see that there's a ton of new people moving into tech. So you see a u shaped distribution or, actually, it's c.

It's c. It's on-site. So most of the people working with APIs are five years and under. And then you see these ten plus years, experienced people probably mentoring these whippersnappers. With all these newcomers, we see the emergence of low code, no code tooling.

So what does that mean? I apologize. I'm sure there's many of you that work for low code, no code. This was just a quick slide off the top of my head. I could plaster this entire thing.

The growth in low code, no code tooling is phenomenal right now. So just some basic characteristics of low code, no code. There's typically a focus on the user interface. You might see some drag and drop, specialized workflows. And all this type of tooling is is a layer of abstraction over other tech that you would normally have to roll on your own.

So my colleague Sue Smith says, developers also use no code tools. So it's not a this or that. Developers do use both. So you can choose to roll your own, or you can use an out of the box thing so that you decide what to focus on. So it's not that no code is for nondevelopers, but it's a trend that makes tech more accessible to everyone, including people who don't identify as developer.

So in conclusion, I'm Ron Burgundy. I did intentionally put a question mark in there, and I apologize in advance. I'm about to end this talk on a real cliffhanger. So just a recap of what the democratization of APIs is. It's controlled by the common people.

You see exponential growth in APIs on the production and consumption side. You are dealing with an increasingly diverse population potentially not identifying as developer, and there's tooling and other efforts to make APIs more accessible to the masses. So DevRel is working with an increasingly diverse population. You might have certain personas that you're targeted to focus on. For many of us, we're educating, advocating, and building communities for those that aren't identifying as developer.

We see a rapidly growing group of people with minimal experience. They might be technical, but they have minimal experience with, say, APIs, and educating them with new tools that require an entirely different set of skills. So I have a question. At what point do we stop calling ourselves developer relations? And I already told you, I don't have an answer for you, and there shouldn't be a single answer.

Developer relations is a function that is notoriously, inconsistently implemented across all sorts of organizations. But I do come back to this wise quote that many of us have heard before. To the community, I represent the company. To the company, I represent the community, And I must have both of their interests in mind at all times. That's Mary Thingball, DevRel over at Camunda.

So Postman has a very big community, very diverse, and this is something that we're struggling with organizationally right now. We have a postman user conference, post con, and we intentionally called it a user conference and not a developer conference. We were alienating a large percentage of our user base by if we had called it developer conference. So how do you represent the community when a big part of it doesn't identify as developer? So, again, I don't have the answers, but some considerations.

Do you make them all developers? Do you educate the heck out of them? Do they even want to be developers? Is it the best thing for your company to make them all developers, or do you cater to every single persona that comes through your community? So I don't have an answer, but I would like to hear what you all have to say either in the dev relcon Slack group or you can find me on Twitter.

And if you're curious about some of this data hopefully, wasn't too much unicorn puke on there. If you're curious about some of these graphs, we do publish the state of the API annual report, and the 2021 is still open. So if you wanna lend your voice to the API state of the API address, then you can go ahead and hit that survey right there. Thank you for your time.