Joyce Lin, Postman | DevOps World 2023

This is Techron tv. Hey everybody. Welcome back to DevOps World 2023 here in Silicon Valley, San to Clara.

We have another great interview, um, another speaker from I think one of our sessions this afternoon and I'm have a great pleasure already. Great interesting conversation that we've had before we got started with, uh, Joyce Lynn. Welcome.

Hi. Senior Director of Developer Relations with Postman. Yes, thank you.

It's great to be here. Excellent. It's awesome to have you.

I've already learned so much. Um, so I know you have like millions of users, but there's new people all the time, like may not know what Postman is. Give us a quick definition of what It's, I'm actually excited to be here 'cause I usually go to developer conferences and speaking with DevOps platform people is not my wheelhouse.

So Postman is an API platform, even though it has the word platform in it. It's, a lot of people think of it as a dev tool or an APAC client, but it's AAPI platform used by over 25 million developers, testers, anybody who uses APIs. So especially in the US us like we have pretty good awareness.

Mm-Hmm. Yeah. Very cool.

So if you're like, designing APIs using APIs, Exactly. Like, so a lot of people use it like an API client, but the entire API lifecycle, if you're deploying and observing, publishing, creating documentation, all of that, You don't have to figure that out yourself. Yeah, Right.

Exactly. You got it Up. Yeah.

Good, good. Okay. So we're, we're talking about, you know, platform engineering's very hot topic.

It, it's interesting 'cause it's legitimized so fast a role which tells you there's been a real need and I think a lot of it is timing. Um, I'd love to hear your thoughts about sort of API adoption, what's happening with the people that you work with. How's the conversation changed since you started with Postman a few years back to what's happening now?

Yeah, I mean, so I've been with Postman almost seven years and I mean, I like to say that tax changes pretty fast. So in the early days, again, I was talking in with a really niche use case, right? API client.

And now I've been talking to people along the entire API lifecycle and people are actually starting to think of APIs as having a lifecycle. Mm-Hmm. So in the early days, it was something that you tacked on top of a larger system.

And now, um, I give a lot of talks about API first, the idea that you needed to design and develop API first before any other functionality. Right? And so you're thinking about the design, the potential impacts, and, um, that ends up getting you, it's a very similar to concept to, um, agile versus waterfall.

Mm-Hmm. Yeah, it's a good analogy because APIs used to be sort of the few use cases that where there was ingress or egress in and out of some larger SOA monolithic application. Now it's, it's how the application works with itself, right.

API first as well as internal externally. Yeah. Sometimes it's not even clear whether it's internal or External.

And if you think about, oh, there's a quote I'm gonna get wrong, but is it like form follows function or function follows form, it's one of those Mm-Hmm. But if you think about the actual form that is gonna drive the function, right? I think that's what it is.

But like, um, if you have this much to expose to somebody, really focus on this because this is gonna drive a lot of what happens, um, later on. Well, and since you're in the lifecycle part of this phase, if you haven't been doing it for a while, like how do you grandfather kinda use that old term, right? Do you grandfather API sunset em, do you, are you ma uh, maintaining the ability, um, across versions?

How do you do versions of APIs? Yeah. How do you, was there a time where you stop supporting some variation of it?

Yeah. Or how do you make 'em more resilient so you don't have to sunset APIs? I do talk about, um, API first a lot of times and it's the easiest to do when you're starting with a blank slate.

Yeah. But seldom do people walk into that situation. They always have like a ton of APIs.

And the dirty little secret is most organizations, most large organizations don't have good visibility about, um, that API scope creep. There's stuff running that people don't know about. Yeah.

Um, and so there's little hacks to get it, getting that visibility, like sniffing the traffic, proxying the traffic so that you can identify like, okay, what all is running on my infrastructure? Mm-Hmm. But it's, um, it, the reason why a lot of us have jobs here today is because organizations struggle with it.

Right? Well, it is very evolutionary, right. If you aren't doing API first or think about APIs in which you're gonna publish what's gonna be visible, it, it's, it's a, uh, n necessity, you know?

Yeah. Mother invention kind of thing where, okay, let's add these APIs to do this now. Oh, we need to provide this information to customers.

All right, here's another set of APIs soon hundred, soon you have hundreds if not thousands of different APIs nobody either knows about, planned about, or Yeah. How do you manage those, Right? Yeah.

And so part of my talk is about, um, you know, platform engineering and how you can impact, uh, developer happiness and a lot of developer happiness is spending time, um, working on things that you feel like don't matter or you're just, um, that don't matter or they're just going into the ether, right? Mm-Hmm. So if I already created something, why should my colleague have to create the exact same thing?

And if something as simple as creating like visibility for all of your microservices, all of your websites, all of your whatever, is, um, a huge part of, um, what, like, I think, um, I'm gonna be talking about Spotify engineering talks about it. Have you heard of Backstage? Mm-Hmm.

Yeah. Backstage internal developer portal where, so basic, having visibility of stuff going on in your org is, is the biggest challenge. So when, when you're talking about platform engineering, and there's a lot of elements to it, right?

Yeah. Which is actually one of, I think the great things about, it's kind of Swiss Army United, if you need this, that's part of it. And one of them is IDPs or developer platforms, um, whatever you might call those.

Um, is, is that your focus of how do you deliver kind of API management support lifecycle, et cetera, through a developer kind of portal? In a sense? Yes.

And I think, um, IDP is something that people jump to and that's what they're looking for. Um, there's a new term called API platform, which, um, I think is relatively new. Gartner recently has been talking about that as, um, API platform operator.

A new kind of role where you're expected to pull all the platforms together. Hmm. Yeah.

What do you think of that idea? Sometimes analysts make up categories to sell more analyst reports. I wonder what I Can say that I might the analyst business.

Yeah, it happens. But I mean, what do you, what do you think about kind of identifying it that way? Does that make sense to you?

It does, based on the conversations I'm having with other organizations, but I think people throw the word platform around a lot. Mm-Hmm. Um, and just to your earlier question, like what is platform engineering, right?

Are you a platform engineer if you do infrastructure? Um, are, are you a platform engineer? If you work on something that cuts across all teams, um, you know, everyone can have their own definition.

Yeah. I, I think that's, I think that's part of, I think the timing was great for platform engineering too, because of economic conditions. You all of a sudden heard about developer productivity.

Okay, well how do I make that better if, you know, engineering managers are like, I'm not sure what to do. And the focus on the developer with platform engineering, I think was perfect timing to Abbott adopted. And I do think it's like a little bit pendulum swinging one way and pendulum swinging the other.

When I first got started in tech a long time ago, it, I mean, we talked about like agile, right? And we, you've probably talked to people about shifting left Mm-Hmm. And it's like, just shift this left shift, this left.

And eventually, um, without standardization, without like having, uh, starting points for people, you're shifting everything onto the developer. And that's not, that's the anti-pattern that comes about with embedded ops. Yeah.

Yeah. I think that's the, the fallacy of shift left. And it's like, it's really about moving things earlier in the life cycle, not giving everything to the developer.

I mean, they don't want to do compliance work. They want to co-create compliant software. But Yeah.

And that's what I think about sometimes when I'm telling people about API first, API first, oh, just design the API first developer or architect. And, um, a lot of developers think it's a good idea intellectually, but then they struggle when it comes to actually executing. How do you do it?

They talk about like cognitive load and like, like I can add this part, I can add these endpoints later. I don't wanna think about it holistically right from the beginning. And, and if you are starting from scratch, then yes, it can be very overwhelming.

Mm-Hmm. But it's also taking concept to, to reality, like microservices, okay, what's an atomic unit of work? How much do you do in a microservice?

There's no one way to do that. And you kind of have to learn like, this works. This is, and different situations might do different things, but it doesn't come with the, the manual of how to do API first.

Right? It is, and it, it's, it takes constant evaluation. Like at Postman Engineering, we've had microservices.

We're like a baby shop. We're like, our total head count's 700. So baby compared to some of these other organizations here today.

But, um, we've definitely had microservices and then realize, okay, now this is just becoming like a distributed monolith. Mm-Hmm. Yeah.

And then singing in back the other way. Yeah. The other way.

So, um, crystal ball question, which means you can't be wrong 'cause nobody can be. Right. Okay.

Excellent. Yes. And know they're right.

Um, where do you think we're going with APIs? What's, what's next beyond API first and API lifecycle management, API lifecycle. So you're asking what's next?

Some people are just now thinking about that. So, um, not to say like, oh, there's something else coming. Not looking for insider product information.

Not, not that, but No, no, I get it. But like, there's some people that are just starting to think about these issues and so the idea of what's the next beyond that can be a little much. Um, but I did see there was a talk today about, uh, AI and AI's role in DevOps.

And so I work with developers, dev tools and productivity. I personally consume a lot of, um, software that has been sneaking little pieces in there. And I have to say, uh, it's not an original thought, but like, um, generative ai, like if your team is not currently looking at how to roll that into your developer experience, your business offering, like, I, I feel like everyone has a slot team on this right now.

Well, and it's so easy. I mean, you copilot and coist and you know, a lot of, a lot of paths to that with Microsoft and GitHub and, and others. Yeah.

There are others besides us That are all enabled by API. They, yes. Yeah.

Yeah. That's how they plug into the ID Right. Exactly.

Yeah. Yeah. I mean, it's all this ecosystem, you know, working for you.

Sometimes that can get a little crazy. Yeah, yeah, yeah. We always like, okay, when do the plugins overtake the main app?

Sometimes that happens. Whole debate about, um, Jenkins and that and all the plugins really. Okay.

Okay. It's kind of an interesting topic. Well, it's been fascinating talking with you.

Yeah. I love talking about this. Pleasure.

Thank you. Yeah. Well, welcome again to, uh, to being with us with uh, DevOps world and, uh, we are glad that you're on this journey here with us.