API First and API Testing – DevOps Unbound EP 45

Hey everyone. Welcome to DevOps Unbound. I'm Alan Shimel, CEO and founder of, uh, tech Strong Group.

A DevOps Unbound is a, uh, semi-monthly, which means it's twice a month, I think, uh, video series that we've been doing that for about three years, and we explore every nook and cranny of the DevOps universe. Um, for three years we've been producing and putting on the show in partnership with our good friends at Tricentis, who I couldn't think of a better partner and a partner on this kind of thing, where if they, if you're not familiar with Tricentis worldwide leader in continuous testing and so much more today. Um, and as I said, we do these shows twice a month, and then maybe once a month or once every month and a half, we do what we call a live round table version of these shows where we invite you, our studio audience to come in and participate and kinda lead the discussion.

Unfortunately, this is not a live one. This, this is a prerecorded version that we did here at Techstrong Studios. But, um, you should pay attention.

Well, we'll, if you ever go to Techstrong TV and you can see the schedules of our live events of, of these, and we'd love to see you at the next live round table. We do, actually, Mitch, while I'm talking, maybe if you can grab a, a I'm a date and when I come to you, you can even, we'll do that with a little plugin. But, um, before we come to Mitch, though, besides thanking Chiantis, I want to introduce what this particular episode is about and introduce our panel.

Today's episode is API first and API testing. We're going to explore all things around API here. You know, API traffic represents the majority of the traffic on the internet.

I've seen numbers as high as 83%, which is the last one that came out of Akamai. Uh, I've seen Cloud flare. I think they had it around 70%.

So no matter whose statistic you go with, it's still a majority of the traffic on the internet. Um, we're gonna talk about, you know, API first development, and we are gonna talk about, um, API testing and, and more. Um, our Cracker Jack production team has already gotten me the date of for our next live round table.

And if you're interested in attending this market calendar's now, it's on July 24th at 11:00 AM and we're gonna be talking about adopting a DevOps culture for cloud migration success. Is there such a thing as cloud migration success? We'll talk about that July 24th.

Let's stick to APIs today. Um, for now though, let me introduce to you our, our panel. Um, first I wanna, well, he's a, a repeat meaning he's been here before with us.

I want to introduce you to Chris kli. I hope I pronounced that right, Chris, Chris, tell, tell our audience a little bit about yourself, if you don't mind. Thanks, Ellen.

Yeah, so I'm Chris Kmo. Um, for the last 12 years I've been working specifically in the API testing and service virtualization space. Um, joined the Tricentis team recently, kind of tasked with the responsibility of uplifting and modernizing some of the service virtualization, uh, tooling.

Um, and as a natural part of that, there's, uh, some API testing, uh, pieces of it. But I've been kind of enjoying that and having fun, imagining what this tooling could look like if we started from fresh. So happy to be here.

Uh, happy to have you on, Chris. Thanks, and welcome back. Next up the kind of queen of the ball here.

She, you know what? I, I just feel like she should move to Florida already. Um, our good friend Tracy Reagan, who's also a CEO of Deploy hub and many other things.

Tracy, why don't you introduce yourself? Well, Alan, thank you for having me here. I always enjoy this.

It's, I feel like I should have a PhD though on some of the topics that you bring me in on. Oh, what we do this About, uh, sometimes, sometimes I've kind of blown, I blow myself away. I understanding more than I realize.

I guess. I've been in this business for quite some time, to be quite honest. Um, I started at, as a programmer on Wall Street, started a company called Open Makes Software that automated builds.

And now I am the, um, CEO of Deploy hub, and we're doing an evidence store around security and DevOps data. I've been involved in the Eclipse Foundation, the open SSF, um, and the, the Continuous Delivery Foundation, and have embraced open source for quite some time and have some opinions on API first. And so I'm happy to talk about it.

Doesn't surprise me. You have some opinions. Tracy.

Thanks. And, and welcome. Our third panel member is Chris Lindsay, and this is Chris's first time.

I haven't yet told him of what first time guests have to do when they first come on here, but we'll, we'll tell him in a little bit. Hey, Chris. Welcome.

Introduce yourself to the audience, Alan. Thank you for having me. My name is Chris Lindsay.

I am an application security evangelist over at Mend. My job is just to talk about application security in general. My history, I wrote software for 35 years, so been there and done it in the trenches and APIs are near and dear to me, and I've been in security for over 15 and plus.

So thank you. Good. And welcome.

Always nice working with the folks at Men. Um, our last panel, well, he's not really a panel member, but our last person that I'm gonna introduce is my co-host for DevOps Unbound. He's our CPO here at techron.

He's also a CTA for Futurum Group, which is a company we are in the process of combining with. Mitchell can explain what the CTA role is, but let me introduce you to Mitchell. Ashley Mitchell.

Take it. Good to be here, Alan, and what a, what a group. Um, what a fantastic group.

Yeah, I'll, I'll be your panelists. I'll be your co-host. I'll be the the chat guy.

I'll be the bottled watch. Whatever you need me to be, Alan, I'll be So no. Just recently, as part of our, um, acquisition process with Futurum, my role's expanded in addition to the doing the analyst work that I was doing with Textron Research.

It's, uh, I have a new, you know, we had to create a new, new title, right? But I'm one of, uh, five people that are Chief Technology Advisors, which is kind of a, a glorified analyst on steroids doing advisory work and analyst work and, and things like that. So it's, it's a lot of fun that, that, uh, being part of the acquisition and, you know, still both, still working with all my old friends as well as new friends.

So it's good to be here with everybody. And yes, I started as a developer and yes, I've designed some really bad I APIs and a few good ones. So we have some lessons that, that I can bring Learned more on the, on the bad ones.

But anyway, um, thanks Mitch. And welcome. So, as I mentioned, API traffic today represents a clear majority, if not a critical mass of traffic on the internet.

And I'm gonna ask someone to explain what that means to the lay folks out there who may not, we don't have that many lay folks, but people who may not understand I'm not, it's, it's either API generated or API to API kind of thing, or, or, you know, somewhere along the line there's an API involvement there, that traffic. Um, but, you know, the effect that an API first mentality has had on the development process in general on testing and security in particular is, has been pretty profound, right? I remember the first time, like this whole thing became clear to me.

I had that eureka sort of moment. I was at a ca world, so I should, should give you an idea of how long ago this was. Um, and, and, uh, they had done an acquisition that company based in Texas, and the folks from that got up and said, you know, it's an API driven economy.

And I was like, wow, an API driven economy. What, what the heck does that mean? And I, you know, I I, I learned more and I, I dove in with it and I realized it was an API, you know, we were moving into an API driven economy when we talk about, you know, digital transformations and, and stuff like that.

And, you know, I think the next logical extension to that was API first, right? That's the default. And, and of following from that, of course, you, you, if you're gonna have that kind of API footprint, you damn well better be doing API testing, right?

To make sure this stuff works and make sure, and then in the last four, five years, API security has become paramount in many ways, right? API security is replacing web application firewalls and stuff like that because WAFs, that API traffic kind of flows under the radar of the wa, right? And so we need something else to kind of make sure our APIs are secure and locked down enough to make your head spin.

Um, Chris, see if it's okay, right? We'll say Chris C and Chris l Chris C why don't you take a crack at explaining in your mind what API first means when we, when we use it in this context. Absolutely.

And, you know, um, to get there, I think I wanna talk, I wanna touch a little bit on that API economy, because that's really like, first and foremost for me, what's driving the API first initiative and just, uh, unironically About an hour ago, I was just talking with ESRI. Um, they're the guys that do a lot of the map, the MAP APIs. Um, they were kind of behind MapQuest back in the day, and I was talking to the guy and he was saying that before that, way before that they were the ones that powered the Thomas guides.

You remember those things that were under your sheet? Sure. You were In your car, right?

Mm-Hmm. We were a logistics company, right? We, we, we, we had a database full of rich maps that we would then compile into a book.

And we were a logistics company. Let's ship them. And then eventually, at some point, that just went away.

And now they are an API first company. They sell their API to Google Maps and to Apple Maps. And so their entire economy is based around their map.

API mm-hmm. And so, uh, to me, that's what the API economy really means is, is it built. Businesses are building their brands.

And a lot of what's powering that is the API. And if that is the critical path to your business, you really have to have an API first mentality when it comes to building them, securing them, testing them, validating them, and really, most importantly, securing them. And so that's to me, what API first kind of means.

Jump panel on that jump go. If I can jump, I'm gonna jump in on that too. I love how you set it up, Christy.

Um, 'cause you think about it, historically, APIs were the things you might add for the exterior of your application or your software to kind of the ingress and egress. But everything inside of it was your app, right? And, and A-P-I-A-P-I first is just the opposite.

Your app is all run through APIs. Even if you don't have a gui, your ui use your interface. Um, and matter of fact, if you do have a U ui, the UI talks APIs to your app.

So the same APIs that you might share with, um, providers or people that are buying your service. Matter of fact, your service may be just the APIs like Chris is talking about. Um, and in doing that, I remember APIs just getting kind of unwieldy and getting outta control just 'cause we added them where we needed 'em here.

And how long are they gonna be good? And do, do, do we, as they evolved, how do we grandfather old versions of 'em? And now we have whole philosophies around the lifecycle A of APIs and how you manage them.

And they're, they think of, we think of APIs as the product because almost all, every app now is exposing those APIs either in a, in a microservices world, very heavily API or we're also to the external world, to people that are buying our products and services. So I, I hope that does justice to what you were talking about, Christy. And while you know that, um, there are, I mean, companies do rely on external APIs.

I, if I'm thinking about what our architecture looks like, we probably have 20% or 25, maybe 30% of external APIs. But most of what we do is internal APIs. And building internal APIs has a, you know, there is some, um, and when I think of API first, I think about what APIs do we need?

Let's think about what that looks like. And I like to refer to, uh, you know, I preach often this concept of domain driven design and understanding what are your domains? What APIs do you need?

What are the, you know, what are the, uh, what are the connection points? What does that need to look like before you ever start writing an application? But for the most part, we, you know, to, to be quite honest, this is not a new, uh, concept.

We tried to do this in, um, c plus plus and common libraries. A lot of companies, uh, when I was working for Discover Card, we did aton of work around initially defining what that com, those common libraries should be, should look like. And that's really what APIs are.

They're common libraries, what we can reuse. And really taking the time to understand what those high level domains are and what we need to create is super critical in building a, um, a true kind of API burst forward thinking model. And that's because if you don't do that, and if you don't manage them well, and you don't communicate and collaborate well, everybody's writes their own APIs that do the same thing.

Mm-Hmm. And that's what we don't there. And that's what generally happens.

And we've done, we've made this mistake as developers over and over and over. We constantly make this mistake, you know, everybody has their own login routine. Everybody has their own error routine processing.

Everybody has their own access to get the customer address. Um, so understanding domains and understanding how APIs should be structured within your organization and how you can break it out and allow ownership of certain domains is critical to an API API first, um, architecture. I agree.

I, yes. So, you know, the other thing I want to just tack onto it is, you know, what, what are your APIs doing? What, what's the purpose?

And in the old days, you would just write your software. You would be in a ui, you would be, you know, either, you know, web-based, where everything's all self-contained, and then you started pulling apart doing the APIs to now when you're developing software, you're thinking about it, there's multiple facets You have to think about, are you gonna expose any aspect of it for reporting or part, uh, you know, business to business or, uh, you know, are you gonna be consumed by other tools internally, um, for, for any reason? Or, you know, what's the UI gonna be?

The UI In today's world, when you're, when you're thinking of an application, if you're thinking of just web, you're, you're being very shortsighted. Do you wanna go web-based? Do you want to go mobile-based?

Or, you know, other technologies out there? And as, as Chris said, you know, talking about, you know, you may have an application that is nothing pure, but pure a, a, you know, APIs. And that's okay because it, again, it's, you know, just, it's all about the usage and what you're actually trying to accomplish.

Agreed. You know, when when I hear API first, to me, there's sort of a chicken and the egg question there, right? What comes before the API or is the API the first the chicken And no, it's not the chicken.

I think first before you, you don't start with the API first. You start with sort of plan of, Hey, I, I want an application that does this, that, or this and this, right? And then we think about, okay, how am I gonna go about doing that?

Right? So I, I think the, the planning and, you know, laying out storyboarding, if you will, or, uh, designing of the app is, is first. But certainly once we get into that design, we start thinking about APIs and potential APIs, I think before we start coding, certainly.

Would you agree that, that that is the essence of API first, right? Before we even start coding, we're thinking about how APIs are going to make or break, or how they're gonna work within the app that we're designing. Yeah.

Because that, that's how APIs are gonna pay for themselves. You know, me as a young developer, I would've loved to had, you know, been a, you know, we talk about feature teams now, you know, instead of application teams, you have feature teams. Well, me as a feature team working on a particular, what would be delivered as an application, I get to go talk to other teams that are doing features, which means I don't have to write all those queries.

I can figure out what they already have, if it's a well organized API structure, and everybody can share those APIs. So that pace is for itself. It's, you know, APIs can save a whole lot of cash when it comes to development because you're reusing objects.

So a hundred percent. And it's has to do with money too. Yeah.

Yeah. It, it does do that. If I could talk on that, what's just, just because the plan triggers me, right?

Is it immediately makes me go to the service definition, which I'm sure a lot of the season guys here are gonna roll their eyes, right? The service definition is not a plan, but a lot of organizations say, this is the beginning of the process, right? Let's, let's write our service definition.

Let's write our contracts, let's start putting in place the actual semantics of what this API is going to do. And what's interesting, if I kind of double click on what Tracy was saying about the domain, and specifically what Mitch was saying about sprawl, this creates a problem because you're not doing that upfront ideation work to say, what is the minimum set of APIs that we need in order to provide the value that will ultimately provide the money to our organization? And this leads to something which I'm seeing a ton right now, which is API and new API is the answer to everything, right?

Okay, we got this new functionality, let's just add another API, let's add another API. And before you know it, you have this massive API sprawl. And so I really do think coming back to the domain of, and the why and the, and, and, and the, the minimum set is super critical to this, to the planning phase before the service definition is even put in place.

So you're saying we can replace the phrase, there's an app for that to, there's an API for that. There's An a p for that. Yeah.

Yeah. Well, you know, and, and Chris, the thing that comes to mind when you were talking about that is solid programming principles, right? So, you know, when you create a class, you create a method.

The goal is, I've created it, I can add to it, but I cannot change it. And when you look at APIs, you know, you may run into, I need a little bit more or a little bit changed or a little bit something. 2, you know, and so on and so forth.

And then all of a sudden, you know, to to everybody's comment here, all of a sudden you may have started off with, you know, 150, 200 API endpoints, and now you're well over a thousand. Yeah, Absolutely. So I mean, it really, APIs, even though they save a lot, um, like microservices, it's complex.

'cause you're decoupling pieces. And when you decouple pieces, you cram, you know, it's your, your puzzle now is in, you don't have, you don't have the top of the box to look, tell you what that puzzle's supposed to be. And you have all these components, all these tiny puddles of pieces laying on the, you know, on the table.

And you gotta figure out what it is that you're creating so that you have This, the blast gradus gets really large Tracy, right? Yes, it does blast. Yes.

Here we go. Um, But that's an interesting, that's an interesting aspect too, right? And it becomes that yes, I have this giant inventory of APIs and I may want to Chris's point, sort of just add incremental functionality to it and, and change its version number.

But in a lot of cases, the APIs are used by disparate teams. And so they might not know, uh, the, the major difference between the UI and the, and the API is the UIs are designed to explicitly tell you what it's doing. You go to the screen, you get it, okay, I'm logging in, I'm creating an account.

APIs will do the same thing, but they're not explicit. And unless you love reading swagger definitions, you can't immediately know what an API is doing. And so that's where that, I think a part of that sprawl comes through is people go, Hey, I don't think this functionality exists.

It's like, well, actually yes it is. It's a subset of this other API that. And, and so I think this is one of the challenges that I think the contracts and service definitions, and definitely to trace, uh, to Tracy's point, the, the conversationing around what exactly are these APIs for becomes paramount to an organization's API's success.

Right? Well, and as an API matures, then what happens too, just like you were saying, you may have certain aspects of multiple pieces of APIs, Hey, to accomplish this task, I have to hit seven different APIs to get all the data. And one API may take forever to run, and I just need one aspect of its data.

However, a lot of it is actually tied to the same background or, you know, the backend. And so instead, maybe I just create a new endpoint to pull what I need. And the next thing you know, again, sprawl, And it's a collaboration that will prevent the sprawl.

Yes. You have to have the collaboration. You have to be, if you don't know an API exists.

And, and there's no way to find out. You're gonna write it yourself. 'cause you might go, this is gonna take me, oh, it'll take it, it'll take me 30 minutes to write it.

Even though that's not true. We do that as opposed to go hunt down somebody who's already written one. So the collaboration is essential just, um, across teams, much less really building out a collaborative API structure.

Couple things there. First of all, I think that was job one. Um, in the API security arms race, when API security started becoming a thing.

I think the first thing these API security solutions were doing was saying, you, it's 10 o'clock. Do you know what APIs you have? Right?

Because, you know, they, API sprawl give us so many APIs, APIs, talking APIs, talking APIs that most organizations really did not have a handle on what APIs were interacting in, in, and within their system or on their system. And let alone what their settings were, their security posture, et cetera. You can't defend what you don't even know is there Mm-Hmm.

And that, that was, you know, that was phase one of API security. I think it's expanded beyond that. It's matured.

But that was certainly the first, the first, you know, kind of thing about it. Um, the first part of, of, of API security, I wanna turn, you know, beyond the blast radius of API security of API first And talk about API testing, right? Because, you know, that's the logical next step.

Okay? So now we are going with an API first mentality. We're gonna have a APIs that, you know, in, in the right from the, from the design phase, we, we are designing APIs in.

But of course, these APIs need to be tested, don't they? Um, you hope. And so you have to get into API testing, but yet I, when I hear the phrase API testing, I still think of, oh, I'm using APIs to do my testing, right?

I, it, it, it sort of adds a layer of automation to my testing. But no, that's not really what I think we're talking about. Yeah.

I think most, Oh, go ahead. Oh, I'm sorry, chase. No, no.

I was just gonna say, I think when we talk about API testing from a developer's perspective, I think about functional testing and validation testing. I don't worry about performance testing or security testing or load balancing or any of those other pieces. And I assume somebody Automate that developer.

That's what We do. Right? I would've validate my endpoints.

I'm gonna do my functional testing if that's good. I'm going Actually that security testing. Yeah.

Um, Chris, Chris LI I'm hoping you have a different attitude towards it. I do. I'm sorry, Tracy.

It's okay. My attitude is, you know, it's, it's a view into your system. And as such, you need to do multiple things.

You know, I, I go to conferences, I see applications. I talk to people I, I with, with penetration testing software. I enjoy going out and attacking and breaking things.

I love seeing, you know, what kind of data I can get back. You know, some systems, you know, you can easily break simply because improper security, improper logging, and proper a lot of things. And so when, when you're looking at APIs from, you know, a, a a standpoint, there's multiple aspects that you have to consider.

You know, the, you know, how does it perform? Because I can come in and do a denial of service attack. If you have a poor performing, performing a PII can call it multiple times from thousands of endpoints simultaneously, if you have an API endpoint that shares data that it shouldn't be sharing, now I can steal data.

If you have an API endpoint that is just not well put together, it it, it's very obvious from a security standpoint. And so, whenever I was actually doing my, my development days and doing senior tech reviews, I would look at, you know, how do they perform? I would look at using tools to look at the payload as it goes in, as it comes out, what kind of things, time to run the time on the back end on, on the database, all the way down to that level just to ensure that, you know, is this performing?

Is it doing what it has? And then beyond that, you know, you also have the security things that you can throw in there, such as SQL injection and, and other various things that can, that can happen. I'll stop.

I can keep going, but No, I get Chris c you're the real tester here. What do you think? Okay, first off, I'm in the vendor space, right?

And so nobody knows less about testing than the actual testing vendors. But I will say this, um, I, I am encouraged that we're talking about development forward API testing. Because quite often in the testing industry, that's put firmly on qa.

And there's these really interesting conversations. Whenever we go to a, a first time API tester where they go, well, whose responsibility is it? Is it, is it the developer?

Is it the tester? Now we all know it's both, but it's at a spectrum. And the notion is that, hey, I'm a developer.

I created a service definition. I should be able to hand that to the, to the tester. They should be able to ingest that and use it.

And the tester says, Hey, you're a developer. You're building the API, you should test it before you give it to me. And there's this constant back and forth.

And I think to both Tracy and Chris's points, there's different levels of testing that you do as it's maturing through the cycle. And the, and the first one to me is contract testing, right? I want to make sure that my service that I'm building is not only complying to my business expectations that I've set forth, uh, for the, for the function of this API, but also that the consumers of IT are not going to be affected if I change it.

Right? And so, I don't know if anybody's really, um, uh, grasped onto, um, uh, uh, uh, contract testing quite like some companies like PACT have. But it's this, it's this really strong grassroots movement that's happening right now 'cause it's developer forward that basically says, I'm only gonna write into this test from a development coded perspective that are my expectations of an API.

That way I can continue to do what I'm doing and know that if the producer of the API makes a change, they're gonna run my contract and know that they've broken me, which fosters collaboration and communication. Those contracts are the seed for everything. Because you can mature those into greater and greater levels of more complicated functional and integration testing.

And then once you have all of those contracts, you have all the attack vectors that you need for your security testing. So I really think that this whole testing thing starts from the moment that first line of code is written against a contract, write the contract. But again, it's all predicated on whether the service definition exists.

Isn't, isn't also, 'cause I remember us using kind of contract with APIs in a little more general way before this, this moment you're talking about. And really a contract in that sense was here's how you use the API, here's the, here's the expected behavior in terms of how you interface with it, and here's the expected behaviors of what it's going to do when you use it in the specified ways. And I think to your point is if you go wacky and do some SQL ingestion or you do something else and pass different parameters that aren't part of the API, it's not gonna respond or it's gonna give you an error or some, some definition that's out, out of bounds of the contract, is that still consistent with the movement?

You're talking the developer forward? I, yes. The contract is, um, again, it's an overloaded term as are many things in our industry, but it, to me, the contract of the API is the service definition that defines semantically and logically what this API is supposed to do.

And you can use that both as a human document to read, to understand, but probably more handing it to the business to to, to the, uh, to the appliance so that it can ingest it and create clients to actually communicate with the API. Um, that same, that contract needs to be tested. Is it semantically valid?

Does it, does it follow all of the, the, the spec definitions that we have for service definitions as it changed recently, et cetera, et cetera. Um, and then that, that component is then used to test the function of the API in its entirety. This is a, this is a, a, a second piece to that, which is I'm using the API in a very specific way, and I have complied to the service definition.

I'm doing everything right. I wanna know if anything has changed, um, or if what I'm trying to do and what's critical to my business. I'm Bank of America, I'm communicating with the PayPal, API, I'm only using like three fields of it.

Don't change those three fields and do whatever you want with it. As long as you don't change those three fields, that if you do change those three fields, you gotta talk to me and say, I'm changing the three fields. What can we do about it?

What can we do about it? That's the, that's the difference between those two types of testing. And there's something that happens when APIs aren't really tested well.

Um, there is a trust factor that we have to always keep in mind if you're an API developer, uh, to make sure that you're doing that testing and that you're maintaining those contracts. Because what happens is, in that example that Chris just gave, that consumer may decide not to take on that new version of an API and that causes a DevOps nightmare called Drift, which means you have multiple versions of your API that are out in the world or being consumed internally by many different application teams that you have to support, maintain, and make sure are secure. So the API testing, if it is so critical in building that trust so you don't end up with so much drift, you know, we talked about sprawl, sprawls a problem, but drift is as big a problem, if not bigger, when it comes to trying to secure the, the, the environment, Right?

And then one of the things that I've seen is a lot of QA departments use automated, uh, regression tools, and their thought is, Hey, my, my tool passed a regression tested. That must mean the APIs are good. Let's move on and let's, let's, let's, you know, consider it good.

And to both Chris and, and Tracy, you know, their point is, look, the contracts possibly could change internally, something could get added, modified a a definition may change. 0, and now you're version 30 and you can't get off of it. And by default, most people who are writing APIs are not logging or doing any metrics.

And when you're not doing any metrics, you're not knowing what API endpoints are being used, how they're being used. You don't know the details. And so the problem becomes, you know, you're sitting there, you're creating drift sprawl, and, and you don't know that, hey, guess what?

Version one is still being used, but versions two through 15 aren't and haven't been for a given time. And so those could be deprecated. So instead at, at a certain point, depending on design and what's going on, you may have to go make 30, 40, 50 changes, you know, spread that same change out across all the API endpoints where if you were paying attention and, and doing good development practices, and, and, and analytics would tell you, Hey, you know, you have people that aren't moving off version one, why?

Ask the why, what's going on there? And then determine, you know, can, can they move up? Or is it just a breaking code change for them?

And if it is, you know, how do you deal with that? And, and how do you work with that? Because at a certain point you need to move forward.

So, but this, this is, this is a bigger problem. You're touching on Chris, right? Thi this is the, the sprawl aspect of it.

We see it cloud sprawl, API sprawl, you know, are all developers and IT people hoarders at their core, maybe because none of us seem to wanna delete anything. Me, I, I find a certain joy in like cleaning out my closet and throwing out things that, you know, I have a rule in the house. If it hasn't been used in the last year and a half, we're probably not going to use it.

There's better things to do with that space. Do we need to, and that's, by the way, that's something we could automate with APIs. And if that forces people to move off of version one to version five because they've been sleeping through the last four upgrades, or refuse to do it, so be it.

Right? Apple people used to knock Apple for that because they did it. They stopped with the backwards compatibility for five years old software.

If you didn't have the last version or two back with you, you couldn't run the latest stop. Mm-Hmm. You know, Microsoft stuck to that backwards compatibility thing for too long, in my opinion.

Should we, there's good API hygiene meaning adopt, something like that. Wow. That's a, a cultural shift.

Because I do think that, uh, developers tend to be a bit order orders as you explain. Yes. Mm-Hmm.

I mean, think about even, um, building a cont a container for an API, you probably gonna bring in stuff that you don't even need because you don't, you're not sure if there's a dependency on it. Um, which is part of the, our current security problems, um, is these transit of dependencies and what APIs calls what API, uh, becomes more of an issue. So it would be hard to get folks to start really cleaning house.

Like, and you think about SBUs, you, you mentioned SBUs, SBUs, I, I was not gonna say SBUs, but think, Well, no, we're not Thinking about SBUs. I, okay. But I do think that AI could help solve our blast radius.

Okay, blast radius. It is. So we're talking about blast radius.

So we could use AI to do that. We could use AI to limit the blast radius, but shouldn't we use AI to just limit API sprawl And drift? Yes.

And drift. I mean, it's good security, I think. Well, and AI is doing so many amazing things today.

You know, from a standpoint, when you're looking at using AI against your APIs, you know, it now creates a lot of, you know, background. It, it gives you a lot of visibility in the things that you didn't have before. It makes it so much easier to, you know, to connect, to get that information, to know what's happening behind the scenes, and to be able to detect anomalies.

You know, you may be up and running and, and AI can go, Hey, guess what? I'm noticing something interesting. Or, you know, if you are doing logging or whatever, AI can also pick, you know, pinpoint and go, Hey, wait a second.

Something's happening. Tracy, you know, she, she lives here. And somewhere on the other side of the globe, Tracy logged in again.

Problem. You know, I wanna bring up ball. Is there, there's also kind of some, we're talking about Some challenges with managing this whole ecosystem, right?

Of APIs. One of the things I think is really great about APIs, Tracy, you were talking about c plus plus remembering back in the day of, of stubbing, uh, stubbing off methods. You know, we would like, here's the structure and I don't have time to write that yet, so I'll just put a return in there and pass some data back.

And, and, and now we have such a better way of not just stubbing, but actually creating the API creating some logic behind it. We can have, you know, some tests actually built into that code that isn't fully been written there yet. Um, but maybe it's generating responses, right?

That we wanna to, uh, be able to test with as part of that API as well as we add the, the function, the service of what it is. And so you can, I think you can build software faster through this API first approach. Um, 'cause you're not managing a big structure, you know, a big object structure with parts stubbed out in some parts not.

And who's got what part of that tree? And I'm using this version of this microservice, this, this API, and it's, it's, it's just stuff there, it's great for building and testing and I'm gonna replace it with the, with, uh, Chris's, whichever Chris wrote it, Chris, CUL. And, uh, you know, I can continue to just evolve the app that way.

Agree. Don't agree. Am I, I agree doing funny stuff in Colorado, or I gotta, I gotta jump in here.

Like, one of the things I said at the beginning with my introduction was that I, I, I am over two products, right? API testing and service virtualization. I don't get to say this very often, but service virtualization doesn't get the love that it needs, um, in our space.

And I think that from an API first perspective, it is massively important for jump starting, you know, any API initiative. And to kind of wrap this into the sprawl and the drift thing, observability can be a huge benefit here, right? Because what, what we're finding when we're going to a lot of our companies is they're like, we want to do this.

We wanna go API first. We wanna test what we existing, what we currently have. We wanna understand what people are using, but we have no idea what APIs we have anymore, right?

Because everybody's kind of cycled out, et cetera. And, um, observability allows you to not only observe the system under motion to understand the actual APIs that are there. 'cause guess what?

A lot of those internal ones that, that Tracy was mentioning earlier, they're not documented. There's no service definition for them. And the observability is the only way you're gonna pick up on those.

And that same traffic can be used to generate those initial service tests, those initial vir virtual service, which is so much more valuable. 'cause it's not just a dumb stub. It's one that actually simulates the business logic and the, and, and, and, and the expectations of the system under motion.

And then you use, and you kind of build your new API scaffolding around that. And it's a great way to get started is leverage your existing observability for service test and service virtualization creation. I love that term.

Your service under motion. It's a great visual Service in motion, Under motion service. It's in motion.

Yes. No, no, it's under motion. It's great.

She's running Something, an 80 song. Anyway, it makes sense, right? Yeah, Yeah.

It does. It does. There's another part to this too, and that is the API security.

API sec, uh, part of security is one of the first things that the API discovery. So if things are going through a proxy or something that's, you know, flow flowing through, um, whether you call it firewall, a proxy, whatever it might be, that's another collection point, if you will. Like you're talking about Chrissy, where okay, what is that?

You know, there's 25 things that happened today. Nobody knows what that thing is or didn't know somebody else was using that way. We didn't know that was going externally.

So that's another kind of data point you can pull into figuring out what's Happening. Well, I had mentioned that earlier. You can't defend what you don't know.

You most people don't know what APIs you have. Well, and, and from the sbo I'm saying from the SBO piece of it, you don't know what dependencies that API is calling into play here. Chris, Chris l you've got something to say.

Go ahead. Yes. Yes.

So, you know, when, when you're looking at the APIs and, and the data coming in, it's just like a ui. You have no idea what kind of crap people are gonna throw at it, what length of information people are gonna throw at it. What kind of information is, is inbound outbound?

Because, you know, crafting a good attack, you know, you, you can do things and, and, and skirt under the radar depending on design. And, and I love the, you know, what, what Mitch was saying, you know, the very first thing, if I'm gonna come attack you guys and look at what's going on, you know, I'm gonna figure out what API endpoints you have, I'm gonna figure out what's going on there, and then I'm gonna start, you know, overloading 'em, seeing what I can come up with. And it's, it's amazing how many people overlook the role-based access.

You know, if you get a JWT token, you get in the door, guess what? Now I can do a lot of things that I shouldn't be able to. Fair enough.

Guys, we, we try to keep these sessions to 40, 45 minutes, and I think we're up against the clock here. Um, first of all, great conversation, great conversation. I, I think look for our audience at home.

Takeaways three, three things. I always like lean these kinds of things, or three key takeaways. Number one, we absolutely do live in an API economy, right?

APIs are driving the internet, it seems, if we look at traffic loads, number two, an API first mindset in, in how we plan and, and develop our applications is, I think the norm, not the exception to that, right? Do we all agree with that? And the third thing is, if all of these APIs are out there, you're not doing API testing.

And that includes API security testing stink. You know, the, the, the, the, what's it, what comes home to roost? Mitchell Chickens can hoan drew the chickens, come home to roost?

I knew it was some foul. That's the Nebraska boy come, that's the Nebraska boy right there. And of course, it expands, expands your blast radius.

Um, I realize we gave nobody any context at the beginning as to why we are doing that. And I love it. We have a very, very sharp audience.

They picked up right away on it, but it's not the first time they played this drinking game. Um, anyway, Chris and Chris, thank you so much for being our guest today on, uh, DevOps Unbound. Tracy is, as always, it's a pleasure to have you on here.

Love having you part of, you know, not just DevOps Unbound, but you're under, you're one of the gang members. I'm Textron Gang and, and of course, uh, tech strong women and everything else you guys do. So thank you.

Thank you, Mitch. As always, you take the last word. Um, I just party thought is there's an API for that.

I said, fair, fair enough. No doubt. Hey, many thanks to T Tricentis, as I said in the beginning of the show for sponsoring this.

They're a great company to work with. com. Until next time, this is Alan Shimmel for Techstrong.

Quick reminder, July 24th is our next live round table. Don't miss it. But until then or until our next show here, we're out.

Thank you. Bye-Bye.