Making the World Become More Programmable With Bill Doerrfeld [Podcast]
Learn about the current trends within the API space, the different API styles and specifications that have emerged and insights as to how APIs can move the industry forward.
Join the DZone community and get the full member experience.Join For Free
"Make the world become more programmable."
That’s the goal of Nordic APIs, which holds a series of conferences and events throughout Scandinavia and, more recently, the US, to help organizations make smarter tech decisions and streamline their operations through APIs and strategies. Their work explores the API sector and sheds to light various emerging technologies and trends through their events and blogs.
In this round of Cocktails, we have Nordic APIs’ editor-in-chief, who gives us an insider perspective behind their work at Nordic APIs. We also dive into the current trends within the API space, where we talk about the different API styles and specifications that have emerged, some exciting prospects and innovations from industry bodies and providers, as well as some interesting insights as to how APIs can move the industry forward.
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!
KM: 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 NordicAPIs, an API event company that also runs a high-impact blog on API practice. Interviewing key players, and sharing insights through his evergreen articles, he’s been featured in several publications such as ProgrammableWeb, Tech Beacon, DevOps.com, Container Journal, CMO.com, ReadWrite, 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.
KM: All right, great. So, we'll jump right into the questions, Bill. We want to talk about Nordic APIs first. So Nordic APIs was founded in 2013 and you became editor-in-chief in 2015. So, what were the founder's objectives for Nordic APIs, and has the scope changed over the years?
BD: Yeah, like you said, those founders, it was Travis Spencer and Andreas Krohn and they co-founded Nordic APIs back in 2013. 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 becoming a platform was pretty novel. And companies were looking to this model to kind of reinvent themselves and see what sort of new businesses could be created and how you could streamline internal operations using API-first strategies.
So, yeah, there was 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 came across them just online and you know, being a journalist and an editor, ended up helping out with their blogs. So, I've been more on the content side of things for them, helping manage a lot of eBooks and blog posts and working with writers and contributors to the space to help increase knowledge around APIs.
DB: So did they have a background in APIs? What drove them to set up Nordic APIs in the first place?
BD: Yeah, so Travis Spencer, he's an identity specialist and his company is now Curity 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 consulting spectrum. At least that's when he was founding or co-founding Nordic APIs. So yeah, a lot of background in that space and knowledge of what was happening at that time.
DB: Curity, for those that aren't familiar with them, do amazing work in the authentication space, particularly.
BD: Yeah. They're doing some really, really cool stuff. And I should mention their organizer and sponsor involved with Nordic API APIs. But yeah, they're doing some innovative stuff. I think the last thing they were working on was integrating hypermedia into the hypermedia-driven security for an API design around authentication, which is interesting.
DB: Yeah. They're always pushing the boundaries. So, 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?
BD: 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 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 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, "Oh, well, how about we just use the Venmo API to solve this payments issue?" And I was like, what the hell is that? And you look it up, you see things like "active pharmaceutical ingredients", all of these acronyms that have nothing to do with application programming interface. And then a few months later, I ended up doing a lot of work with ProgrammableWeb 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 reinvent the wheel from all these different business operations that you could just plug and play into your own application. That really seemed like where things were heading and I wanted to be a part of it. So, that's kind of how I got started. And so before I got into Nordic API's editor-in-chief thing, I had a basic 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 actually, just assigned those kinds of questions to our writers, you know, like, "What is OAuth?", "What is rate-limiting?", "What does versioning mean?", "What are the REST constraints?"
So, just realizing what I personally didn't understand and I was able to build that knowledge, And I actually recommend that to anyone who's in charge of any sort of blog presence or thought leadership channel. Recognizing what you don't know and owning up to it and being proud of that can be a strategy to avoid imposter syndrome and realize what you need to improve on. So 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 I really owe it to the good founding direction and awesome contributors and writers.
DB: So, whilst you have a broad range of subjects related to APIs, then a little bit further in the field like microservices architecture and the like, but 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?
BD: You would think that you would, right?
BD: I've been surprised how easy it is to keep ongoing. You crack open an onion and then you peel back the layers and then you realize there's like a hundred 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 be null and void a few months later, just with how fast the technological space progresses. Everyone's always evolving. I know some of your questions are about new trends and standards, which I'm sure we'll cover. So, yeah, I think that's part of it.
Also, there's like so many great minds trying to solve these problems that we're experiencing with things like linting OpenAPI specifications. Well, that's a very nuanced concept and only relevant, [from] 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 roundups of like a bunch of different comparable comparative technologies. So yeah, there's a lot to cover.
DB: 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. How have you seen, I'm guessing you've seen specifications change, new standards emerge, what's the sort of things you've experienced over those six years?
BD: I'd say the most significant change I've noticed is the emphasis on developer experience. And 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 API documentation 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 not only visually, but they were using SOAP and XML and kind of holdovers from SOA days, which was before my time. I can't even talk about it fluently, which shows the evolution of the space here. And doing some of that work with ProgrammableWeb, just reviewing all these documentations and realizing how difficult it was 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 the sleek dark mode-filled developer experiences for these APIs. And the providers are really putting effort to make the services way more self-service, especially with the whole rise of the API-as-a-product trend, which we've been following on the blog, and we’re working on an ebook toward that soon, too. So, yeah, I've noticed that as a big movement lately, emblazoned by the success of Twilio and Nylas, Skyflow, Shopify - there's been like API first companies literally IPOing, which is, you know, people are wondering 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-as-a-product concept and people trying to put that to the test to create new business models, which is super interesting. Yeah, I could go on. There's a lot with standardization, style guides, a lot of funding in the sector. There's a lot that's evolved and in just a mere six years.
DB: And of course, that developer experience, you started ProgrammableWeb and they wanted to facilitate discovery APIs by creating a directory of APIs. It kind of reminds me of Yahoo though. You know, humans creating this directory listing of API services that are available, documenting them. And, ultimately of course Yahoo's directory was supplanted by Google. So, is the future more of self-discovery of APIs? Better indexing APIs?
BD: I was just talking to someone about this today, actually with David from APImetrics. 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 items out there. I could totally see using metadata from an OpenAPI specification to simply populate a card that Google shows as a dropdown. Of course, having these directories is super important for comparative analysis. Being able to see performance rates, making sure asset SLAs are being met, comparing different security nuances between services, and of course pricing. You mentioned ProgrammableWeb, there's API discovery, there's RapidAPI. Of course, I think that's where their big value is. It's not like searching for these services because like you said, someone could just do that on Google. And it's not really supplanting anything in that way, but yeah. Giving some more analysis and a comparative lens between the services. I see value in it still with that.
DB: Yeah. I mean, it can be of enormous value. This has 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? Was the conference always part of the strategy with Nordic APIs? When did the conference start?
BD: Yeah, definitely. I think they had their first platform summit in 2013. And since then, they 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, livecasts, and Stockholm-based platform summit, and the new Austin API Summit are organized by Curity. And there's some awesome people taking the helm with that, Simon Anderson, Victoria, and Stefan, through Curity 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, and 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 I can't really confirm or deny any exact event plans at this point for the future. But I know that the team is eager for it all to resume once it's safe to do so.
DB: Right. The intention is to get back to face-to-face conferences.
BD: Yeah. As far as I know, I think that's still the plan.
DB: And when you took it to the US market, I mean, you would think you're taking, you know, an enormous opportunity there with an enormous market. What 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.
BD: Yeah. That's a great question. I think the way that people kind of interact, maybe it's a little bit different in Europe, as opposed to in the US. People maybe a little bit more 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 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 with people involved in the community.
DB: The Sweden-based conference ties up nicely with SaaStock in Dublin. They're almost back-to-back. So, I attended the SaaStock conference in Dublin and I was able to do the NordicAPIs conference straight after that.
Last year, the year before, what are the current trends you're seeing from industry bodies? When we say industry bodies, we have standards, organizations like OpenAPI 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?
BD: So I already mentioned API-as-a-product. That's been an evolving trend for people looking to externalize APIs as reusable products, but there's also the internal use case. Building API-first kind of follows the whole 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 back of a lot of people's minds and architect's 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 microservices architecture environment, how do you centrally manage a fleet of thousands of microservices and apply common things like 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. That's kind of interesting to see, you know, the strategy behind all that emerge. We're also seeing a lot of trend towards multi-cloud and everyone pushed a lot of their offerings to the cloud and the cloud is a huge rising component over 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 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's just a lot of different trends and in different parts of the industry here.
DB: Has there been more certainty provided over API design, particularly RESTful APIs? I remember earlier, in the last decade, there were a lot of competing description formats for RESTful API. We had RAML and Blueprint and Swagger and a number of other formats for describing APIs. Has that settled down a bit and is someone emerging?
BD: It's settled down significantly. I would say OpenAPI specification became the king from those spec wars if you will. So, OpenAPI 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 and sure I see them as complementary or rather being used for different use cases. You could have a GraphQL layer over a REST API. There's nothing really stopping you from doing that. GraphQL has some limitations with native caching and doesn't really handle 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 overfetching or underfetching. GraphQL is great at that. Yet I still see REST as the industry standard. You know, working with an HTTP API and serving JSON payloads, REST works very well for that.
And like the whole OpenBanking movement, for example, has embraced the REST format for the most part it seems. Design it to work on the scale of decades. And I think we are seeing that actually functioning 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 built very differently, they're structured differently. And so we've seen Async API rises as a new paradigm for explaining those types of services. And it's kind of a different approach. It's complimentary, if you will, on the side of the OpenAPI initiative. So, those two in my mind are some of the biggest documentation or definition setting bodies in the API space today.
DB: Yeah. I mean, it's interesting, you've mentioned a few, the OpenAPI, Async API, and GraphQL. Some people see these as competitors solving the same problem, but from what you said, that's not necessarily the case and that they might be better suited to solving different problems. Right?
BD: Yeah, that's correct. 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 see some comparisons of these in practice and what the experts recommend for different situations.
DB: So whilst we've seen some consolidation in the description formats for REST APIs, and they say OpenAPI 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 with Async API and GraphQL. So the API space is still maturing. There's still new solutions coming out, solving different problems. Of course, we have, like, WebEvents for remote-based, event-based architecture as well. So, the industry is still evolving whilst REST API seems to solve 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 problems there.
BD: Yeah. Completely agree. I was just going to say, 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 designed by [inaudible] 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 some similar things going on with like W3C 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 a lot more beyond just the OpenAPI and Async.
DB: Of course, OpenAPI as an industry body has some funding and some big companies that sponsor them. 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?
BD: Yeah, I think we did see that with the consolidation, with the Linux foundation now overseeing OpenAPI. Who knows what the future will hold for merging that with other specifications. I know OpenAPI v.3, they're adopting a way to describe webhooks and some other things that might blend into other situations more like JSON schema support and whatnot. So, yeah, I’d say they are considering these fringes and considering how they can adopt it into OpenAPI. But at the same time, they need to consider what works for documenting the most cases, kind of that classic 80/20 rule.
You’ve hosted Daryl Miller on the podcast, right? If not, he would be an awesome person to get involved to speak to exactly what the OpenAPI’s mission is and how they're working to evolve the specification.
DB: Yeah. We've had of course the API Evangelist, OpenAPI initiative in the show. So, we have some sort of insight as to what the OpenAPI Initiative is pursuing. And my feeling is that there probably will be some sort of consolidation. Some of these standards are looking for a home if you like, whether that's a Linux Foundation home or 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 us and consolidation that takes resources to build and promote these standards, right? Some efficiencies there to be seen.
BD: We'll see what happens.
DB: We'll see what happens. So look, what's the future? I mean, obviously, you mentioned microservices and I briefly mentioned WebEvents or, you know, remote-based events. We've also had people on the program talking about automatic discovery and consumption of APIs with machine consumption of APIs. Where are we going? Is gRPC going to overtake microservices and is the future, you know, WebEvents, the discovery of API consumption, where is all this heading?
BD: Yeah, I've noticed a lot of interest in gRPC. I could see further architecture is being built with that as 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, we have great functionality out there. We have 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 more of the business folks could be very interesting in growing the space I believe.
And once we do that, once we loop more of those kinds of minds into 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. Yeah.
Because what 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, and security and, and answering those questions and coming up with ways, to define 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 the API is just a mechanism that we just don't even think about it anymore. It's just the way we do things. Right?
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 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 want, like, all the weather data out there, you know, and they want to 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.
DB: That's just, you go for cloud-based services, right? So we abstract to the APIs of cloud-based services so that you can have a single API to provision, compute or storage. So it's possible that it's not an insurmountable problem to do a similar thing for APIs. You do have different database entity descriptions and formats. So, you know, some APIs will return different data to others, and it creates complexities in 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 abstracting a public API is not that much of a stretch. It's really just a case of managing the data and how you consolidate that data and return it from these different formats, whether it's probably a relatively easy one because there are not so many attributes of those entities [like] how to describe weather.
But a CRM, for example, you can describe a contact record or a company record and 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've also embraced with our product, Negroni, at TORO Cloud, 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.
BD: 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 that's exactly what we're talking about. And we're going to see the future of the abstraction layer for the API continue to become more accessible.
DB: Bill Doerrfeld, it's been a pleasure to have you on the program. How can listeners follow you? What do you write about and what do you do?
BD: Yeah, 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: APIs, recovering strategy, security, design platform, education, a lot of different topics. And I'm also doing a monthly livecast 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'd like to follow up with my writing or what I'm doing personally, Twitter would be the best at "DoerrfeldBill". That's my tag.
BD: Great. Thanks so much for having me really fun to nerd out on everything API.
Published at DZone with permission of David Brown. See the original article here.
Opinions expressed by DZone contributors are their own.