Podcast | Who should handle the complexity in consuming APIs?

Jean
Shin

Director, Strategy & Content | Podcast Host of Mobile Interactions Now

28 min podcast

In this episode, we’re talking with Zdenek Nemec, Founder of Superface, who’ll help us imagine an alternative way to provide and consume APIs. With trillions of API transactions powering today’s digital commerce, Zdenek sees an entirely new communication protocol – Autonomous API, anyone

Podcast Transcript

Jean:

Z, welcome to the show. We gave a short intro in the beginning, but I would love you to tell our audience a little bit more about the journey that led you to founding Superface.


Zdenek:

Thank you, Jean. Hello, everybody. I'm Z and I'm an API expert, I guess. Because the journey started I think over 10 years ago with a start up that formed in the UK, but it was essentially founded by Czech founders called Apiary. That's basically where we started to think about APIs and what they are and what values they are bringing. And build this amazing tool called Apiary for API design. And that's how I got to APIs, and that's how I got into this line of business. And travel around the world, speaking and researching APIs programmatic.

And then later on, when Apiary was acquired by Oracle, I decided it's time to move on and started my own consulting business called Good API, where I continued in what we were doing in Apiary. But this time being with the actual people or companies or organizations that are implementing APIs and helping them on their journey. And that's basically how I got into APIs. And I spend a lot of time at small start ups and big companies in the trenches, but also researching and thinking about what might be the next things in APIs.


Jean:

Actually, this is the 23rd episode of Mobile Interactions Now, but only the first time I'm actually addressing API as THE topic. It used to be more of an adjacent topic that we talked about in terms of solving certain problems, explaining certain relationships. But we are really going to talk about API itself. And I'm like, wow, I didn't know I wanted to talk about this. But then I could not have picked a better guest to actually delve into this. So let's do this.

The value of APIs is being perceived more and more in a very prominent way, but it is not really outside of the little tech community, we haven't really talked about it in this light. So I know this might probably be boring for people who are living, speaking API every day, but can you just quickly walk us through how APIs became such an integral part of how businesses are delivering and sharing technology? Because it's no longer just a social fun. And I went through the whole Flickr thing in that age when it became a social fun thing. But now it sounds like it's such a business to business relationship. What is this, how we got here?


Zdenek:

Absolutely. And that's actually a very good question. And it's good that you are actually thinking more about the business and not focusing on the APIs. Because at the end of the day, APIs are and should be what enables business, what empowers business, what enables innovation and operation efficiency and whatnot.

So, the story of APIs really goes hand in hand with the story of digital transformation. That's when businesses started to realize that, hey, there is this new creation called computer and later on it's working. And worldwide web in 1990 was basically what started it all. What drew this digital transformation to the next level where companies started to realize, okay, it's not just smart type machines, but now we can communicate over internet, we can sell stuff on the internet.

And so that is basically where we already started seeing first APIs around the year 2000 and later companies started to realize that, hey, there is not just the eCommerce side of this thing, not just the website. But then API being the wholesale presence of your company. This is not just your customer front door, but really you as a business connecting to another business.

And just one interesting information, I just stumbled upon the other day, is that in 2017, that was the most recent number I was able to get, the global eCommerce transactions were estimated at 25.5 trillions in business to business transactions. So that means a big portion of that is actually going through the APIs. And only, I think, three, well, only three trillions were really the B2C from shopping online. But the rest of the 25 trillions is really going through, one way or another, through some sort of APIs.


Jean:

That is a mind boggling number. Just to think about how many API calls are going through. I happen to work for a company that makes two billion API calls a year on one product. And I totally believe you with this comparison between B2B and B2C. And sometimes it's the amount of interaction that it takes for one B2C action to happen properly, I think there are a lot of layers in B2B, something that people don't often think about.

So, I mean, there is an API and then there is this, what I'm beginning to hear, that's why I invited you here today. Something called autonomous API. And I think this is your latest initiative with Superface. And I have no idea, when it comes to autonomous API, I'm like whaaat? Autonomous car? So what is this autonomous API?


Zdenek:

Absolutely. So autonomous API is basically a system, so APIs are about a distributed system. An autonomous system is the systems where you don't control its elements centrally. And so such an autonomous APIs is a system where you can have machines or these components being in the environment, in the system, figuring, being programmed for some purpose, do some stuff, buy some goods, do this, send a text message, whatnot. And they go out and they figure out how to do it. And they perform the task.

So the point is actually, and that's where we, again, need to go a little bit back into histories, what happened with the APIs at the start? They were these point to point integrations between two big businesses that could afford it. And they had engineers wiring the wires relay from one company to another company.

And then later on we realized, hey, this might be actually useful, we might have, so I call it, generic APIs, where more companies, more businesses are interested in your business offering and connecting to it.

And now we are seeing situations where there is many, many connections. And you mentioned it. The applications today in general, one study shows that an average application has 15 connections in one app. So that means, as a consumer, that means a lot of complexity, a lot of things are going on. And when you are facing this complexity, because APIs are growing, and more and more people and organizations are deploying APIs, then you are starting to face a huge complexity of these like wires going here and there.

And the way I see it, there are only four ways how to solve it. You can a) hire more people, b) try to do some standardization and governance, c) try to automate this governance to automate the processes, or you give up on this notion of handling the complexity centrally, and you give the components autonomy and you let them go out, figure stuff and do it.


Jean:

So you're basically telling enterprises in a way, just don't try to deal with the complexity, it's not your thing anyway?


Zdenek:

I'm telling them to do it differently. Because today, what they are doing, and most of us are actually, all API industries doing, is we are adding more people to the APIs. Because we need more APIs. And we are adding more people to APIs to connect to machines.

And that's a funny thing. You have one interface, but two machines talking to each other through this interface. So you would say, hey, this is machine to machine interaction, but the truth is there are some [inaudible 00:09:47] poor people in the middle, connecting these machines together. Writing the documentation, reading the documentation, programming the machine according to the documentation.

So because the number of APIs is growing, we are pouring more and more people into APIs just to be able to establish what I believe should be communication between two machines and machine should be figuring it out.


Jean:

So basically you're trying to get people like, okay, don't think you can control this. The original intent of API is basically machine to machine interface. It's a fool's errand to keep adding people to make that machine to machine interface happen?


Zdenek:

Absolutely. Absolutely. It makes sense when you think about it. Okay, this is how we started. We laid this first connection by hand. But now it's getting out of control. And companies are spending a lot of money and effort to have a good developer experience and have well designed APIs and then design APIs in a similar way and all this kind of stuff. And that's very expensive and very slow and costs a lot of effort and what not. It takes a long time. And it's very brittle. So it's easy to break.


Jean:

I totally empathize with that problem of having to have people to integrate APIs and all those things on both ends of that spectrum. And now I get the picture of what the problem is. Let's say autonomous API is in the middle. How is my day looking differently? Other than not having more people in the middle trying to integrate this? What does it look like? Paint me a picture please.


Zdenek:

So there are two layers to this. One is, this current situation with large enterprises I've been working with, and don't get me wrong, I really enjoy that cooperation, but with some of the largest companies, they are building these API centers of excellence teams. They are putting a lot of effort into getting their APIs right. And making them beautiful and attractive. And then even they do some launch parties around that and whatnot. So that's one element that I don't think is needed because that's element for humans and machines can figure it out and just do the stuff we ask them to do. And we don't need the parties around launch of your new API because machine doesn't care. So you lose that element of people doing this boring work that nobody actually really enjoys doing. So that's one thing, the cost of that whole department.

And more importantly, it's about the time. So you have some capabilities as an organization. You want to get those capabilities out. You want to realize whether there's somebody maybe paying for those capabilities you have, or you need to do something different, and mix them differently or whatnot.

And my world, the world I'm working on, is really a situation where you can get your capabilities out just like that. Without spending months and weeks and millions and whatnot to do [inaudible 00:13:19] and to get them out.

So you have a business, you have some capabilities, and I'm telling you that you can deliver your business capabilities at almost no cost to the outside world. And let people connect to your business capabilities, find them and connect to your business capabilities in milliseconds. So, your world really will be like, hmm, we have something we can do. Let's say a ship container or bring you food. And it will take you literally minutes to make this available through a digital channel.


Jean:

As a tech business person, whenever I hear something as fantastic as this because it’s really talking about the pain and speed, it’s a really huge issue especially in this pandemic situation we are going through and all that. But at the same time, part of me think, at least in this current status quo, there's the governance mechanism, there are some things that developed for a reason to control some of the known problems.

So now we know the direction this autonomous API is painting. What are some of the things, the difficult challenges that still need to be solved? Meaning, I'm thinking, are we talking about one autonomous API handling many other things. Therefore this is like the one thing that can go down then… am I at the mercy of this one API performing? Things like that. So take us through some of the big issues that still remains as a big challenge for this to happen.


Zdenek:

So, one thing I see as a big problem, and I don't think companies are realizing it, is consuming an API is a liability. When you basically dedicate yourself to consume somebody else's API, you're creating yourself handcuffs in a way. And you are locking yourself to the other vendor and you are saying, hey, I believe in this vendor, I hereby decide to directly couple with that vendor and be at the mercy of that vendor. And not so many people are actually realizing it when they are building their applications and consuming stuff. So they don't think about consuming API as a liability. But it is a dependence in your software, in your creation. And you need to be very well aware of that.

And if I go to a random company today and I ask them, so what are your dependencies? What APIs are you depending on right now? Most of them actually have no idea or very little idea. And very few of them know hundred percent every single dependency they have in their chain. That means if something goes wrong, like we just had with some situations in companies, might be going really quickly away, quicker than we thought. Then suddenly one of your dependency might just go away. That's of course potentially a big threat for your business.


Jean:

We briefly talked about layers of things involved in delivering a service. Just help me understand this better. A lot of times, I think you briefly mentioned about having multiple vendors doing things and the kind of complexity that creates. But does this mean autonomous API works better? How would it work for a typical enterprise solution, in a solution package that has a lot of layers. So for example authentication, I mean, think about authentication as a service. And if I have that as, let's just call it an AaaS API, underneath that, there are a lot of other APIs using different channels and such. There will be a lot of different services. But it's happening on many layers. Does autonomous API work better for certain things? How about something packaged as a solution, when enterprises are already consuming it as a solution, is it different? Tell me.


Zdenek:

At this cake model or this layers model, it gives you in each of the layers, it gives you the cushion of basically decoupling your application from an actual provider. Because in many cases at the end of the day, you don't really care for authentication. You might not care, you might care. Depends. If it's provided by a company A or B or your internal service A or B. You don't really care about that in many scenarios. You just want to get that authentication going or that use case that you want to take. And the autonomous APIs are basically enabling your consumer application to decouple yourself from the actual interface of the particular provider, particular service, particular company. So it makes easier for you to switch to another provider, to another service at each of those layers.

So, it becomes way more elastic than it is right now. And one of the biggest problems with APIs is also the way we currently hard wire them together. Is that of versioning, of those evolutions. You are, as a provider of a capability today, you are locked on your version. You cannot do some breaking changes because you don't know who depends on your API. And if you do it, then there might be people crying or some contracts broken, or something just go break and you have no control over it. So that's also one element of what's currently going on and what are the problems with API, that autonomous APIs are solving. Because you have this cushion because you are not hardwired to a technical interface. But you are, as a consumer, about the thing you want to do, the use case you want to take, then that gives you the flexibility and also some safety when things change.


Jean:

Try to also think about how that jives with some of the enterprise conversations going on in terms of the whole governance and some kind of policy making process that is being discussed surrounding APIs these days. I mean, if in fact, if I'm totally decoupled from these services, how do I make sure ... because not every company has the same requirements…how would they implement different things they want to impose. How would they even think about this once this gets decoupled? How do they make sure?


Zdenek:

So, first of all, it actually helps you to publish less things. So you don't have to publish as many thingies as before because those are simply no longer relevant. Today, with the enterprise API governance, you want most of the APIs being produced by different teams looking alike. That's our goal. Because then it makes it easier for you to consume one service, other service, third service and whatnot. This is not necessary. This is only for humans. And if there is a machine, instead of human, connecting these two APIs, then you don't have to have this policy. You don't have to have that governance.

Which translated, gives more autonomy to your teams in your organization. Because you no longer ask them to, hey, program this API in such a way, using this technology, and it has to look exactly like that. So you no longer have to do this kind of stuff. The teams are now free to basically use what technology they know the best, technology they think is right for the task without being sort of limited by these policies. Of course, there are still some policies. Of course, there is still some governance that has to go on. But it's a very smaller, let's say, subset of what it was today.


Jean:

Then just quickly though, so things like data protection policy, how would I…because if it's like one solution provider, you have auditing process, you have certain things that make sure before you sign the dotted line and things like this, how would you handle that kind of topic?


Zdenek:

Well, those still have to be there one way or another. We envision that these policies, and that's actually back to your previous question, we envision that these policies are also machine understandable and accessible. So the moment you as a consumer, look at some capability provided you understand, let's say, the data policies they have, you understand the SLAs, you understand, I don't know, even the price. And that's actually one big problem with the pricing today, or with commercial APIs. You want to use an API today, then you need to first find it, probably using Google. Good luck if you are not working well on your search engine optimization. Then you need to understand it from this developer portal, what's going on there. And then the fun starts, you need to have some sales calls and meet with some sales people.

How is this communication between machines, when a human person needs to do all that stuff. So it's not just the data polices and the SLAs and legal policies and all that, but it's going as far as basically being able to purchase the capability without having to meet a physical person for a coffee and sign some agreements. There is a lot of leaps we need to take, as you can see, but I envision that at some scenarios, we will be able to do digital sales, I'll call it.


Jean:

Well, I am very disappointed, autonomous API is not solving everything…


Zdenek:

You need to change some mindsets first.


Jean:

Exactly. There's always a human factor in business decisions, I understand this. But then, let's think about this now, in order for it to really be popularized what still needs to happen? Meaning, let's just say for the sake of argument that web APIs, including Rest, became really popularized once the cloud computing really took hold, what do you think needs to happen in order for the, say, autonomous API to really take off?


Zdenek:

So I think we are reaching the tipping point with the growing number of APIs, and we are running out of engineers, and people willing to do that. So, that's one part. The number of APIs and the number of connections, that's every single application, it's going to have [inaudible 00:25:32] the proportion and the complexity relative to that…autonomy API I think is the only possible solution. As opposed to central management.

And the second one is really a buzzword. And that is AI. If you really think about an AI, so there are two ways to think about it. The statistical machine learning AI, that's one thing. You want to have harmonized data to train your algorithms and do stuff.

But I'm more thinking about maybe a little bit farther in the future, and this reasoning AI. When you task your AI assistant, hey, do something, I don't know, order me an ice cream. I just fail to see how we can have this kind of AI, and these robots may be physical mechanical beings, how we can have these robots and AIs, yet people will still be wiring the wires between those robots and the rest of the world. That's not going to work. That's just not possible.

So we kind of need to look at a different solution, how you can tap on capabilities digitally without having humans connecting these wires.


Jean:

Sounds like a big, hairy communication problem to solve.


Zdenek:

Well, it's happening. The search engines are struggling understanding the content on the web. They are pushing for some machine understanding of the HTML or the website that people are creating. Because they can, yes, do full text search, but they have little idea of what's going on those pages. And as such, they cannot provide any edit value in their search because they simply don't understand what's going on there. You cannot say, hey, tell me about Mona Lisa because they don't understand the context. They don't understand whether you mean the person, the painting or whatever. So there is a push already to start getting meanings to things so you can use them digitally. You can tap on them digitally.

Part 2 of the interview with Zdenek Nemec will be released in two weeks, following this release of part 1.