Democratizing API Management – Rakshith Rao, APIwiz

This is Textron TV. Hey guys. Thanks for the throw.

We're here with rockshith rail. Who is CEO for API with and we're talking about API life cycle management, which is something that most people seem to be overlooking these days. Hey rockshift welcome to shop.

Thank you. Thank you for having me today. So what do you think is the fundamental problem with API management?

Because we have more apis than ever most of them seem to be internally facing but it doesn't feel like we apply the same level of management principles and best practices to apis that we do to almost everything else. I think so part of the problem is like what you pointed out. We have a lot more than what we ever imagined with apis.

Look at the last decade in terms of the the growth of apis. What was once thought as helping build a mobile application is powering the entire business today and like you pointed out it's experience-based api's Partners based apis internal apis and the API sprawl is just growing and what we imagine about then doesn't seem to be working in today's landscape when it is even being multiplied with hybrid multi-cloud strategy that every organization is adopting. Do we need a dedicated team to manage these apis or is it just a function of working with the developers of crazy apis to manage them over the course of their life cycle?

So when when this started out quite some time back this was seen as a niche team that's focused on making sure that the apis the right way. They took care of trying to be the The Gatekeepers for the organization. And all the course of time with every organization scaling up their footprint.

This is becoming a challenge and now they're not able to get the same needs skill set which they needed earlier on and they're now grappling with trying to do a lot more as part of their business kpis. But in reality, they're still struggling to make sure that they get a proper release of an API into production that they can bet that it'll work the very first time. Which is where there's a major Gap in terms of the old process of having more people to solve this problem.

What won't work? So basically it doesn't scale unless we find some way to make it possible for the people who created the apis to manage the apis. But how do we kind of do that or shift the whole thing left in a way that they can absorb, right?

But that's why I guess the the local no-core nature of what we are seeing at least in the last couple of years helping really plug this Gap because it's essentially democratizing the whole life cycle process of making sure you design and build develop deploy and monitor them just the right way where folks are more inclined to focus towards the business logic and not worrying about. Hey, did we get the configuration right that we've put in the right certificate did it pass these set of test cases? Hey, by the way, we forgot we need to push it to this environment for externally apis as well.

So these kind of mundane tasks that we are seeing especially with the more and more apis and more versions and revisions getting released is not sustainable. So shift left our local whichever you want to call it is the only sustainable way to make sure that as we go beyond and full of few hundreds of apis thousands of apis to remain sane and make sure the business can run. It has to be done differently from what it was done fighting years ago.

Is the building and maintaining of those apis do I integrate that within a devops workflow or does that sit alongside my devops workflow? Good question that you buy brought up right see essentially if you look at what devops is all about. It's essentially creating more pipelines are embedding things as part of it.

So devops is making sure that you can call or invoke certain things and certain things happen. So what we have essentially done as part of API is and the nature of where the industries heading towards is meant to work within the devops construct. And what was initially thought devops predominantly focusing on packaging the right stuff and deploying slightly expanded to make sure that hey we can do testing along with that.

We can do release management and other pieces of the life cycle. So the the nature of the new way of doing things has to be automated and devops a is going to play a significant role and plugged into that. We hear a lot about API security these days is security really just an extension of management and we should think about the melding of those two things together, or are they separate motions as well?

Absolutely security cannot be a by-product or an afterthought or seen as a separate piece just as a nature of my background being in the API management spacefolded Florida decade. We've seen the the shifts in terms of how the API and API management constructs has been really seen as what was one scene as more of a Gateway functionality expanded to have analytics and development to simplify their option. Dan is when people start realizing that the trick Vector for an organization is not just having a firewall at the far end of the organization because it's a hybrid nature of how we all operate today.

So which means security cannot be seen and done like what it was initially plan. So a couple of things that we are seeing as a big shift my guess specifically security governance and compliance are certain pieces of things which cannot be seen as it's a function. It's a layer or it's a group of team that actually manages that the the approach that we start looking at was something that we went through it as an organization when we scaled up from a handful of apis to over 500 apis that we have today.

We started realizing that where is the data model for this? How do you make sure that the design is consistent with what we are releasing because security is not just making sure that we are acting as a firewall to put protect everything coming in and going out. It also needs to make sure that just like what we saw with Optus where an API was exposed naked which allowed people to completely hack and get all the necessary details.

So making sure that how do we not release an API? Are not even designed an API that is not meeting organizational set standards. And that's where we are seeing that some of these Natures has to be Blended in to the API cycle and it has to be every Point like a design stage at testing stage.

That's the breaking changes as early as possible in the life cycle. We also hear a lot about zombie apis. Is that a real problem or is that just some kind of cute name that people have out there that they go.

That's not really that big an issue. Where are we? Oh, it's definitely a big problem.

We recently spent some time with on some of the largest financial organization and the US and after having gone through a couple of months where we just took a snapshot of all of their services and apis that they're running within the organization. We were able to give them a complete automated report in terms of sure are your services managed and managed undocumented use the news without currently inboxing even if it means it has only two API calls a year or a month is completely clock login even realize that eight versions of a single API still running in production. He's a big problem.

So a lot of them are being done over the period of time. And especially in large organization the thought processes don't go break it unless it's not broken or somebody's asking you to fix it. So leave them as is go build an excretion.

So over a period of time what we fail to realize is you are now accumulating a lot of API dead which will come to Hunters back at some time. So some of these are called as zombie apis, which are how do you make sure that do they even exist who's actually using them to what extent should be sunset those apis. Is there a deprecation policy that we can actually enforce it's easy to put on paper but hard to enforce similar to Shadow apis at we are seeing where people don't even know that last projects get promoted to production or some apis are in production and no documentation even exist for those so some of the process that we have taken is autogenry the API document.

Station and catalog them if something is being can be attached to a Gateway or through process of the devops or some form factors through which you can actually get the data about what's being going out. We capture them and document them and even provide a catalog so that organization have bare-bone view of what their API landscape is if I have 40,000 Services. It's a reality check to make sure that do we really need those who is using them to what extent should we standardized them?

Should we collapse them why we having eight versions of those apis. So the business decision the technical decisions that people make will be Lord easier using this approach. Do you think the bad guys are getting better at catalog in the apis than the organizations are that created them because they're looking at that and scanning that and doing penetration testing and as a result, they're kind of, you know, using those apis to exfiltrate data in a way that frankly people don't realize how easy it is for them to do it.

Obviously, it's it's definitely the that up. What we feel is what we are doing as part of a large organization. We are focusing on putting a lot of thought process into building really cool Tech that's solving business problem customer experience and everything else and while we're doing all of this there are like people out there or making sure that they are using all forms a possible to make sure that they can get hold of things are fine ways to which they can actually breach the overall organizational perimeter and compromise data and get them out.

So one of the things that Mike we have been doing is something called as an API compliance. So which means it's a reality check of every API and every API traffic which is making sure that it's checking and making sure that are there in nature. I don't want to call it as any IML or anything asset.

But if you it's really using some level of Logix to make sure that there is a method to the madness in making sure that what's going out of organization or use within the organization. It doesn't mean they said standards either the standard needs to be upgraded or being compliant to those like for example, like thou shall not expose an API. That's not on https.

It's easy to say but how do you make sure that you can actually enforce this our it's easier when it's at like okay saying, okay incrypted. I'm gonna Crypt it on stuff like this. How do you make sure that it needs to be encrypted or using specific Fields only or making sure that there is a specific or token or a jwg token that needs to be passed or other forms of authentication authorization or even at the field level.

Is there a credit card information being exposed outside as the raw parameters within the request or response things like those very really want to catch them up front and we are talking this not in production. We're talking about this as early as in design phase and mapping them back into watching production. So you are having checks and balance in all places to make sure that while people outside are getting smarter organization using an automated approach is building intelligence that is helping them to make decisions in terms of are they heading down the right path?

Of course, most of the focus has been unrest apis, but there are Now graphql API. Oh, yeah are things getting more complicated both in terms of volume, but in types A apis that people are being asked to manage. Okay, you're absolutely right.

So what took time to standardize we where lot of organizations are mood and standardized towards using rest and Json as their as a core means of exchanging information. Obviously, we have come across a major shift towards specific use cases, which demand new ways in which people can actually access them like graphql like you pointed are websockets gRPC, even based model of exposing data. It's changing the way in which data is being exchanged.

So which means the way in which you're handling them or having the best practices needs to make sure that you are not putting cognitive or load on the team that's actually building managing and running that Why should the best practices radically change because you're using some new ways of exchanging data? Are the chicks that you enforce change radically because you're using a graphql. This is where a local panason approach price to abstract out some of the complexities that are being introduced because of the new nature of how data is being exchanged or format or protocols.

So that developers focus on making sure that they do things right rather than trying to focus on. Hey, let's go dedicate a new team that's gonna dedicate towards building all these new set of apis and graphql so you got two teams. So you've got two different best practices.

You've got two different ways in which it's being exposed out. So there is no common data model. For example, if I'm saying we are going to have an address field.

How do you make sure that the address field is consistent with rest and graphql? How do you make sure that is it camel case snake case or are you going to use different form factors? Those should be uniform across the organization irrespective of whether it is rest or graphql because data is a data that needs to be first looked at.

So what we are seeing is essentially a shift towards saying let's focus on the fundamentalists leave the part of the Gateway or the protocols to be done wait on through platforms. So that developers or security team analyst team testing team don't need to really change the way they worked they focus on best practices rather than on trying to learn new ways of how to do things. All right, folks, you heard it here all of it these days revolves around apis.

If you don't know how to manage or secure them bad things are gonna happen right? Thanks for being on the show. Thank you, Mike.

Thanks for having us. All right back to you guys in the studio.