Aaren Quiambao

Welcome to Coding over cocktails, a podcast by Toro Cloud. Here we talk about digital transformation, application integration, low code application, development, data management, and business process automation. Catch some expert insights as we sit down with industry leaders who share tips on how enterprises can take on the challenge of digital transformation. Take a seat. Join us for a round here are your hosts, Kevin Montalbo and Toro Cloud CEO and founder David Brown.

Kevin Montalbo

All right. Joining us today from Sydney Australia is Toro Cloud CEO and founder David Brown. Good day, David 

David Brown

Good Day, Kevin. 

Kevin Montalbo

All right. And our guest for today is a well known tech journalist who tracks the API economy as well as covers Devops topics and analyzes state of the art technologies in the enterprise cloud software space. He's the editor in chief for Nordic APIs, an API event company that also runs a high impact blog on API Practice, interviewing key players and sharing insights through his evergreen articles has been featured in several publications such as programmable web tech beacon, Devops.com container journal, cmo.com, read, write and many more. He also speaks at API conferences, online events and podcasts such as this one. Ladies and gentlemen, joining us today for coding over cocktails is Bill Doerrfeld. Hi, Bill. It's great to have you on the show. How are you doing?

Bill Doerrfeld

Hi, Kevin. Doing well. Thanks for having me. Thanks for the introduction.

Kevin Montalbo

All right, great. So we'll jump right into the questions, Bill. We want to talk about Nordic API first. So Nordic APIs was founded in 2013 and you became editor in chief in 2015. So what were the founders objectives for Nordic APIs? And has the scope changed over the years?

Bill Doerrfeld

Yeah. So like you said, those, those founders it was Travis Spencer and Andreas Kr and they co-founded Nordic APIs back in 2013. So a couple of years before I entered the picture there, and the mission kind of has always been to help disseminate knowledge, to help the world become more programmable through the use of APIs and API strategy. And at that time, the whole idea of like becoming a platform was pretty novel and companies were looking, looking to this model to kind of reinvent themselves and see what sort of new businesses could be created and how, you know, you could streamline internal operation using API first strategies. 

So yeah, there's a lot of interesting knowledge at that time and there wasn't really an API conference series happening in the Nordic region, which is where the founders ended up. And so this was kind of built to fill that gap and then I, I came across them just online and you know, being a journalist and an editor ended up helping out with their blog. So I've been more on the content side of things for them, helping, you know, manage a lot of ebooks and blog posts and working with writers and, and con contributors to the space to, yeah, help kind of increased knowledge around APIs

David Brown

And the founders did they have a background in APIs, what drove them to set up Nordic APIs in the first place?

Bill Doerrfeld

Yeah. So Travis Spencer, he's an identity specialist and his company is now pity. And at that time they were doing more consulting now they have a fully fledged service company and Andreas is more in the API design kind of consulting spectrum. At least that's when he was founding, co-founding Nordic APIs. So, yeah, a lot of background in that space and knowledge of what was happening at that time.

David Brown

And of course security for those who are not familiar, do amazing work in authentication with space particularly.

Bill Doerrfeld

Yeah. Yeah, they're doing some really, really cool stuff and I, I should mention they're a, they're a organizer and sponsor involved with Nordic APIs . But yeah, they're doing some innovative stuff especially around like I think the last thing they're working on was integrating hypermedia into the hypermedia driven security for Yeah, and API design around authentication, which is interesting. 

David Brown

Yeah, they're always pushing the boundaries. Yeah, exactly. So look, nor does Nordic APIs covers a very broad range of API related topics from specifications, standards, security and architecture. Were you already familiar with these topics when you joined Nordic Apis or did you have to learn real fast?

Bill Doerrfeld

I was already somewhat familiar. My first kind of eye opening moment was when I was trying to design an app and it totally failed. We like did this Kickstarter and everything. It was a part of a college course which I took really seriously and brought it off campus with some, some people and we tried to make it happen but it didn't end up working. But, one of the co-founders, Andy, he was like,, what, how about we just use the Venmo APIto solve this payments issue? And I was like, what the hell is that? And, you look it up and you, you see things like active pharmaceuticals, ingredients, all these acronyms that, you know, have nothing to do with application program, c programming interface. And then a few months later, I ended up doing a lot of work with programmable web and just researching a lot of APIs and cataloging a lot for their directory, which really turned me on to the whole industry. And I just realized how fascinating this was that they're, you know, creating all this reusable technology and literally helping people not re invent the wheel from like all these different business opera operations that you could just plug and play into it, you know, your own application. 

So that really seemed like where things were heading and, you know, and I wanted to, to be a part of it. So that's kind of how I got started. And so before I got into Nordic APIs editor in chief, I had a, a basic, you know, baseline understanding, but really, I had to keep asking questions and I think that's what drove things forward, like realizing what I personally didn't understand about the space, really helped me realize what other newcomers wouldn't readily understand as well. And so I actually just assigned those kind of questions to our writers, you know, like, what is oo what is rate limiting? What does versioning mean? What are the rest constraints? So just kind of realizing what I personally didn't understand. And you, you know, I was able to kind of build that knowledge and actually recommend that to anyone who's in charge of any sort of blog presence or thought leadership channel, like recognizing what you don't know and like owning up to it and being proud of that . That can be a strategy to, you know, avoid imposter syndrome and like, just realize what you need to improve on. So, we're, we're, we're always trying to improve our knowledge of the space. And yeah, I'm proud of the body of work we've assembled, but really owe it to the good founding direction and awesome contributors and, and writers.

David Brown

So whilst, whilst you have a broad range of subjects related to APIs, some you know, a little bit further afi like microservices, architecture and the like, but do you ultimately, you're covering APIs, you've been doing it for six years. Do you find it hard to keep finding new things to write about?

Bill Doerrfeld

You would think that you would, right. I've been surprised how easily it is to keep on going. You like crack open an an onion and then you peel back the layers and then you realize there's like 100 more onions in that onion. So it's kind of like the deeper you go down the rabbit hole, the weirder it gets and the more questions you have and even if you did learn everything, it would kind of be null and void a few months later, just with how fast the technological space you know, progresses. So every everyone's always evolving. 

I know some of your questions are about like new trends and standards which I'm sure we'll cover. So yeah, I think that's part of it just, and also there's like so many great minds trying to solve these problems that we're experiencing with things like, you know, linting open API specifications. Well, that's a very like nuanced concept and only relevant, you know, I don't know, 2016 onwards. So there's so many new packages being developed and then those need to be put to the test or we're doing round ups of like a bunch of different comp compare comparative technologies. So yeah, there's a lot to cover.

David Brown

Interesting, let's discuss how the industry has changed . So over the last six years, you would have seen a lot of evolution in the space. have you seen, I'm guessing you've seen specifications change new standards emerge. What is, what's the sort of things you've experienced over those six years?

Bill Doerrfeld

I would say the most significant change I've noticed is the emphasis on developer experience. When I first entered this space. This was a very novel concept that not many people were acknowledging or thinking about really. So you would kind of just publish an APIdocumentation to some sort of web portal. People weren't even really calling it developer portals at that time. And the standards were different, the design looked a lot different . Just not, not only visually, but they were using like soap and XML and kind of holdovers from . So a days which was like before my time, I can't even talk about it fluently which you know, shows the evolution of the space here. So yeah, and doing some of that work with programmable web, just reviewing all these documentations and realizing how difficult it was like for someone coming from a more business perspective just to understand what the tech was doing. 

But nowadays, interfaces are a lot prettier. There's more testing sandboxes, there's better use of like these sleek dark mode filled developer experiences for these APIs and the providers are really putting effort to make these services way more self-service, especially with the whole rise of like the API as a product trend, which we've been following on the blog and working on an ebook toward that soon too. So, yeah, I've, I've noticed that as a, as a big movement lately, especially, it seems like, you know, emblazoned by the success of Twilio and Nili Sky Flow Shopify. 

There's been like API first companies, literally IPO which is you know, people are wondering like if there's a next API based unicorn out there for some other sort of sector that hasn't really been covered yet. So there's been a huge proliferation of that sort of API is a product concept and people trying to put that to the test, create new business models, which is super interesting . Yeah, II I could go on, there's the, there's a lot with standardization, you know, style guides, a lot of funding in the sector. There's a, there's a lot that's evolved in just a mere six years.

David Brown

And of course, that developer experience, you started a programmable web and, and they wanted to facilitate discovery of APIs by creating a directory of APIs. It kind of reminds me of Yahoo though, like, you know, humans sort of creating this directory listing of API services that are available and documenting them. And ultimately, of course, Yahoo's directory was supplanted by Google and the like. So is the future more self discovery of APIs better indexing of API

Bill Doerrfeld

I was just talking about someone about this today actually with David fromAPImetrics and we were kind of fiddling with the idea that discovery will essentially be solved. The same way, Google has approached discovery for every other, you know, day items out there. You could totally see using metadata from an open API specification to simply populate a card that Google shows . you know, as a drop down, of course, having these directories is super important for comparative analysis, being able to like see performance rates, making sure Slslas are being met comparing like different security nuances between services and of course like pricing. So that's where these marketplaces and discovery platforms, like you mentioned programmable web, there's APIdiscovery, there's rapid API of course, I think that's where you know, their their big value is it it's not like searching for these services because like you said, someone could just do that do that on Google and not really supplanting anything in that way. But yeah, giving some more analysis and comparative lens between the services. I see value in it still with that.

David Brown

Yeah, I mean, it can be enormous value that's been proven in spaces of shopping comparison engines for insurance or car loans or whatever it may be. So it can equally apply to the API space, right? There's still be your conference . Was the conference always part of the strategy with Nordic API is when did, when did the conference start?

Bill Doerrfeld

Yeah, the, the definitely the, I think they had their first platform summit in 2013 and since then, had been holding the platform summit every year. Of course, until COVID hit, I should preface that. I'm a bit distanced from the actual physical conference planning. I'm more on the content side of things like the blog ebook, live casts and the Stockholm, the Stockholm based platform summit and the new Austin Api summit are organized by C and there's some awesome people kind of taking the helm with that Simon Anderson, Victoria and Stan through cur who is helping to organize those events. 

So, yeah, it's been based in Sweden. It's been about, I'd say in the fall and winter every year since then, aside from 2020 then in 2018, we took the conference to Austin and we did a few Austin API summits and basically just copy and pasted the same format there. And it's been growing since and it's been doing really well and can't really confirm or deny any exact event plans at this point go for the future. But I know that the team is eager for it all to resume once it's safe to do so.

David Brown

Right. So we will get back to the intention is to get back to face to face conferences.

Bill Doerrfeld

Yeah, as far as I know, I think that's still the plan.

David Brown

Yeah and when you took it to the US market, I mean, you would think you're taking an enormous opportunity there with an enormous market. Did it supplant the Sweden based conference in terms of size? Is it difficult to enter that market? I'm sure it has very different dynamics.

Bill Doerrfeld

That's a great question. I think the way that people kind of interact maybe is a little bit differently in Europe as opposed to in the US. people maybe are a little bit more like boisterous and informal in Austin as opposed to in Stockholm. So I noticed that, but our industry is so global at this point. The best practices and a lot of the same speakers were at both, but I wouldn't say that one event was, you know, supplanting the other at all. There's plenty of knowledge to go around and plenty of people interested in both that were coming out. But yeah, obviously a great advantage of taking a conference on the road is that you can go to people where they are and they just get more interested people involved in the community.

David Brown

Yeah, the Sweden based conference ties up nicely with SAS Stock in Dublin. It's almost back to back. So I normally do the SAS conference in Dublin and I was able to do the Nordic ABIs conference straight after that. Yeah, obviously the last year or the year before. What are the current trends you're seeing from industry bodies? We have, when I say industry bodies, we have standards, organizations like open API . and I guess API solution providers themselves are also pushing the space. What are the trends you're seeing from these bodies and solution providers?

Bill Doerrfeld

So I already mentioned API is a product that's been an evolving trend for people looking to like externalize APIs as reusable products. But there's also the internal use case. Building API first kind of follows the whole like Bezos mandate of externalization from day one kind of using that even for your internal offerings as well, adopting that mindset . So, you know, that's been, I think in the background of a lot of people's minds and architects minds. There's also been as I'm sure your listeners are well aware, the sort of revolution from the monolithic architecture to this more decentralized decoupled microservices approach. And I've seen a lot of the solutions in our industry now providing ways to try and tackle the repercussions of all of that. So once you have a distributed, you know, microservices architecture environment, how do you centrally manage a fleet of thousands of microservices and apply common things like role based, role based access and security and monitoring, routing and communication between those microservices. 

So, yeah, I've seen a lot of the solutions kind of flip flop and try to centralize a decentralized state. So that's kind of interesting to see the strategy behind all that emerge . We're also seeing a lot of trend toward multi cloud and, you know, everyone pushed a lot of their offerings to the cloud and the cloud is a huge rising component of the last decade . And we also saw a lot of cloud service providers, you know, acquire a bunch of these leading API managers in the last decade or more. But now we're seeing more people see benefits of adopting multiple clouds and seeing like where the edge of one cloud might not compare to the edge of another . So adopting standards to help deal with that in an agnostic way, I think people are kind of thinking about that as well . There, there's just a lot of different trends in in different parts of the industry here.

David Brown

Has there been more certainty provided over API design, particularly restful API si remember earlier in the last decade, there was a lot of competing description formats for restful APIs. We had Ramel and blueprint and swagger and a number of other formats for describing APIs has that settled down a bit and some winners emerging

Bill Doerrfeld

It's settled down significantly, I would say open API specification, you know, became the king from those spec wars if you will. Yeah, so open API initiative. Now, part of the Linux Foundation seems to be setting course for designing restful services . You might make the argument that GraphQL has emerged, you know, and sure I see them as complementary or rather, you know, being used for different use cases, you could have a GraphQL layer over or Rest API there's nothing really stopping you from doing that. GraphQL has some limitations with like native caching and doesn't really handle like hypermedia all that well . awesome for data retrieval and just working with a lot of database mechanics and you know, getting what exactly the client needs and not over fetching or under fetching. 

A GraphQL is great at that . Yet I still see rest as the industry standard, you know, working with an HTTP API and like serving JSON payloads, rest works very well for that. 

And like the whole open banking movement, for example, has embraced the rest format. For the most part, it seems you know, fielding designed it to work on the scale of decades. And I think we are seeing that actually function in practice simultaneously, there's a lot going on with event driven new architectures and asynchronous communication. A lot of these involve different protocols and these communications are just, you know, built very differently, they're structured differently. And so we've seen async API rise as a new paradigm for explaining those types of services. And it's kind of a, a different approach. It's complimentary if you will on the side of the Open API initiative. So I, those two in my mind are some of the, the biggest like documentation or definition setting bodies in the API space today.

David Brown

Yeah, I mean, it's interesting but you've mentioned a few there open API AC KPI and GraphQL. Some people see these as competitors solving the same problem. But from what you said, that's not necessarily the case that they might be better suited to solving different problems, right?

Bill Doerrfeld

Yeah, that's correct. Yeah, that's my cursory view on it. And we've done a lot of deep dives into this on the blog if you'd like to, you know, see some comparisons of these in practice and what the experts recommend for different situations.

David Brown

So whilst, whilst we've seen some consolidation in the description formats for rest APIS and as you say, OpenAPI was, was the winner in that space. We have seen the emergence of new description formats for different types of APIS, like you say the event driven based architecture with AC KPI and GraphQL. So the API space is still maturing, there's still new solutions coming out solving different problems. And of course, we have like web events for remote based event based architecture as well. So the, the, the the industry is still evolving whilst rest APIs seems to be solved a lot of use cases and probably the biggest solution in the marketplace, there's still a lot of other solutions out there for different problem sets.

Bill Doerrfeld

Yeah, completely agree. Yeah, if you would like to be involved, you know, I recently kind of did a write up on different standards bodies and their practices on, you know, inviting members to participate in these new formats . Some stuff is even being like designed by I ETF kind of working with HTTP APIs and seeing if there's like anything in the headers that we should be considering or standardizing . There's similar things going on with like W three C and they're working on a web of things, interest group kind of considering the more iot things level approach to semantic descriptions for APIS. And yeah, there's, there's a lot more just be beyond just the open API and async.

David Brown

It is of course open API as an industry body is has some funding and some big companies as sponsors. Do you see some sort of consolidation in the space where some of these description formats for different solutions like async API, for example, come under the umbrella of a single body.

Bill Doerrfeld

Yeah, I think we did see that with the consolidation with the Linux Foundation now overseeing Open API, who knows what the future will hold for merging that with other specifications. I know open API and version three, you know, they're adopting a way to describe web hooks and some other things that might blend into other situations . More like Jason schema support and whatnot. So, yeah, I, I'd say they are considering these sort of fringes and considering how they can adopt it into open API but at the same time, they need to consider what works for documenting the most cases, kind of that classic 8020 rule . I'm sure you've like hosted Darryl Miller on the podcast, right? If not., ok. If not, he would be an awesome person to get involved to speak to exactly what the open APIs mission is and how they're working to like evolve the specification.

David Brown

Yeah, we've had of course, the API evangelist API initiative with the show and, and of course, we're members of the Open API initiative ourselves as to cloud. So we have some sort of insight as to what the open API initiative is pursuing. And our feeling is that there probably will be some sort of consolidation. Some of these standards are looking for a home if you like, whether they, whether that's a Linux foundation home or, or, or some or so independently under the Linux Foundation or come under the openAPI umbrella that remains to be seen, but I think there's perhaps an opportunity for some consolidation there. You know, it's takes resources to build and promote these standards, right? So efficiency is there to be seen,

Bill Doerrfeld

Not ruling it. We'll see what happens.

David Brown

We'll see what happens. So look what's, what's the future? I mean, obviously you mentioned micro services and I briefly mentioned web events or, you know, remote based events. We've also had people on the program talking about automatic discovery consumption of APIs with machine consumption of APIs. What, where are we going is GRPC going to overtake microservices and is the future, you know, web events with auto discovery of APIs consumption? Where is this? Where is all this heading?

Bill Doerrfeld

I, yeah, I've noticed a lot of interest in GR PCI I could see further architectures being built with that as a, you know, you know, the communication support layer, I can completely see that for supporting more microservices delivery . But in general talking about where the API space is heading . You know, we have great functionality out there, we have like container based architecture, serving these great microservices and everything's API connected or possibly API connected. But like I said earlier, I think the developer experience is something we really need to consider and put more effort into and also making these APIs more consumable by a larger market. And what I mean by that is opening them up to citizen developers and you know, low code platforms, ways that we can extend the power of APIs to the, you know, the more the business folks could be very interesting in growing the space I believe. 

And once we do that, once we loop more of those kind of minds in the conversation, A lot of what needs to be tracked is more like, how does this affect the overall business or what is the security at, at, at hand where we start looking at more like metrics and performances of these APIs as opposed to just, you know, does it get the job done? I feel like the standards have risen significantly. So if we're, you know, out on the market, choosing something to purchase, there's a lot of options now and it's going to come down to which not only solves the function at hand and can deliver, but which does it in the most streamlined way with the best experience for developers and which is the most secure. So I think standards have risen like that and we'll just see these sort of API based products continue to refine themselves based off of those standards.

David Brown

Yeah, because we had the comment on the program in the past that, you know, at this stage of development of APIs, we're really sort of working on the plumbing we're working on, specifications, standards of security. And answering those questions and coming up with ways to define and ways to do things. But ultimately, the plumbing should be a problem which is largely solved and should really disappear into the background. And we should be focusing more on like you say, the developer experience and, and the API is just a mechanism that we just, you don't even think about anymore. It's just the way we do things.

Bill Doerrfeld

I think it's something that the general public still doesn't understand and probably will never understand because it's more of a base layer of plumbing there and maybe there's no reason for them to you mentioned consolidation earlier on the program. But you were talking about in terms of like specifications . The same is kind of being attempted by companies who are trying to consolidate like a bunch of APIs in the same sector into one single endpoint. Like we're seeing this for like looping in a bunch of CRM APIs or banking APIs. So they're calling it the universal API. There's a couple of these providers out there attempting this, which is pretty interesting because like aggregators who need to who want like all the weather data out there, you know, and they don't want to like refine the output and make sure it's perfect . They might want to integrate a lot of these similar services. So who knows? And eventually we might have one API for weather for the entire earth.

David Brown

Yeah, I mean we we do it for cloud based services, right? So we abstract the APIs of cloud based services so that you can have a single API to provision, compute or storage. So it's not an insurmountable problem to do a similar thing for APIs. You do have different database, yeah, entity descriptions and and formats. So you know, some APIs will return different data to others and it creates complexities how you manage those data issues. But from a technical perspective, there's no reason in fact, that's common practice even internally to abstract your own APIs. So the concept of a abstracting public APIs is is not that much of a stretch. It's really just a case of managing the data and how you consolidate that data and being returning it from these different formats. 

Weather is probably a relatively easy one because there are not so many attributes of those entities of how to describe weather. But a CRM for example, you know, you can describe a contact record or a company record in in so many different ways in so many different formats. And I think Microsoft is probably trying to solve that problem with its alliance with Sap and Adobe with the common data model which we also embraced with a product called Negroni at Toro Cloud that and so to standardize on actually the data entities as well. So maybe that forms part of the solution as well whereby that might make it easier for those API providers to abstract them.

Bill Doerrfeld

I completely agree. I think it does kind of boil down to that common data model. And once there's more standards then, yeah, this is far more feasible. I like how you phrase it as an abstraction layer, I think. Yeah, that's exactly what we're talking about. And well, we're gonna see the future of the abstraction layer for the API continue to become more accessible.

David Brown: Bill Doerrfeld, It's been a pleasure to have you on the program. How can our listeners follow you what you write about and what you do? Yeah.

Bill Doerrfeld

Sure. Well, first off, you can follow Nordic APIs anywhere on social media or just go to the site. And we have a great newsletter. I pump out like six articles every two weeks on everything API is recovering strategy, security design platform, education, a lot of different topics. And I'm also doing a monthly live casts series, kind of similar to this podcast, but with a couple presentations involved and we're tackling specific topics. So yeah, that's something to keep an eye out for. If you like to follow up with my writing and track what I'm doing personally, you can go to Twitter, would be the best at Door Feld Bill. That's my tag.

David Brown

Great. Thank you, Bill.

Bill Doerrfeld

Great. Thanks so much for having me, really fun to nerd out on everything. API

Kevin Montalbo

All right, that's a wrap for this episode of Coding over cocktails to our listeners. What did you think of this episode? Let us know in the comments section from the podcast platform you're listening to. Also, please visit our website at triple W dot toro cloud.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. Talk to us there because we listen, just look for Toro Cloud on behalf of the team here at Toro Cloud. Thank you very much for listening to us today. This has been Kevin Montalbo for coding over cocktails. Cheers.