API Evangelist Conversation with Asanka Abeysinghe, CTO at WSO2

Hello, Kin Lane here, API Evangelist, for another one of my API conversations with interesting folks who are doing interesting things with APIs. Let’s not waste any time, let’s dive right in. We have today, hello, who are you?

Hey, Kin, yeah, I’m Asanka Abeysinghe, CTO at WSO2. Good to talk to you, it’s been a while.

Yeah, it’s been a while. We’ve definitely had plenty of conversations over the years, and I did probably about 160 podcasts at Postman, and you’re one of the ones that never quite, that kept getting pushed back, and so I’m very thankful to have you back here talking. And so we didn’t even prep for this, I just want to understand what’s top of mind for you right now. We kind of dove into it a little bit, but what’s important to you right now?

Yeah, I think there are a lot of things happening and a lot of noise out there, but we are very focused on what really the enterprise is looking for, and what exactly the architects and the product teams inside these enterprises are looking at. So again, like, the main focus these days is about platforms. I think everybody is 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 the 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 is the consumers are not getting what they are looking for, even though the platform engineering teams are putting a lot of effort to build these platforms. And then again, API and API management has become a cool part of this story as well. So that’s what I thought, part of the discussion 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 a couple things I want to hit you with there. So let’s roll it back and start with the basics. What does it mean to be building an API platform?

Yeah, so I think, in my view, you need the internal developer platform, and the API platform is part of that, because isolating an API platform will not provide the full benefit for the application developers who consume the APIs, and the providers who are building the APIs and providing it to the application developers to consume. So that’s where I’m coming from, like, without isolating it, make it part of the woodwork, and make it accessible, self-service capability, a platform service that people can easily access. To answer your question, what does it mean by an API platform, basically having the full life cycle embedded into the platform, from the designing to deprecating an API, that handle the entire life cycle of an API, and give that capability within the platform for various user personas that we get in this particular exercise.

Yeah, I like the way that you separated it out there and focused on the internal developer platform, and then to bring it back to what you were saying, we’re not always delivering what the consumers of these platforms are needing. And I feel like we’re at this intersection of several, I would call, I mean, they’re real movements and they’re real things, but they’re also very vendor-led narratives around API management, which is where you and I know each other from, that’s been, you know, full life cycle, bundled, unbundled, there’s a lot of concepts around what is API management. And then you have kind of DevOps and this other area running its course, and you have these things colliding at this moment we’re in right now. And I get why we’re doing the API platform, but what do people actually need that we’re under-delivering on?

Yeah, so the problem that I see, the complexity, because there’s a massive complexity that we have to deal with. One from the infrastructure side, right, Kubernetes is great, but then again, running the Kubernetes cluster in 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 complexity and become platformless, basically you have a platform but you are not dealing with the platform, rather you consume it. Even in serverless there are servers, but then again we are not dealing with the servers, right. So the same thing that we think should happen in the enterprise, that the application developers and application development team should not focus on the platform, rather focus on consuming the platform. And there’s a problem, Kin, 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, but we think, yes, you need that, but you need something more than that, you need enterprise software engineering capabilities embedded with that operational, delivery capabilities. When you look at the enterprise software engineering capabilities, that’s where API management comes in, how you can make it easy to expose an API, because API is the standard way of how 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 and correct type of APIs, but it has to be a managed API, that you expose these business capabilities to the consumers to consume. And if we can bring that to the platform, and I would say pushing 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.

So you and I have been talking about this stuff for the last decade, for a while now. What’s the biggest obstacle in our way from making the delivery of APIs truly easier, and not just APIs, API products that business and technical people care about? What’s the biggest obstacle that’s still in the way that we need to deal with?

Yeah, so one thing is the technical aspect of this, right, like 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 are trying to figure out how do I create an API, how am I going to release it, and then again even the discovery still is not there, right. We are speaking about developer portals, marketplaces, for a long time, but then again it is not well established, that’s why we need those capabilities to be part of the platform, and then have that easy access to the producers as well as consumers. That is one. And number two, blindly getting into conclusions. As an example, when GraphQL came into the picture, I have seen some of the enterprises telling, I’m going to expose all my APIs on GraphQL. Why? Because it’s cool. Okay, but then again, I think we have to use the correct style at the correct place. As an example, GraphQL is made 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 GraphQL, without knowing the data model, how can an application developer consume it? And sometimes the application developers don’t have a clue about the data models within the organization. So if you provide it as a simple REST API, it would have been very easy for the application developer. So I think those are the two main barriers that I have seen, that API management is not available to access, as well as jumping into these types of conclusions without looking at the real problem and finding a proper solution for the problems that they see inside the enterprise.

Yeah, great. I can’t agree enough. After my last couple journeys, Postman and Bloomberg, I’m 100 percent focused on HTTP APIs and webhooks and the governance of those, nothing more. And you can govern, you can standardize, you can provide management for these other, but, as you said, GraphQL is often, I’ve seen too often, a distraction for companies from actually doing, learning and doing REST or HTTP APIs well. Kafka often and WebSockets becomes a distraction from doing webhooks well. And so I feel like technologists, as engineers, left to our own devices, will always chase that next new shiny object, and we need more pragmatic business stakeholders involved in the conversation. So my next question for you is, do business people in 2025 almost, do they care about APIs enough?

Yes, I think that they will and they have to, because anyway a lot of things are happening, right. 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 value, because composability is the key, right, how you can quickly build new business models. It comes with the technology hand in hand, and if you have these APIs available you can build a new business model quickly and then deliver it to your 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 how you can bring AI-augmented software engineering, that’s where we can use some of the AI capabilities to govern the APIs from design time to runtime, and then number two, how you build AI-driven applications. Again, API is the key for all this stuff, right. And we were speaking about ingress for a long time, but now egress is going to be a bigger part as well, how you call outside the enterprise, how you find the correct models, how you monetize these APIs, how you throttle these APIs, all these requirements are required to the enterprise. So I think it’s going to be more focused and bring more value to the business in 2025 more than ever. So I think the focus will shift back and we will more focus on the APIs again. And I think as technologists we have a bigger role to play when it comes to API management and how we can deliver value to the business through APIs.

Agree, I like it. All right, one last one for you. Who has more power, API producers or API consumers within the enterprise?

Ah, good question. So I think 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 teamwork, and producers should provide what consumers require, and then consumers should request from the producers what they’re looking for. 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 as the management teams, what the management should do is provide that environment to have this conversation, and then provide useful APIs, because having a hundred of APIs without consuming it doesn’t work, right. So you need to consume the APIs, and you have to do this iterative approach, like iterate, iterate, iterate, and then give valuable APIs for the consumers, and consumers should give the providers that feedback and make it work for the business. I think it goes hand in hand, and it’s teamwork.

Agree, I agree. APIs are not a one-way street, that’s in their name, it’s an interface, it’s by design. So can’t agree more. Excellent answer, and I appreciate you coming by and chatting with me, this has been fun.

Yeah, indeed, it’s good to have a chat, and it’s very useful, and thank you very much.

All right, thank you. Very cool. I literally just threw him in, didn’t prep before, and asked what was top of mind, because I know he can handle it. And I actually find with folks like him it’s better off to just throw them in, because they’re pros at this and they get what’s going on, and I always love hearing the answers. All right, everyone, thanks, talk to you later.