Kevin Montalbo

In 2020 APIs have become an essential part of any digital transformation toolkit, whether you're looking to deliver new products, expand your marketing reach, analyze your data, innovate on existing technologies or improve work efficiency, modern enterprises rely on APIs to get things done. However, as API adoption explodes the complexity of discovery consumption and integration also gets dialed to 11 when APIs have to be integrated and maintained manually. This places an additional burden on an already overwhelmed IT department. So how do we move forward from this? Our guest may have the answer. 

Greetings internet. My name is Kevin Montalbo, content editor at Toro Cloud. In this episode of cocktails, we talked to the founder of Super face dot AI. A platform that promises to integrate APIs without humans. Of course, with me today is Toro cloud CEO and founder David Brown. Hi, David

David Brown

Good day, Kevin.

Kevin Montalbo

And our guest for today is the co-founder and CTO of Super face dot AI revolutionizing how businesses connect, digitally empowering developers and establishing autonomy for APIs. He also founded Good API helping enterprises and start ups to identify and build the right APIs for their business and was the former director of DSL Development at API where he authored the API blueprint description language, which is now used by over 200,000 developers and architects to describe well over 300,000 APIs worldwide. Ladies and gentlemen, joining us for a round of Coding over cocktails is Zdenek “Z” Nemec. We're glad to have you, Z.

Zdenek “Z” Nemec

Thank you, Kevin. Hi and good to be here.

David Brown

Good day, Z.

Kevin Montalbo

All right, in the previous article that you wrote, you told readers that the way we do APIs is broken beyond repair, can you share with us some of the challenges that the industry is currently facing with regards to APIs and how these all led you to start Super face dot AI.

Zdenek “Z” Nemec

So the reasons are two fold, one is a business, business approach to APIs and another is, is of course technical. The first one, you know, the relation between the business and it can be fixed and it's improving, you know, sales people understanding APIs. And on the other hand, the developers thinking about, hey, how this API is actually helping my business. So there are some improvements there. It's still you know, a long way to go. But then the technical side of things, I think they are not going all that well because we had the concept of rest APIs and hypermedia and it was not really understood and adapted by developers. And now we are for many years looking into and we are down this rabbit hole of people trying to you know, solve the versioning problem, solve the documentation. And basically they are holding everything with their bare hands and trying to, you know, keep keep the ball floating. but I don't think it's going to work with, with the increasing demand.

David Brown

That's an interesting perspective from someone who authored a description language for A P I's blueprint has the adoption of API description formats like blueprint and the more recently opened API and AC NKP I has that enabled better automation and discovery of API si

Zdenek “Z” Nemec

I think it did. It absolutely did. I think that was one of the revolutions or you don't have to call the revolution. But the change of thinking started you know, back in the days in a pa I think it was like 2012 or something. And there was a format called Ve before APR A where really we, we pushed people or we asked people to OK, don't program first, you know, stop and think design, design, your APIs upfront. Before, before you start coding. And so these formats gave gave us as developers and architects you know, the chance to think about the APIs but also to, to make them more discoverable. So I think it totally helped. The journey was quite bumpy. nowadays, still a lot of people are not designing first, they are still generating this API descriptions format from their code. And we are seeing, you know, it helps with the discovery because these developer portals, these api helps when they submit when the developers submit the API description format that definitely helps with the discovery.

David Brown

See, I know that at Super face you what you're trying to achieve is automation. So my my understanding is is that OK, we have a, a form of a description language for an API whether it be OpenAPI or something else. So there's some sort of machine readable format for an API now. So presumably if there's a machine readable format, there's the capacity for a machine to be able to pick up that API in someone else's API do some sort of machine learning algorithm over the top of it, automatically map it and create the services to connect the two is that the concept behind Super Face

Zdenek “Z” Nemec

In a way it is, but there is a fundamental change to this API description formats from the super faces standpoint and how we use them. The first thing is the problem with the current formats including the one I have created was that um or is that they are mixing two things together the business. So what do you want to do or what does API can do, like send text message and the actual implementation. So we have, you know what, what AC TP call you need to do or not. No. So right now these two are in one, in one document, in one description format. And as such, it's, it's, it's really difficult to, you know, understand what is what and, and and maybe abstract the way on the use case level and not, not you know, get down into, into the implementation. So that's one thing that super face is actually doing like splitting the two right? You have the, you have some notion of of business layer if you will of what the API can do and then the actual implementation, whether it's graph Q or rest or, or anything else. So that's one thing. The other thing is we don't use these description formats at the run time. There might be some, you know, very few examples. graph G schema can be introspected at the run time. But we are not using the open API spec or API blueprint at the run time these days, we use them at the design time to spin spin out the docs or, or, or I don't know SDKS or some tests, but we are not using these formats at the run time. And that's a fundamental, you know, problem because we are baking everything into our code into our clients and then we deploy those clients and then if something changes, we need to basically change the client and redeploy, right? So the difference with super phase is the, of course, you know, you split the business and implementation and then you actually share this information at the run time, not at the design time, not at the coding time, which gives you many benefits.

Kevin Montalbo

All right. So you probably are going to or are currently facing a lot of skepticism from companies and API experts when it comes to automation. So you're probably getting questions. So how are the people you've talked to responding so far with super face? What's their take on automated APIs?

Zdenek “Z” Nemec

So there are two layers of this, like one is one is automation and the other is autonomy over years. I think the automation is actually a more cultural problem than, than technical, you know, we're having having this CICD approach and the C approach that takes actually more you know, change of culture or mindset or approach in the company than actually bringing some crazy new. So that's, that's one thing, you know, we still have to convince people that automation is good and helpful. And then you have this autonomy like saying, hey, you know, you can have clients that can self heal, that can self navigate. That's something that people of course, don't, don't get at the first and, and and then you get this denial, right? Like especially when I talk to, to developers, like fellow developers, the first thing they do. And that's the nature of us as developers. We try to break things, right? We we somebody presents you with some something new and then they are starting thinking, hey, hm how this works? Or, or this cannot work or what if, what if, what if? Right? So from the developer standpoint, we often hear you know, this this might not work or what if, what if if you talk to API experts then most of them, you know, the most of them get it. They, they think something like this must to happen must happen. They, we see that, you know, we cannot have developers manually connecting to APIs if we are going to really get to some, some you know, a AI future. And so I think experts are seeing it. The question is, of course, is this particle implementation will be the one we think it will

David Brown

You're talking about automatic healing in case there was a change to the API. So the client can detect the change to the API at run time and automatically adopt those changes and heal. But isn't the concept of an API as a contract that doesn't change? So what sort of, what sort of changes are you talking about?

Zdenek “Z” Nemec

So when you are a client, your contract is really or should really be what you want to do as a business case, not, you know, you don't care what is the implementation at the end of the day. If you want to ship container, fetch some information or do whatever you care about those business, you know, use cases and not whether your provider have implementation in what API style or JSON format is just trending, right? So your contract should, and in reality really is the the business case, you know, and then the rest is just the the implementation detail. So and that's, that's what I that's going back to what I said about the API description format. Now, the contract is bold, the business case and how they implemented it yesterday, right? And that's that is what is causing a lot of problems. Superfice is giving the freedom to, you know, contract on the business case level. And don't worry about the implementation that can change, that should change actually. And this in a hands side gives you the ability to switch the providers because if they fulfill the same business case, then you are no longer tied to, to, you know, their actual implementation because you know, with firsthand integration costs a lot of money today. And if you if you if you integrate with one provider and that's what we are, of course, seeing they know the providers know that if you spend the time integrating with them, then you are more likely to stay with them, right? Because changing to another provider costs you of course, another an integration work.

David Brown

There are so many variables in how are you managing all the variables associated with the different services and implementation of the operations?

Zdenek “Z” Nemec

And right there this is this this this is a huge topic, right? There is a there is a a many things and we are starting small. So we are starting with the, with the technical interfaces we are or technical aspects of this. We are not yet looking into the business parts like contracting, getting APIs legal slas all that, that's a, that's a, that's a whole, you know, another box to to be opened. So we are now like of course, you know, dividing concourse of starting small with trying to teach developers don't integrate with API you know, don't integrate with Twitter or integrate with sent message. OK? And that's the first bridge that we need to cross start thinking about.

David Brown

But in that, in that particular example, you're not talking about abstracting the API and creating a send message API which you're mapping to all send message providers, right? That's not what you're doing.

Zdenek “Z” Nemec

No nine, we have a, we have a basically one universe SDK where where you use this SDK to talk in this business language. So send message and that SDK will figure out through this concept of integration mean that we are talking about what are the providers, you pick some providers and translate on the flight? So there is not this in in, in our world, there is not this integration platform in between the integration is or the the translation from the business case to the actual API call is happening on the client side in this particular is decay.

David Brown

Amazing. Are you, are you picking particular use cases to begin with like, like send message for the example we gave that?

Zdenek “Z” Nemec

That’s correct. Yes, but we want to make this open so everybody can add their own use cases and of course, the maps to, to the providers. So we are starting with some selection of these use cases. for example, the send message or logistics use cases would be another another example and we want to have this open and it actually will be open by nature because the clients, of course running on the, on the on the client side. So that's, that's an open source, that will be an open source client. So that, that, that one universal SDK is really doing most of the magic. And when you think about it, a lot of, you know, burden with today's APIs is that we are building custom best clients for every API like every single API, every single client for sales for API is, is best. That's, that's just ridiculous. Right? Like we are writing, it would be like writing bespoke web browsers. We we don't do that. We have universal clients for worldwide web, the most successful API so you have dozens of web browsers and they work with the different applications.

David Brown

That's true. But the description, the machine readable description language has enabled automation of that client so that the client can read that we do it ourselves with our own product. We read the description language, we generate the services automatically the machine generated. And if this game changes, we can automatic create.

Zdenek “Z” Nemec

That's the funny thing. You know what Google is trying to do. They are advocating, hey, the structure data notate your html with Jason LD. So we as a Google search engine can actually understand what's going on on HTML page. So Google is the first pushing, you know, web web developers or, or you know, whoever is making the website to annotate the actual content on the in the html. So it's meaningful for machines. So Google can give you a better result.

David Brown

You, you invented the description language.

Zdenek “Z” Nemec

Well, yes, but then you know, I I know but I'm still learning in the process. Of course, meeting the people and observing the the you know, this world. If you would meet me like 10 years ago, I would have this dream like OK, hypermedia unrest is the right way to do it. Yeah. And over the years and years I learned that it will crawl in a better way.

David Brown

It's amazing. And obviously, you're at the forefront of thinking when you came up with blueprint, quite possibly, you're at the forefront of thinking. Now, with this automated discovery and implementation of API as well, I'm going to get slightly off track because I just think it's interesting with the API description, wars with blueprint versus Ramle versus open API and swagger or swagger that was then known. How do you see that played out? Why did swagger and its evolution or open API seem to become the winner in the Open API in the rest of the API wars and then competing formats like Graf Killer and Nay API for different use cases.

Zdenek “Z” Nemec

They did one amazing thing to, with the, with the swagger. and they did to it, it's of course, like, you know, how do you play it on the developers community? And they did this amazing move to, to move the swagger, what was Swiger into the Linux foundation? Right? So, I think, you know, I guess the APR A even though we built the API blueprint and tooling around it as open source, it was always perceived as as this company's language or this company, DS L and company too, which was the same for all the others that you mentioned. But they did this amazing move to move it into the Linux foundation called it open API and create this open API and which is good. I think it's good that we have one format there. That, that, that now is de facto standard. Of course, when you have one monopole, you might be losing something, but that's good. But again, I think we need to move past this, this descriptions format that are being used at the design time only and that are mixing the business and implementation.

Kevin Montalbo

All right. So I can imagine that a machine learning algorithm it can easily learn that an API that describes a data entity as last name might be referred to a surname in another API and automatically map it. So data mapping enrichment transformation, they can get a lot more complex than that. So how far do you think? Can we go with automation?

Zdenek “Z” Nemec

Well, we don't know what we don't know. But I think eventually we'll be very far, right? If you dream about the the interface is connected to your Neocortex, then you know, and do this some sort of reasoning then eventually and, and maybe singularity, then I think, you know, we as mankind get probably not the super face, probably not in the next decade. But I think we take, we can take it very far. That's, that's for sure. And, and we are learning in the process like how, how we do this and we do an awful lot of things manually, but we historically know that the automation and autonomy is actually the solution to the complexity. So when, when a lot, when a lot of people are doing something manually, then you know, then of course people start thinking about how to automate and how to give it an autonomy. And I think we are at this point with the APIs because of course, there is more and more stuff happening digitally, especially this year. And the number of APIs in the way we keep them together by hands is just, you know, not going to scale. So there is this urge for us to to, you know, take it further to start thinking about the automation so we can use the engineers to do a better work than just you know, doing the wires,

David Brown

The design side of things. So we talked about, you know, the client, how would automation change design of an API? Does it change at all?

Zdenek “Z” Nemec

It it it will, it, it but it will be the design of an API will be a secondary thing I think in the future, that's, that's, that's my thinking. So these design formats and will be like a secondary. Of course, you still care today about the design of a chip, about the, you know, the the assembly language and whatnot. But we are now thinking in a higher like most of the developers are thinking in a higher level than you know how the the assembly works or you know, the, the the chest design and whatnot. So there are of course, people and teams who are deeply taking care of the design of this sort of low, low level you know, hardware or languages, but most of the developers are operating on another level and I see this will happen with API. So the API design will be there, the API architectural styles will be there, but they will become more like a low level to, to, you know what the the majority of developers do is doing so as such, the design. Yes, it will be important but it won't be like,, you don't have a design experts in your company, you don't have your API designs right then you know, good luck having the customers or developers using your API. That should be the thing of the past because this is really an implementation problem. At the end of the day, the the name of the game should be, you know, what business capabilities your company offers, what are the commercials? Um Something related to this. Not if you are able to hire, you know, good enough API designers and technical writers to document on interface.

David Brown

I love it. You're turning on it on its head, you're turning, you're turning all the stuff which is being preached out there at the moment about this discovery languages and you know, focusing on design first and,

Zdenek “Z” Nemec

And I'm guilty, you know, like I'm guilty for for what we done and I'm guilty for you know, rest not being understood and the rest not being used as it was meant to use. We were, we, we as an api expert actually failed into, you know, advocating those principles, but it's time to, you know, just move past and say, OK, this didn't work. Let's let's you know, learn from this and, and, and move higher.

David Brown

It's not that it's not working, it's just that it's a learning process. And so in actual fact, significant gains have been made from innovations you and others have created. It's just that we're in the infancy of this, it was such early days. And so we just have to have such a long light guy.

Zdenek “Z” Nemec

And I know we call this medieval 2.0 you know, when we will be looking at what we are doing today. For maybe, you know, in 200 years, this would be like,, these guys are medieval, they were just manually connecting computers together.

Kevin Montalbo

Yeah. I would like to just jump on that thought because we're thinking here on a, like a change the mindset type of thing, you know, because Z is like, you're totally on a, on a different plane of thinking right now. due to the fact that you want to change the way we like consume APIs. And here in the show, we, we often talk to authors like Mike, a man and a friend of yours. I'm sure who explained to us the API story and James Higginbotham as well, who, who told us about the aligned define and design mentality. So there's always this human approach but is automation going to change all of that?

Zdenek “Z” Nemec

Yes and no. But th th this, this, this story approach that's definitely very valid, you know, but that, that goes back to the product ownership and APIs like what we were doing recently before I move into super phase. We were spending especially at the, you know, my, my favorite company, Adidas, we were spending a lot of advocacy and and evangelism on, on, hey, you know, API should be treated as a product. API should have a product owner and that's where the story is and personas and who are you building this for is actually very important, right? But again, if we go back to back to what I was saying before, like API will be this low level, low level thing is still very important, still have to have a proper design. Then you know, this product person, I will probably move higher on that level of abstraction. So the product person and the story of, of what your company is offering should be on the this business level and then, you know, only enabled by these technical interfaces. So, so the the the the user journey, the stories will be here, the program owners should be there. But I hope, you know, we make their life a little bit easier because we'll move higher up from the technical interfaces to the actual cases that you want to solve.

David Brown

Interesting, how about security and privacy? How are they, how are they going to change under, under this new world?

Zdenek “Z” Nemec

It will be a whole, whole new world like when you start to think about it in, in so many aspects. So as for the security, I think the biggest concern right now that we are having with with this autonomous integration match the super phase is really the trust because you have you will have a lot of elements, the clients, the consumers, the providers, you know, in this, in this network in this mesh and you need to of course establish the trust between them because they don't know each other. And so that's one aspect and of course, yy, you know the way the super face is designed, you are essentially running some code in your, on your client side, something similar that you are doing now with the web browsers. When all the web browsers are downloading all the javascript to do, you know something executing a remote code on your, on your computer. So you know, we need to of course, take a great care about that. So there are not, not some men in the middle attacks and whatnot. So there is this volume aspect of basically our clients running some other code from the outside. And then as as for the privacy goes, I think this will be actually a more um a private place to be if you will because you will no longer need this integration middleman, the, the services that you built, the layers in between that are of course adding latency. But you know, in case of some, you know, third parties, they might be a concern of, of, of privacy because you are in, you know, in this AI mesh because you are communicating directly between consumer and pro provider, there is no middle man except except maybe the internet issues in between you and the provider. So that might actually help with the, you know, feeling about the privacy and barrier that data are going true.

David Brown

The super interesting guest where, where are you at? Like with this whole process? Like when, when will we see something from super face launch? Do you think?

Zdenek “Z” Nemec

Very good question. So we, we aim at the Adelaide, Adelaide access Q 121 and open for public you know, 3-4 months later, depends on how that go. So we are, we are definitely ramping up hiring up hiring people and, and working on this as much as we can. But again, there was one part of building it, but then we need to evangelize, you know, hey, stop, stop, you know, coding AC TB calls. That's not what you need to do. Just start starting and start operating on another level. So that's, that's another part of what we are trying to do and evangelize and, and of course, thanks for having me because that also helps.

David Brown

Of course, and it's super face at AI is where everyone can follow you and no doubt, join your mailing list and stay in touch with what's going on there and your social accounts, how can they stay?

Zdenek “Z” Nemec

That will be the Twitter channels and whatnot. But you know how it is when you are at the start and you have so many things to do from the technology to social media

David Brown

That stuff comes later. 

Zdenek “Z” Nemec

It's just like probably won't see any of Christmas this year.

David Brown

Yeah, look, I think it's, you're doing amazing things. whole new world. Congratulations. Just the stuff that you are working on. It's amazing.

Zdenek “Z” Nemec

Thanks for your support. Thank you very much.

David Brown

Yeah, and we'll definitely be following your progress and seeing how we can adopt your thoughts and processes inside of what we're doing here at Toro as well.

Zdenek “Z” Nemec

Cool, cool. I appreciate it. Thank you.

David Brown

Thanks. It's great to have you on the show. Thank you.

Kevin Montalbo

All right, that's a wrap for this episode. Thank you very much, Z Nemec for being with us to our listeners. What did you think of this podcast episode? Any thoughts on automated APIs, let us know in the comments section from the podcast platform you're listening to. Also, please visit our website at www.torocloud.com for a transcript of this episode as well as our blogs and our products. We're also on social media, Facebook, LinkedIn, Youtube, Twitter and Instagram. You can talk to us there because we listen, just look for Toro Cloud again. Thank you very much for listening to us today. This has been Z Nemec, David Brown and Kevin Montalbo at your service for Coding over cocktails.