APIs Over IPAs 18: Platform Engineering and Reducing Operational Overhead with Nuwan Dias, WSO2
In this episode, Nuwan Dias, Vice President and Deputy CTO at WSO2, joins to explore what effective API lifecycle management really looks like. Drawing on his deep experience building API platforms, Nuwan outlines the key pillars of successful API programs—from strategy and governance to security, testing, and deployment. He shares how organizations can operationalize API-first thinking at scale, and the role of dedicated API teams in enabling this shift.
The conversation unpacks the importance of treating APIs as products, establishing centralized governance, and driving consistency across internal and external developer experiences. Nuwan also weighs in on the relationship between platform engineering and API management, offering a pragmatic view on where they intersect and diverge. Whether you’re defining your API strategy or scaling existing programs, this episode delivers practical guidance for aligning teams, tools, and processes around a unified API vision.
Listen to the episode on SoundCloud, Apple Podcasts, YouTube Music, or wherever you listen to podcasts. You can also watch the video on our YouTube Channel.
Table of Contents
- Foundations of API Lifecycle Management
- Platform Engineering and Developer Enablement
- Challenges of Platform Engineering at Scale
- Aligning Platform and Product Teams
- AI's Role in Platform Engineering and API Development
Foundations of API Lifecycle Management
Derric: Hi folks, welcome to another episode of IPAs and APIs with Moesif. Joining us today is Nuwan Dias, Deputy CTO over at DEVSA2. Very timely, we’re talking about today how to think about platform engineering and reduce your operational overhead. Nuwan, really happy to have you here today.
Nuwan: Thank you for having me, Derric, and it’s a pleasure to be here as well.
Derric: Awesome. Just kicking things off, we’d love to hear a little bit more around what is API lifecycle management and, you know, the high-level process to ship an API.
Nuwan: Oh, well, so I think, so like lifecycle management for an API is, you know, just like lifecycle management for a product. It’s basically a process of product management. You know, it starts with identifying the requirements of your customers. It starts with, you know, understanding what they really want and what kind of experiences they want. It starts with capturing those and documenting them properly. And then, of course, it has a process of developing the first version of it. And then beyond that, you, okay, of course, go through your engineering process, put it into, you know, production, give it to the hands of your customers. And then you have to think of things like discoverability, you know, ease of consumption, you know, the documentation, all that stuff, and then you put it into production. And, of course, then you keep monitoring it, right? So you keep looking at how are people using this, what are the issues they are facing. At the same time, you keep capturing the new requirements, and then you go through an iteration process, right? You capture your feedback, your issues, you plan out the next version, you know, think of a migration. So I think, I mean, to sum it up, API lifecycle is nothing but just another act of, you know, product management, just for your APIs.
Derric: Yeah, definitely taking that feedback, you know, making sure we’re listening to customers and looking at our data to improve those products and ship new versions of APIs. But, you know, as someone was thinking about scaling out their API program, what makes API lifecycle so important these days?
Nuwan: Well, so it’s APIs, you know, aren’t just code, right? So they are a product by itself, right? So just like any good product, your API needs to be treated like a well-designed, reliable, and, you know, something that’s able to evolve, right? So think of an organization creating one API, or their first API, right? So, you know, you create your first API, put it up into production, okay, all’s good, nothing’s wrong. You know, if you create your second one, okay, everything’s good. Now, imagine you have 25, 30, 50 APIs in production, right? So if you don’t have proper lifecycle management, now this is going to be a mess the moment you process, let’s say, like 15, 20 APIs, right? So if you don’t have proper lifecycle management, your APIs will have no standard, you know, no consistency. So their consumption experiences will differ from API to API, and that becomes a mess for people, you know, trying to consume the APIs of your organization. And, you know, you’ll not have a standard way of capturing how your API is performing, you know, it will all be done in different, different ways. So I think this is why lifecycle management is critically important, right? Because if you don’t treat your APIs as a product, if you don’t, you know, standardize things, if you don’t monitor things consistently, the moment you go beyond, let’s say, 10, 15 APIs, then, you know, things start falling apart, it becomes a mess. So that’s why I think it’s very, very important to think of it from day one itself.
Derric: Definitely, having that consistency across the different products, so super easy for new developers and customers to get up and running with APIs.
Platform Engineering and Developer Enablement
Derric: We’ve also heard this term platform engineering. What is the goal of platform engineering, and how is this helping with development, delivery of all these API products?
Nuwan: Yeah, so if you, you know, broadly look at platform engineering, platform engineering was bought in, it’s basically the evolution of, you know, DevOps, as I would, you know, like to put it. So the whole idea behind platform engineering is to make things faster, you know, make things more reliable, make things more consistent, and so on, right? So that’s the whole process of platform engineering. Now, when it comes to the context of APIs, right, so, you know, think of it, think of delivering APIs. APIs without a platform engineering process, right? So you’d have to write your code for your API, you’d have to host it, and now to expose this, you’d have to think of an API gateway, right? You’d have to install it, and then you’ll need to figure out, okay, how do I get my APIs contract onto my gateway? You’d have to think of making this discoverable, and so on. So it’s a, you know, it’s a whole lot of tools and processes to expose your API without a process of platform engineering. Now, platform engineering is all about making that entire process, you know, automated and consistent. So that means, as a developer, your focus is basically on your API, on the logic and the code of your API. The platform engineering process, or the platform, which is the outcome of the platform engineering process, should basically do all those things for you, right? So you should no longer be thinking about API gateways, you should no longer be thinking about how do I get my contract onto the gateways, how do I scale my gateways, you know, what do I have to do for the discovery part of the API? So all of that will be taken care of by the platform in engineering process and the platform eventually, right? So that’s why, you know, platform engineering exists, and that’s the whole goal of it, right? So this way you deliver things faster, and of course, it becomes consistent so that everyone building APIs goes through the same pipeline.
Derric: I like that. So trying to take away a lot of the infrastructure and just make it easier for teams to be shipping their APIs. But, you know, if we start moving everything into platform engineering, how do you balance autonomy so that developers can still innovate and ship, you know, different APIs and test new things while trying to reduce and ensure that standardization is in place?
Nuwan: Yeah, I mean, yeah, that’s a tricky one, because on one hand, you want, you know, you want standardization and everything to be consistent, everything to be reviewed and authorized and so on. And then on the other hand, you want to give full autonomy to your developers so that they can basically keep doing, you know, what they do best. So it’s a challenge, but I think that the trick here is in moving to a more of an enablement mindset or rather shifting to an enablement mindset from an enforcement mindset. So instead of, you know, instead of giving them rules to follow, documents to read, best practices, guidelines to read and learn and do stuff, you know, the platform should enable them to do it by default, right? So this means templates of APIs so that you can get, you know, easily started and so on, right? So basically what I’m trying to say is you build the platform in such a way where the easiest thing to do or the easiest way to build your API is also the best way to do it, right? So your platform makes sure that the easiest way to build an API is also the best way to do it, right? So these are also called golden paths, right, in our platform. So I think that’s the trick to it, you know, instead of putting boulders and, you know, trying to block developers, you enable them to do things the right way through the platform.
Derric: I like that, enabling developers versus trying to add too many blocks and everything else. It’s always, you know, just like in SAS, where we get the shadow IT model and people start doing their own things and, or they can’t do anything, right?
Nuwan: Exactly.
Challenges of Platform Engineering at Scale
Derric: But, you know, there’s some challenges to platform engineering as well. So, you know, what do you see as a platform team, some of the challenges in maintaining all this infrastructure and, you know, some of the operational overhead that we see with a platform engineering model?
Nuwan: Yeah, so I think one of the key challenges is building this, you know, platform as a product, getting into the platform as a product mindset is one of the key challenges. Because what I’ve seen at least is, I mean, many organizations, so there’s the development team, and then there is the platform engineering team. So, so the platform engineering team builds a platform to make their life easy. So the platform engineering team’s life’s easy. So what that means is developers, when they want something, they create a ticket, the platform engineering team picks it up, and then they use the platform to execute it, right? So they build this tool for their ease, and they don’t give a lot of empathy to the actual developers who want things done fast, right? So this is one of the key challenges, I think. So I think to address that, you should get into this platform as a product mindset. They should understand that this is a product that they are building, and their customers are the developers. So you need to have empathy on your customers, listen to their pain points, you know, identifying where they are getting blocked or slowed down, and really, you know, think of your developers, right? So that, you know, they can do stuff better.
And also, I think over-engineering is also one of the challenges, because this whole platform has really a lot of things to do, you know, all the way from CI to CD. To security, to security, to security, observability. So it’s a challenge to figure out one process that works for everything sometimes, and therefore, this ends up in a situation where you over-engineer stuff, and that sometimes leads to shadow ops, right? So when developers find it hard to troubleshoot things, so someone puts up a platform where, when there’s an issue, developers have to go to one tool to look at the deployment logs, they have to go to another tool to look at the application logs, they have to go to a different tool to look at the access logs, and so on, right? So it becomes very painful, and because this has been over-engineered, and so what happens there is developers basically try to bring in their own tools behind, you know, behind the hood, right? Behind the scenes. So that’s another challenge.
And resource management is also, I think, another challenge, you know, especially when you’re running stuff on the cloud. It tends to get pretty expensive, pretty fast, so that is another challenge, I guess. And also, you know, adoption, right? Adoption is also a challenge, so you build stuff, but of course, now you need to get your users to use it, right? So that’s, again, going back to that platform as a product mindset where, you know, you need to be evangelizing and so on to get people to use it. So, yeah, I guess these are some of the challenges that I’ve seen.
Derric: Definitely treating your platform as a product and listening to the customers, which is the development teams, you know, what do they care about? And at the same time, you know, really like this notion of make sure you don’t have too many different tools to choose from, right? Because that’s just creating operational overhead.
Nuwan: Yeah, too many tools, yeah.
Derric: What are some tools that you can create to help create that more productive developer experience for these various teams?
Nuwan: Yeah. Yeah, so, I mean, to be honest, there are too many tools in the market.
Derric: Indeed.
Nuwan: So, there are, like, take a single aspect. So, if you take CI, there are so many choices to pick from. If you take CD, there are so many choices to pick from. So, I think the problem is not that we are lacking any tools. We have all the tools we need. The challenge is creating an integrated experience with all of that, right? So, like I said, the platform engineering teams, most often, they build the platform for themselves to make their life easy, actually, right? Not the developer’s life easy. And therefore, they just pick a bunch of tools and give it to the developers and say, okay, fine, here’s your platform. Everything’s in place. All the features are done. You have CI, you have CD, you have, you know, API gateway, you have observability and logs and tracing and metrics. You have all of it, right?
But the reality is, you know, it’s just very hard to navigate through all of this. So, I think the trick is not that there are not enough tools. I think there are too many tools to pick from. The key challenge is in how do you create, like, a single interface, a unified experience, and create the platform in such a way that developers love to use it, right? So, I think that’s the challenge that many organizations are facing.
Derric: So, thinking more about the experience than just shipping a bunch of tools over the fence, right?
Nuwan: Yeah.
Derric: How do you take your approach to the shift left around API monitoring, testing, trying to empower developers without, I guess, just giving them a bunch of tools at the same time? So, I guess it sounds like, is that somehow incorporating the experience and what are the best approaches there?
Nuwan: So, again, I think it’s a matter of, you know, productizing those tools. The, the, the, the, so, you know, there are individual tools in the market that address different, different problems. So, instead of saying, you know, go to this tool to, to do your job, what you have to do is, again, this is, again, going back to the platform as a product mindset. So, instead of throwing in a tool, I think the platform engineering team has to use that tool and build an experience on top of it, right? So, use it in the, in the backend.
So, this is something that we are doing in WSO2, right? So, we do, we do, we also use a lot of tools, but our developers, they don’t get direct exposure to those tools. Those tools are in the background. So, what we do is we, we do a lot of integration work across these different tools and we give a, a, a unified interface, like one interface for developers to work with. So, they don’t have to move away from that UI for doing their stuff, but when they are navigating through that UI, they are crossing a lot of tools in the process, right? So, they’re actually getting stuff from different, different tools, but they don’t leave that single interface. They’re always in that one interface, right? So, so, I think that, that’s the key, you know, you can, it’s okay to use the tools in the background, but you have to do a lot of work in the front end to unify it and create one, you know, one experience across everything.
Derric: So, it sounds like making the platform invisible almost to the typical development workflow of these, these APIs.
Nuwan: Exactly.
Derric: Yeah, I think you, you, you hit the nail on the head. It’s basically about making the platform invisible.
Aligning Platform and Product Teams
Derric: Now, speaking on API productization, we’ve heard that term around as well. For these different product teams, how do you actually enable consumption of these APIs and, and what is the different process there for, you’re shipping an API product, speaking more for the product team itself?
Nuwan: Yeah. So, I think, again, this, this goes back to, at the root of it, I think this goes back to treating your API as a product. So, if you were selling a product, right, what would you do? You would, you would first have a lot of empathy towards its consumers, you know, you would listen to them. So, so, you know, your tool is going to be useful and used by the consumers. So, a lot of customer empathy has to go in. And then, you know, you also bring in your, your marketing team to make sure the world knows about it. So, that’s how we, you would treat a, a product.
So, you have to apply the same thing to your API as well. You need to do a lot of evangelizing, whether it could be inside the organization, outside the organization, on your API. And also, you have to make it easy to use, right? So, that’s what we would do when we were, if we were building a product, for example, we’d make it as easy to use as possible, right? We’d go to great lengths to simplify the user experience. So, the same thing has to apply to your APIs, right? You need to make it easy to find, which means you need like a nice developer portal kind of a thing. You need to have good documentation, SDKs, basically make it as easy to use as you can, right?
So, so that’s that. And then, you need to have some feedback, some mechanism for, for gathering feedback, so that you can, you know, improve your, the experience that you give to your consumers, listen to their requirements, and come up with new features and new versions and so on. So, so I think, yeah, so, so these are, these are some of the things that I can think of, but, but at the root of it, I think the way we think of an API and the way we think of a product that we put out on the internet to use as a SaaS or download and use, they have to be the same. So, the process you follow for your product should be the same process you follow for your APIs as well. And depending on your consumer, you have to do whatever is right to, you know, to make it super easy to use and valuable.
Derric: So, it really sounds like there’s multiple abstraction layers with these APIs. You have the platform team, which is trying to treat the platform as a product and listen to their customers. But at the same time, you got these product teams that are trying to treat their APIs as products, listen to their customers. I guess we’re really decoupling the product team from the platform team in a way. So, well, I guess, what does that mean? What does the future look like around, you know, these product and platform teams?
Nuwan: Oh, so, so I think they should be very close together, right? So, the product and the platform teams, because, you know, like I said, the goal of platform teams should be to work as closely with their customers as possible. And their customers are the product teams which are building the products. So, yeah, I guess they have to be very close together.
So, one pattern we follow in WSO2 is that, you know, we have dedicated or allocated engineers from the platform team that are closely associated to the product teams. So, we have, like, several product teams building different, different kinds of products. And we have, like, a common platform team, but in this common platform team, we have representatives representing different product groups so that, you know, we make these teams as close as possible, right? So, so I think it’s going to be a very close relationship, or it has to be a very close relationship between the platform team and the, and the team’s building products.
Derric: That’s interesting. So, embedding someone inside the product team to help ensure that feedback loop is as quick and short as possible.
Nuwan: Yeah. Yeah, exactly.
Derric: So then talk about API metrics. What are some competent operational business metrics and who owns them? Is it a platform team? Is it a product team? A little of both?
Nuwan: Yeah. Yeah, so that’s an interesting question because I tweeted out an article just today, earlier today, which said, this was on Newstack, this said, you know, observability is owned by the developers, not, not by the platform, you know, not, not by the platform engineers. So, I think there are two kinds of things here. So, there is the, the logs and the application. Stuff that it is, you know, that it is, you know, emitting out. And then there is, you know, tracing and various kinds of metrics that are important for SLAs and so on. So, I think developers should have the freedom to put in like the logs and whatever things they, they think are important. So, I think it’s important because when it comes to troubleshooting an issue, right, it’s going to go into the hands of, if it’s an issue on the application side, it’s going to go into the responsibility bucket of the developers. So, they should have the freedom to put in whatever they think is useful and important.
But at the same time, there are things like, you know, SLA violations and, you know, these kinds of metrics. So, they, I think, fall under the bucket of the platform engineering team so that they get alerted when things are, you know, going out of SLA and so on. So, I think it’s a bit of both, but in the market today, there’s this kind of this belief that all metrics and logs and everything should be owned by the platform engineers. I don’t think that’s necessarily true. I think developers have an equal, say, should have an equal, say, in this as well.
Derric: Definitely having that, I guess, dual ownership and trying to figure out what is the right things to be tracking for each team is important here. But we’d like to also talk about trying to treat APIs products and aligning them to business outcomes. So, I guess, trying to give some of that visibility to developers themselves to understand those outcomes and define those outcomes is important. How do you incorporate that in the API lifecycle?
Nuwan: Yeah. So, I think it’s a, this should be, this should, is kind of, should come from the platform as well. So, when you put out an API into some kind of API management solution or if you’re running an API on a platform, the platform should, you know, cater to two different, at a very high level, two different kinds of metrics. Which is, you know, the things that are useful for your operations. So, these are like the latencies, error rates, you know, uptime and these kinds of things that are in discrete, right. So, whatever that is important for troubleshooting issues or running the APIs, you know, in production.
And then, from the platform of API management solution should, either by itself or by using a third party, should give important business metrics, right. So, it should just be plug and play, right. I don’t expect developers to, you know, understand all these metrics that are important for the business. They should definitely have a say in it, but they shouldn’t be responsible for implementing it, right. So, their platforms or the API management solution should take on that responsibility. So, when you just plug it in, it should somehow give out the business set metrics as well, such as, who are your consumers? Who are the unique number of consumers you are having? You know, what is your adoption rate, like your growth rate, right? And what is your churn rate, like how many people are coming in, how many people are staying over, how many people are, you know, letting go after the first day of a stover and so on.
Like, and also things like, you know, how fast do you get to the first request and so on. So, there’s these operational metrics and the business metrics. While the developers should have a say, I think the responsibility of implementing it and giving it should, you know, happen from the API management solution or from the platform, either by using features they build themselves or by integrating with some third-party solution.
Derric: So, again, making that data layer, that observability layer invisible for the respective product teams, they just need to think about the business metrics and that’s it, right? So, not really think about the underlying infrastructure.
Nuwan: Yeah, yeah.
AI’s Role in Platform Engineering and API Development
Derric: So, I guess, you know, can’t do a podcast without discussing AI and, you know, that’s one of the big talks these days. What do you see some of the risks around AI, especially some of these newer AI applications around security, governance, and some of the other things as we discuss platform engineering?
Nuwan: Yeah, so, I mean, using AI gives a lot of power to applications, obviously, right? But, you know, as they say, you know, with a lot of power comes a lot of responsibility. So, I mean, AI is all great, but you have to use it with a little bit of caution. You first have to understand how AI works really thoroughly, you know, before really getting into it. And, you know, there are some risks, but of course, none of these risks should fear you from using AI, right? So, every organization should be bold enough to, you know, take the steps towards it, but with caution.
And that is why understanding how it works, what kind of data it is processing, and the nature of, you know, its outcomes needs to be clearly understood. So, for example, there’s always this risk of data leakage, right? You know, so you have to be cautious about what data do you feed it in, right? And then processing of personally identifiable information, PII, right? So, you have to be cautious about, okay, what kind of, if there is PII going in, how do I mask it out, right? And, you know, things like that.
And also, there could be other risks, such as, you know, that thinking that AI is always right is also a, like, you know, common mistake. So, the one, the nature of AI today is that it is, you know, non-deterministic. So, which means that the outcomes may not be exactly right all the time. So, that means you need to put in the right guardrails so that, you know, you don’t screw things up when it misbehaves, right? So, understanding that it is non-deterministic and working around it is very important.
And, you know, when everything’s up and running, again, running without proper understanding of, like, observability aspects, right, such as, you know, how many tokens you are using, you know, and so on. And, you know, these kinds of things are also risky because, you know, it may drive up your costs. Unintentionally, there are that side of the risks as well.
So, I think that the key is there could be different, different kinds of risks. And what is a risk and what is not a risk, I think, depends on the nature of the organizations and the type of data it is processing. So, but I think the key is, again, not to fear, you know, AI, just because there are risks. Everyone should take the step towards it. But the key is to understand exactly how it works and, you know, proceed with caution.
Derric: I really like that. Trying to approach it with caution, but at the same time, you don’t want to fear it, right? And everyone’s going to start incorporating AI and really make platform engineering even more important, right? Have the right guardrails in place. We’ve heard these terms like economic denial of service where it’s not really hacking, but I guess you could accidentally run up a big cloud bill these days, right?
Nuwan: Yes, definitely, yeah.
Derric: Any other risks that you see, you know, that could impact platform engineering that the AI is introducing?
Nuwan: Well, so some of the risks could be something like, you know, like all automation without understanding the real need, right? So, I mean, platform engineering is all good with all kinds of automation and so on. But at the end of the day, it’s very important. You always question yourself about, do you really need this? You know, going back to the first principles about asking the question of why you are doing this and so on.
So, if you use AI, you know, AI just knows how to read some stuff and, you know, apply it, but maybe the real need for it could be different, right? Or there may not be a real need at all, right? So, there could be the risk of overengineering because of the use of AI. So, that could be one risk you have to be a little bit cautious about.
And also, poor quality suggestions. So, there are also cases in AI where I think you sometimes need, like, to implement, like, human-in-the-loop systems, right? So, AI is all good for giving suggestions and so on. But sometimes you need to implement human-in-the-loop, right? So, AI could come up with poor quality solutions. So, you could, you know, maybe in certain situations, you need, like, a human-in-the-loop kind of workarounds to get through it.
And also, you have to be a little careful about, like, the security and the data exposure that it might risk in, right? Basically, whether the use of AI results in your data or your customer’s data landing up in places that you really don’t want to, right? So, if you incorporate AI without understanding it properly, there is that risk.
And, yeah, I think these are some of the risks that I can think of when it comes to applying AI in the context of platform engineering.
Derric: Yeah, I wonder if shipping some APIs super fast just through leveraging AI yourself, you’re going to induce a lot of cybersecurity risks and everything else. So, it’s going to be interesting to see, you know, how platform teams try and mitigate that risk and make sure, you know, you’re not shipping, shipping basically unauthenticated API accidentally for whatever reason.
Nuwan: Yeah, yeah, yeah. So, yeah, that can kind of be mitigated if you have the proper guard risk. So, one of the requests that one of our customers came up with recently is to say, look, we know in your platform we can turn on and off security. But we want to make sure that nobody in our organizations is ever allowed to turn off security on any of the APIs, right? Can you help us implement that, right? So, we came up with a policy which said, okay, no, nothing doing, nobody can turn off security, even though that’s a feature, right? So, I mean, these kinds of guardrails can be implemented, yeah. So, yeah, yeah, you’re right, yeah, you’re right. Those risks exist and we have to understand them and put in the right set of guardrails to counter them.
Derric: Makes sense. And then, I guess, flipping to the product teams, you know, how can they also leverage AI as they’re really trying to treat APIs as products and ship the best possible APIs for their customers? What are some trends you see there?
Nuwan: Yeah, I mean, so, on product, like, all applications today are, like, you know, kind of, like, AI enabled. So, there is, you know, some kind of chat interface and so on. So, we have this, you know, concept in WS02 called AI for code and code for AI, which is basically a matter of how AI can help you write better code. So, that’s basically one angle to it, right? So, this is all about generating better code, making it more efficient, making it more faster, and so on. So, there is that side of the equation where how AI can help you build better applications.
And then, on the other side, there’s this process of how can AI really help your product itself, right? So, I think every product team needs to think of that. How can they utilize AI to make their product better, right? So, to give you some context, now, we are working on, we have a platform in, like, a software engineering platform that we offer at WS02. And we’ve also gone through this cycle, and we figured out that, okay, through this, we can implement capabilities like, you know, implementing guardrails, or basically the fact that I talked about earlier.
How to switch from enforcement to enablement. So, we figured out that, you know, using AI, it’s much easier to shift from enforcement to enablement, right? So, what this means, to be very precise, is to say, so, you have best practices documents in organizations, right? And we have, for a long time, been expecting engineers to read them, understand them, and do things according to that, right? But now, with AI, you don’t have to get the developers to read it. You can feed this document into the system and tell developers, okay, you just write your code, right? You focus on your application. And the engine will make sure it reads the documentation, identifies, you know, where things are not really right, and say, look, dude, everything’s fine. But, you know, these are some places you need to take a second look at, right?
So, that basically, and it can also generate templates for you, right, for doing your job right. So, this is something that applies to our product. So, similarly, I think AI can help different, different products in different, different ways. So, it’s the job of these product owners to think of how they can help in these angles and come up with it. It’s more of a creative process, I would say.
To sum it up, there’s the aspect of how AI can help you write better code and build better products. And at the same time, there’s the aspect of how AI can help you improve your product. And that is unique to, I think, each product and its capabilities.
Derric: I like that. AI for code and code for AI. And kind of, hopefully, developers, they don’t ever read docs. So, what can you do to make it easier for them and still, you know, have that governance in place?
Nuwan: Yeah.
Derric: But, thank you very much, Nuwan, and glad to have you here today. And looking forward to joining the next episode of Moesif’s Webcast.
Nuwan: Thank you for having me, Derric. It was a pleasure.
Related Articles
API Strategy
API Management: How to Monitor API Usage Across Multiple API Gateways
Monitor API usage across multiple gateways with Moesif. Unify API management, analytics, and billing to improve visibility and scale API products faster.
API Analytics and Monitoring
How to Setup Observability for your MCP Server with Moesif
In this article we’ll discuss how to set up observability to debug your MCP server and understand usage patterns
Podcasts
APIs Over IPAs 17: Aligning API Design to Business Outcomes with James Higginbotham, LaunchAny
In this episode, Derric chats with James Higginbotham, founder of LaunchAny, about designing successful API strategies that drive business value.
API Analytics and Monitoring
Gravitee + Moesif: Unlocking API Observability And Monetization
Learn how you can achieve API observability and API monetization by using Gravitee and Moesif together.