Are automated APIs the future? with Zdenek “Z” Nemec

Kevin Montalbo

Greetings internet, my name is Kevin Montalbo, Content Editor at Toro Cloud. In this episode of Cocktails, we talk to the founder of Superface.ai, a platform that promises to integrate APIs – without humans.

Of course, with me today is Toro Cloud’s 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 Superface.ai, revolutionizing how businesses connect digitally, empowering developers, and establishing autonomy for APIs. He also founded Good API, helping enterprises and startups to identify and build the right APIs for their business and was the former Director of DSL development at Apiary, 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 Zdenec Z. Nemec. We’re glad to have you, Z!

Zdenek Nemec

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

David Brown

Good day, Z.

Kevin Montalbo

In a previous article you wrote, you told readers that “the way we do APIs is broken beyond repair”. Can you share with us some challenges that the industry currently faces with regards to APIs and how these led you to start Superface.ai?

Zdenek Nemec

So, the reasons are twofold. One is a business approach to APIs, and then the other is of course technical. The first one, the relation between the business and IT can be fixed and it's improving, salespeople understanding APIs. 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 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 solve the versioning problem, solve the documentation. And basically they are holding everything with their bare hands and trying to keep the boat floating. But I don't think it's going to work with the increasing demand.

David Brown 

That's an interesting perspective from someone who authored a description language for APIs: Blueprint. Has the adoption of API description formats like Blueprint and the more recent OpenAPI and Async API – has that enabled better automation and discovery of APIs?

Zdenek Nemec

I think it did. It absolutely did. I think that was one of the revolutions, or we don't have to call it a revolution, but the change of thinking started, back in the days and Apiary, I think it was like 2012 or something. And there was a format called Swagger before Apiary where really we pushed people or we asked people to: “Okay, don't program first, stop and think and design your API up long before you start coding”. And so these formats gave us developers and architects the chance to think about APIs, but also 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 these API descriptions formats from their code. And we are seeing, it helps with the discovery because these developer portals, this API hops when the developer submits the API description formats, that definitely helps with the discovery.

David Brown

So, I know that with Superface, what you're trying to achieve is automation. So, my understanding is that okay, we have 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, that is the capacity for a machine to be able to pick up that API at someone else's API, do some sort of machine learning algorithm over the top of that, automatically map it and create services to connect the two. Is that the concept behind Superface?

Zdenek Nemec

In a way it is, but there is a fundamental change to this API description formats from the Superface standpoint and how we use them. The first thing is the problem with the current formats, including the one I have created was mixing two things together. [First], the business: so, what do you want to do or what the API can do, like “send text message”; and [second] the actual implementation. So, we have what should you be calling me to do or not now? So, right now, these two are in one document, in one description format. And as such, it's really difficult to understand what is what, and maybe abstract the way on the use case level and not get down into the implementation. So, that's one thing that Superface is actually doing, like splitting the two, right? You have, you have some notion of “business layer”, if you will, of what your API can do. And then the actual implementation, whether it's GraphQL or REST or anything else. So, that's one thing.

The other thing is we don't use these description formats at the runtime. There might be some, you know, very few examples, GraphQL schema can be introspected at the runtime, but we are not using the open API spec or API blueprint at the runtime these days. We use them at the design time to spin out the docs or, SDKs, or some tests, but we are not using these formats at the runtime. And that's a fundamental problem because we are baking everything into our code, into our clients, and then we deploy those clients. And then if something changes, they need to basically change the client or deploy, right? So, the difference with Superface is, of course you split the business and implementation, and then you actually share this information at the runtime, 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 through responding so far with Superface? What's their take on automated APIs?

Zdenek Nemec

Over the years, I’ve seen automation is actually a more cultural problem than technical.

So, there are two layers of this. One is automation and the other is autonomy. Over the years, I’ve seen automation actually a more cultural problem than technical, having this CI/CD approach and DevOps approach that takes actually more change culture or mindset or approach in the company than actually bringing some crazy new technologies. So, that's one thing, we still have to convince people that automation is good and helpful, and then you have this autonomy like, “Hey, you know, you can have clients that can self-heal that can self navigate.” That's something that people, of course, don't get at first. Then you get this denial, right? Like, especially when I talk to developers, like fellow developers, the first thing they do, and that's the nature of us developers, we try to break things, right?

Somebody presents you with something new and then they start thinking, “Hey, how did this work?” or, “Oh, this cannot work” or “What if?”, right? So, from the developer standpoint, we often hear, “This might not work” or “What if?”. If you talk to API experts, then most of them get it. They think something like this must happen. We see that we cannot have developers manually connecting to APIs if we are going to really get to some “AI future”. 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 told me about automatic healing in case there was a change to the API. So, the client can detect the change to the API at runtime and automatically adopt those changes and heal. But isn't the concept of an API as a contract doesn't change. So, what sort of changes are you talking about?

Zdenek Nemec

So, when you are a client, your contract should really be what you want to do as a business case. You don't care what the implementation is, at the end of the day. If you want to ship a container, fetch some information, or whatever, you care about those business use cases and not whether your provider of implementation, what API style or JSON format is just trending, right?

So, your contract should end in the business case, and then the rest is just the implementation detail. And 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 is what is causing a lot of problems.

Superface is getting into freedom to contract on the business case level. And don't worry about implementation that can change – that should change actually. And this, in hindsight, gives you the ability to switch the providers, because if they fulfill the same business case, then you are no longer tied to their actual implementation. Because you know it firsthand, integration costs a lot of money today. And 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 integration work.

David Brown 

There are so many variables. How are you managing all the variables associated with the different services and implementation and the operations?

Zdenek Nemec

Right. This is a huge topic, right? There are many things and we are starting small. So, we are starting with the technical interfaces or technical aspects of this. We are not yet looking into the business parts, like contracting, getting API, legal SLA. So, all that, that's a whole another box to be opened. So, we are now like, of course, divide and conquer. So, starting small and trying to teach that all the pers don't integrate with API, don't integrate with Twilio, integrate with “send message”. Okay. And that's the first like, bridge that we need to cross.

David Brown 

But 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 Nemec

No, not. We have basically one universal SDK where you use this SDK to talk in this business language, so, “send message”. And then the SDK will figure out through this concept of integration management we are talking about. So, what are the providers? You pick some providers and translate on the fly. In our world, there isn’t an integration platform in between. The translation from the business case to the actual API call is happening on the client side and this particular SDK.

David Brown 

Amazing. Are you picking particular use cases to begin with like a spike-send message with the example were going with?

Zdenek Nemec

A lot of burden with today's APIs is that we are building custom bespoke clients for every API.

That's correct. Yes, but we want to make this open so everybody can add their own use cases. And of course, the match to the provider. So, we are starting some selection of these use cases, for example: the send message or logistics use cases would be 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 client side, that will be an open source client. So, that one universal SDK, it's really doing most of the magic.

And when you think about it, a lot of burden with today's APIs is that we are building custom bespoke clients for every API. Like every single API, every single client for Salesforce APIs is bespoke. That's just ridiculous, right? It would be like writing bespoke web browsers. We don't do that. We have universal clients for the worldwide web, [which is] the most successful API. So, you have dozens of web browsers and they work with different applications.

David Brown

That's true. But you know, the description language, 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, then machine-generate it. And if the schema it changes, we can automate--

Zdenek Nemec

That’s the funny thing! You know what Google is trying to do! They are advocating “Hey, at the structured data and notate your HTML with JSON-LD, so we, as a Google search engine can actually understand what's going on on that HTML page”. So, Google is the first pushing in a web developers or whoever's making the websites to annotate the actual content in the HTML. So, it's meaningful for machines so Google can give you better results.

David Brown 

[laughs] You invented the description language!

Zdenek Nemec 

Well, before yes, but then – I know! But I'm still learning in the process, of course, meeting the people and observing this world. If you would meet me like 10 years ago, I would have this dream like, “Okay, hypermedia and REST is the right way to do it”. And over the years and years, I learned that --

David Brown

--that there’s a better way. It's amazing!

And obviously you're at the forefront of the thinking when you came out with Blueprint, quite possibly, you’re at the forefront of thinking now it's 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 RAML versus OpenAPI and Swagger. How do you see that play down? Why did Swagger and its evolution to OpenAPI seem to become the winner in the RESTful API Wars, and then competing formats, like GraphQL and Async API won different use cases?

Zdenek Nemec

They did an amazing thing with a Swagger and it’s of course, how to play it in the developers’ community. And they did this amazing move to move the Swagger, what was Swagger into the Linux foundation. Right? So, I guess the APRA, even though we built the API Blueprint and tooling around with this open source, it was always perceived as this company's language or this company DSL and component tooling, which was the same for all the other others that you mentioned. But they did this amazing move to move it into the Linux foundation, call it OpenAPI and create this OpenAPI Initiative, which is good! I think it's good that we have one format there that now is a de facto standard. Of course, when you have one multiple, you might be losing something, but that's good. But again, I think we need to move past these descriptions formats that are being used other design time only, and that are mixing the business and implementation.

Kevin Montalbo 

All right. So, I can imagine that with a machine learning algorithm, it can easily learn that an API that describes a data entity as “last name” might be referred to as “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 Nemec

We historically know that automation and autonomy is actually the solution to complexity... and I think we are at this point with APIs

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

David Brown 

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

Zdenek Nemec

It will. But the design of an API will be a secondary thing I think in the future. That's my thinking. So, these design formats will be like a secondary. Of course, you still care today about the design of a chip, about the assembly language, and whatnot. But we are now thinking higher – most of the developers are thinking in a higher level than how the assembly works or the cheapest design and whatnot. So, there are, of course, people and teams who are deeply taking care of the design of these sort of low level hardware or languages, but most of the developers are operating on another level. And I see this will happen with the 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 what the major developers are doing.

As such, the design, yes, it will be important, but it won't be like “Oh, you don't have a design experts in your company. You don't have your API design right? Then, you know, good luck having 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 name of the game should be “What business capabilities your company offers? What are the commercials?” Something related to this, not if you were able to hire good enough API designers and technical writers to document that interface.

David Brown

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

Zdenek Nemec

I know! I'm guilty for what we’ve done and I'm guilty for REST not being understood and the REST not being used as it was meant to. We as the API expert actually failed into advocating those principles, but it's time to just move past and say, “Okay, this didn't work. Let's learn from this and move higher.”

David Brown

It's not that it's not working. It's just that it's a learning process. So, in actual fact, significant gains have been made from the innovations you and others have created. It's just that, we're in the infancy of this, right? It's such early days. So we just had such a long way to go.

Zdenek Nemec

I know. We call this a Medieval 2.0, you know? When we will be looking at what you are doing today, maybe in 200 years, this will be like, “Oh, these guys in 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 like a “change the mindset type of thing”, because Z is like, you're totally on a different plane of thinking right now due to the fact that you want to change the way we consume APIs. And here in the show, we often talk to authors like Mike Amundsen, a friend of yours, I'm sure, who explained to us the API story and James Higginbotham as well who told us about the align, define and design mentality. So, there's always this human approach. But is automation going to change all of that?

Zdenek Nemec

Yes and no. But this story approach that's definitely very valid, that goes back to the product ownerships and APIs, like what we are doing recently before I moved into Superface, we were spending especially on my favorite company, I did ask, we were spending a lot of [inaudible] mentalism on “Hey, you know, API should be treated as a product, API should have a product owner.” And that's where the stories and personas and who are you building this for is actually very important. Right? But again, if we go back to what I was saying before, the API will be this 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 what your company is offering should be on the business level. And then only enabled by these technical interfaces. So, the user journey, the stories will be here. The programs should be there, but I hope, we’ll make their life a little bit easier because we'll move higher up from the technical interfaces to the actual cases that they want to solve.

David Brown 

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

Zdenek Nemec

There'll be a whole new world! Like when you start to think about it in so many aspects. So, as for the security, I think that the biggest concern right now that we are having with the autonomous integration mesh, the Superface, is really the trust. Because you will have a lot of elements, the clients, the consumers, the providers in this network, in this mesh, you need to of course establish the trust between them because they don't know each other.So that's one aspect.

And of course, the way the Superface is designed. You are essentially running some code on your client's side. Something similar that you are doing now with the web browsers, when all the web browsers are downloading, all the Java scripts do something, executing a remote code on your computer. So, we need to of course take great care about that. So they are not, not so many man-in-the-middle attacks and whatnot.

So there's this aspect of basically our clients running some other code from the outside. And then as for privacy goes, I think this will be actually a more private place to be, if you will. Because you will no longer need this integration middleman, the services that you built, the layers in between that are, of course, adding latency. But in case of some third parties, they might be a concern of a privacy because you are in this AI mesh because you are communicating directly between consumer and provider, there is no middleman except maybe the internet issues and between you and the provider. So, that might actually help with the feeling about the privacy and the barrier that data are going through.

David Brown 

Z. Super interesting guest. Where are you at, like with this whole process? When will we see something from Superface launch, do you think?

Zdenek Nemec

Very good question. We aim for Early Access Q1-2021, and open for the public, three, four months later, depends on how that goes. So, we are definitely ramping up, hiring people, and working on this as much as we can. But again, there was one part of building it, but then we need to evangelize. “Hey, stop, stop, you know, coding __ calls, because that's not what you need to do. Just start operating on another level.” So that's, that's another part of what we are trying to do and evangelize, and of course, thanks for having me, because that also helps.

David Brown

Of course, and Superface.AI is where everyone can follow you and no doubt join a mailing list and can stay in touch with what's going on there and your social accounts. How can they stay connected?

Zdenek Nemec 

That would be Twitter, SuperfaceAI as well, and LinkedIn the same. So we asked, we are in the process of relaunching the website with more information and starting the media 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 the social media.

David Brown 

[laughs] Yeah. That stuff comes later.

Zdenek Nemec

I probably won't see any Christmas this year.

David Brown

Yeah. Look, I think it's, you're doing amazing things – a whole new world. Congratulations. Just this stuff you're working on. It's amazing.

Zdenek Nemec

Thanks for your support. Thank you very much.

David Brown

Yeah. 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 Nemec

Cool. I appreciate it, thank you!

David Brown

Thanks Z. Great to have you on the show!

Zdenek Nemec

Thank you!

Kevin Montalbo

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 our blogs and our products. We’re also on social media, Facebook, LinkedIn, YouTube, Twitter, and Instagram. Talk to us there, we’ll 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.