API Evangelist Conversation with Asanka Abeysinghe, CTO at WSO2

Hey Ken. Yeah, I’m Asanka. Asanka, best single CTO at WSO2. Good to talk to you. It’s been a while.

Yeah, I think, uh, there are a lot of things happening and then a lot of noise out there, but, uh, we are very focused on what really the enterprise is looking for and then, uh, what exactly the architects and the. Uh, the product teams inside these enterprises are looking at. So, uh, again, like main focus that these days, uh, about platforms, I think, uh, everybody, uh, working on platforms, everybody building platforms. And as a result, platform engineering has become a hot topic. But then again, the problem is, are we delivering what we need? Enterprise is looking for. And there are two sides to the story, right? The provider of the platform and the consumer of the platform. And what we have seen, the consumers are not getting what they are looking for. Uh, even though the, uh, platform engineering teams are putting a lot of efforts to build, um, uh, these platforms. And then again, API and API management has become a core part of this story as well. So that’s what I thought of discuss with you since you are mainly focusing on API and API management side. And what’s the link between platforms and what’s our viewpoint on this?

Yeah, so, um, I think, uh, uh, in my, uh, view, like, you need an internal developer platform. An API platform is part of, because isolating an API platform will not provide the full benefit, uh, for the application developers, um, who consume the APIs. And then, uh, providers who’s building the APIs and providing it for the application developers to consume it. So that’s where I’m coming from, like, without isolating it, uh, make it part of the woodwork and then, uh, make it accessible. Self service, um, capability, uh, platform service. That people can easily access to answer your question. What does it mean by a, uh, API platform? Basically, having the full life cycle embedded into the platform from the designing to you deprecate an API that handle the entire life cycle of an API. Um, and give that capability within the platform for various user personas that we get in this.

Yeah. So the, the, uh, the problem that I see the complexity, because, uh, that’s a massive complexity that we have to deal with one from the infrastructure side, right? Uh, communities is great. But then again running a kubernetes cluster in production um Production setup is not that easy. Not everybody can do that And then again, it has become an ecosystem, right? A lot of things are connected to this infrastructure layer So mainly the application developers are dealing with that layer not focusing on the application So that’s the main problem. That’s why We have to hide that complexity using some kind of an abstraction and abstractions are everywhere, right? In computer science and abstractions are great. So that abstraction that we need to hide that complexity is the internal developer platform. So we hide that, um, complexity and become platformless. Basically, you have a platform, you are not dealing with the platform, rather you consume it. Even in serverless. They are our servers, but then again, we are not dealing with the servers, right? So same thing that we think should happen in the enterprise that application developer developers and application development teams should not focus on the platform rather Focus on consuming the platform capabilities and that’s a problem keen as you said Depending on various vendors how they position this thing unfortunately internal developer platforms are mainly focusing on Operational side and the delivery focus, but we think yes, you need that But you need something more than that. You need You Enterprise software engineering capabilities embedded with that operational and delivery capabilities. When you look at the enterprise software engineering capabilities, that’s where API management coming on how you can make it easy. To expose api because api is the Standard way of you communicate right internally as well as externally it can be Some kind of a format. I think we debate about rest. We debate about soap We debate about graphql. It doesn’t matter. I think what we need is the correct style Uh and correct type of apis It has to be a managed API that you expose this business capabilities to the consumers to consume. And if we can bring that to the platform, I would say, push it down to the platform. So that way, We have that API management capabilities embedded in the platform so everybody can easily consume it without worrying too much about this operational aspect of API management.

Yeah, so one thing is that, um, the technical aspect of it, right? Like the API management as a service or the API management as a self service capability available within the Enterprise it’s one problem that I see because still people trying to figure it out How I create API how I am going to release it and then again even the discovery Still, it’s not there, right? We are speaking about developer portals, marketplaces for a longer time, but then again, still, it is not well established. That’s why, like, we need to be that those capabilities part of the platform and then have that easy access to the, um, Okay, the producers as well as consumers that is one and number two blindly getting into Conclusions as example when graph ql came into the picture I have seen some of the enterprises that they are telling i’m going to expose all my apis on graph. Why? Because it’s cool Okay, but then again, I think We have to use the correct style at the correct place as example graph ql is great for data related Apis, I would say and I think still rest is very powerful when it comes to application developers because the problem with graph ql Without knowing the data model, how can an application developer consume it? And sometimes the application developers, they don’t have a clue about the data models within the organization. So if we provide it as a simple REST API, It would it would have been very easy for the application developers. I think those are the two main um, I think barriers that I have seen that API management is not available to access as well as Jumping into these type of conclusions, uh without Looking at the real problem and finding a proper solution for that, uh, problems that they see inside the enterprise.

Yes, I think they will and they have to because uh, anyway, uh a lot of things happening One like delivering value because value has become the key for everybody how we can deliver more value as technical teams and I think api is the more kind of the center of everything how you can deliver business values because Composability is the key right how you can quickly build new business models You Comes with the technology hand in hand and if you have these apis available You can build new business models quickly and then deliver it to your end users So that’s number one and then again, I know ai is a completely distraction But then again how you wisely use it within the enterprise is another thing, right? And I think there are two things one is Uh, how you can bring AI augmented software engineering, that’s where like we can use some of the AI capabilities to govern the APS from design time, uh, to run time and then the number two, how you build, um, AI driven applications again, API is the key for all this stuff, right? And we were speaking about, uh, ingress for, uh, ingress for a long time. But now egress going to be a bigger part as well. Have you call outside the enterprise, how you kind of find the correct models, how you monetize these APIs, have you, uh, throttle these APIs? All these requirements are required, uh, to the enterprise. So I think, uh, it’s going to be more. Focus and bring more value to the business in 2025 more than ever. So I think focus will shift back and we will more focus on the APS again. And I think as technologies we have a bigger role to play when it comes to API management and how we can deliver value. Uh, to the business through APIs

Ah, good question. So I think, uh, both because without the consumer, no point of having producers, right? And then consumers can’t survive without producers. So I think it’s a combination and it’s a teamwork and producers should provide what consumers require. And then consumers should request from the producers what they are looking for. I think it’s a I think this marketplace concept is pretty cool, right? When you go to a real marketplace, it’s a conversation with the producers and consumers, and we need to have that conversation within the enterprise without working as silos. And I think, uh, as, uh, the management teams, what The management should do provide that environment to have this conversation and then provide useful APS because having hundreds of APIs without consuming. It doesn’t work, right? So you need consume the A. P. S. And you have to this iterative approach like iterate, iterate, iterate and then give valuable A.P.S. For the consumers and have consumers should give the providers that feedback and make it work for the business. I think it’s go hand in hand and it’s a teamwork.