#248: The Fundamentally Fascinating World of APIs with Marco Palladino

The Analytics Power Hour

Application Programming Interfaces (APIs) are as pervasive as they are critical to the functioning of the modern world. That personalized and content-rich product page with a sub-second load time on Amazon? That’s just a couple-hundred API calls working their magic. Every experience on your mobile device? Loaded with APIs. But, just because they’re everywhere doesn’t mean that they spring forth naturally from the keystrokes of a developer. There’s a lot more going on that requires real thought and planning, and the boisterous arrival of AI to mainstream modernity has made the role of APIs and their underlying infrastructure even more critical. On this episode, Moe, Julie, and Tim dug into the fascinating world with API Maven Marco Palladino, the co-founder and CTO at Kong, Inc.

Links to Resources Mentioned in the Show

• (Book) To Have or To Be? Eric Fromm
• (Article) Big Tech needs to get creative as it runs out of data to train its AI models. Here are some of its wildest solutions by Lakshmi Varanasi
• Canva’s Video Editor
• Simulation for Probability of Success by Nathan Yau

Bonus Links!

Shortly after this show published, listener Riesling Walker posted a comment in the Measure Slack community with some really helpful pieces that she had co-written about getting up to speed and comfortable with APIs. It’s great stuff, so we’ve added her note and those links here!

---

As someone who was (and frankly still is a little bit) scared of APIs, my coworker Deepsha and I wrote a 3 part blog about using APIs (and collaborating in R + python using Reticulate), using Ravelry’s, a social networking and organization fiber arts website , API!

• How to access an API for first time API users. In this article, I’m particularly proud of the section called “APIs versus relational databases”, which talks about the mindset differences you need to have when analyzing data from an API vs a relational database. It also has very simple code that you can use to try it for yourself!
• Collaborating between Python and R using Reticulate
• Turning our API hackathon into an end-to-end data science portfolio project (in which Deepsha was literally the best coworker/friend ever and mailed me yarn )
• Or, you can just check out our repo: https://github.com/deepshamenghani/R_Python_Reticulate

---

Thanks, Riesling!

Photo by Shoeib Abolhassani on Unsplash

Episode Transcript

[music]

0:00:05.9 Intro: Welcome to the Analytics Power Hour. Analytics topics covered conversationally and sometimes with explicit language.

0:00:13.9 Tim Wilson: Hi everyone. Welcome to the Analytics Power Hour. I’m Tim Wilson and this is episode number 248. There’s a pretty good chance you’re listening to this episode on a mobile device. No guarantees, but I’m just gonna play the odds on that. I’m sitting here at some point in your past speaking into a microphone that is connected to my computer, which is connected to the internet, which is using a recording platform, which will result in audio files that will be edited, which will then wind up as an MP3 that gets syndicated to multiple platforms, which winds up getting pulled down to your phone and your specific listening platform. That’s a lot of interactions across a lot of different applications. Put another way, it’s a lot of interfacing between applications through programming. How’s that done? Well, with application programming interfaces or APIs. Because application programming interface is a mouthful, but that’s the topic of today’s show APIs. APIs are fucking everywhere and I love them. We’ll see if I’m joined in this adoration by my co-host for this episode. Moe, you’re the director of Data Science for marketing at Canva, which for those keeping score at home is a platform that has an API, Canva Connect, bravo. But Moe, on a scale from like rest to OAuth, how do you feel about APIs?

0:01:34.9 Moe Kiss: Pretty damn good. I feel like they’ve saved me many, many an hour.

0:01:41.4 TW: Awesome. And we’re also joined by Julie Hoyer, API manager. I mean wait, analytics manager at Further. Julie, do you remember the first time you used R to programmatically pull data from Adobe Analytics? And if so, do you recall if you literally pumped your fist?

[chuckle]

0:01:58.8 Julie Hoyer: Of course I did.

0:02:03.3 TW: All right.

0:02:04.9 MK: Actually, sorry to steal your thunder. I think my first time it was Twitter’s API.

0:02:10.7 TW: Really? Pulling tweets or pulling like five over accounts or both?

0:02:13.2 MK: Tweets. Tweets.

0:02:13.6 TW: Tweets?

0:02:14.6 MK: Yeah, back in the day.

0:02:16.3 TW: Back in the day when there was a platform called Twitter. Interesting. So none of the three of us hold a candle to our guest when it comes to being passionate about APIs. Marco Palladino is the co-founder and CTO of Kong Inc., a leading API management platform. So yeah, Marco loves APIs so much that he founded a company to help other organizations establish a manageable gateway to the wide range of APIs that they put in place to programmatically hook into multiple different backend services. Marco has also been a member of the business governance board at the Open API Initiative since 2016. He was also the co-founder and CTO of the Mashape API marketplace, which was acquired by Rapid API back in 2017. Seeing a theme here? Today he is our guest. So welcome to the show, Marco.

0:03:09.9 Marco Palladino: Well, nice to be here. Welcome everyone.

0:03:13.0 TW: All right, somebody who’s got so much API in his background, I’m excited for this conversation. So we don’t know exactly where this discussion will go and it’s been noted in the past by some of my co-hosts that I have a tendency to sort of cannonball right into the deep end of some topics when I’m moderating the show. So I’m gonna try to not do that here. So maybe we can just start with a basic definition of an API. So Marco, if you were talking to someone who had maybe just graduated from university with a non-technical degree and you needed to explain to them what an API is, what would you do? How would you tell them?

0:03:57.8 MP: Well, I think that what I would say is that APIs are today the new internet. You know, back in the days when we were looking at what the internet was, it was websites, it was blog posts, it was email. That internet does not exist anymore. It has been replaced by an API powered internet. So it is the new underlying technology that powers every mobile application, every experience in the digital world, every website today is powered by an API, 85% of the world Internet traffic is APIs. So it is what makes the internet as we know it today possible and available every time.

0:04:35.9 MK: I would challenge you though, like you could still engage with the internet, right? Like, ’cause I obviously live on the, I suppose more technical side where I probably do agree with your premise, but just to be a little bit challenging, that you could still engage with the internet, I guess, without even having an understanding or awareness of APIs. Or is it more that just it’s the backbone?

0:04:58.9 MP: It’s the backbone. So essentially APIs, it is what under the hood powers those experiences. And today if we remove APIs from the internet, everything will stop working. Every mobile application will stop working overnight. Every e-commerce company will stop working overnight. Every bank transaction will stop working overnight. People are not getting paid, people are not productive. Zoom will stop working. The internet today runs on APIs, but APIs is the underlying technology. You’re right, it’s not something that as an end user I am going to see, but it is what powers that connection. And so the definition of an API is a technology that allows us to connect services together and data with those services. And so for example, if we are looking at a map with our phone, obviously our phone doesn’t have all the maps for the whole world. That would be an incredible amount of data to store.

0:05:50.9 MP: The phone itself communicates to a server to pull that map and then show it to us on our mobile application. And the way it pulls that map and show it to us, that is what APIs do. It is a way for an application to retrieve data and services from the servers that we’re using. And without an API essentially, none of that would be possible, which is also the reason why if our internet is down, all of a sudden we can’t show maps anymore on our phone. Because APIs need that connection to be able to communicate to the servers.

0:06:25.7 MK: I desperately need to clarify something because I feel like you are really adding to my thinking. Would it be fair though to say, and this might sound completely basic, but as someone that is not a backend engineer, I really wanna make sure like, because you basically have your backend services, but the APIs is just managing the connection between the two, right? So like you still have a standalone service. It’s that the APIs sits on top of it. Is that a fair description?

0:06:56.9 MP: Well, so we have, there is two different sides of the equation. When there is an API, there is something that’s making that API available that’s producing the API. And then on the other end we have applications that are built on top of those APIs that are using or consuming the API. And so whenever we are thinking of APIs, we’re always thinking of who’s building that API and offering it, can be a server, it can be a database and then can be, by the way, artificial intelligence today artificial intelligence is all powered by APIs, or it can be on the other end of the equation something that consumes it or uses it. And it can be our fridge, our mobile app, it can be our car, it can be pretty much anything that wants to either send data or retrieve data.

0:07:38.9 TW: So that actually has me thinking and that’s a use very useful way to frame it. As an analyst, I find myself being the, I feel like the consumer, like close to a 100% of the time I will read about things that are in theory if you’re making a a data product, you may say, my data product, now I need to have an API so other individuals or other programs can kind of consume it. But the dependency like in 2024, is there any system that can even exist without offering some sort of an API I mean that’s gonna be a broad generalization. I remember looking, and this is in my intro, I was like I wonder if like Canva should have an API and it took literally two seconds and I was on their developer website and I’m like, yeah, canvas has an API, which I would assume that 99% or more of Canva’s users don’t know what an API is and don’t use an API. But boy, that 1% who are saying we need to programmatically generate or consume, push or pull into Canva absolutely need it. So I guess is there any modern system that can be stood up without thinking we have to have an API or is it the way systems are now built, they build APIs ’cause they wind up using them within the platform. And I don’t know like is Canva using the Canva API within Canva also?

0:09:14.9 MP: Well, you’re bringing up a very good point. I mean that was the transformation that has happened in the last few years. APIs used to be an add-on something that we would think afterwards to build on top of our systems. And then this thing that used to be an add-on all of a sudden became the first consumption channel for pretty much all digital experiences. And today APIs are not an add-on anymore. Today we build applications and we start with the API. That mindset shift, it is what made APIs today very powerful. Of course, you can still build software without an API, but that software is going to be siloed because it cannot be used by anything and it cannot communicate to anything. And so it is a siloed software and in this day and age, I don’t think we, we see much of these type of applications around anymore.

0:10:08.6 TW: It’s time to step away from the show for a quick word about PIWIK Pro. Tim, tell us about it. Well, PIWIK Pro has really exploded in popularity and keeps adding new functionality. They sure have. They’ve got an easy to use interface, a full set of features with capabilities like custom reports, enhanced e-commerce tracking and a customer data platform. We Love running PIWIK Pro’s free plan on the podcast website, but they also have a paid plan that adds scale and some additional features. Yeah, head over to piwik.pro and check them out for yourself. You can get started with their free plan. That’s piwik.pro. And now let’s get back to the show.

0:10:51.4 TW: I remember when Adobe Analytics on the, the digital analytics side, when Adobe Analytics came out with analysis workspace, which was a completely different kind of way to interface. And then they were saying, and our API, they lagged a little bit on exposing the new API but they kept making such a big deal and I was like, why are you guys making such a big deal out of this? Until it sort of clicked for me where they said the API, it’s the same thing that’s powering the web interface that many analysts were using with that platform. They said we’re using that API and basically have built an application using this API that is the, Adobe sanctioned this thing called analysis workspace, but it’s the exact same API that if I want to connect through R which did, when the light bulb went on all of a sudden made a lot more sense as opposed to saying, Well, I can do this in your tool, but I can do this other thing if I use the API or there were limitations. It was completely, like 99% synonymous. So, and that clearly was what was happening in their development team saying, when we redo this, we’re gonna build it with an API first mentality.

0:12:06.9 MP: I’m going to say this internet based APIs, which is the type of APIs we’re seeing today, they were a singularity in our industry. There was a world before these APIs were widespread. And there is a world that has developed after APIs were widespread. This is a one of those things that happened once in the history of humanities, one of those technology shifts or improvements that only happens once. And once they happen, you look back and you’re thinking, oh wow, this thing was inevitable. Like I cannot imagine of a world without this thing now. You know, it’s like going from analog cameras to digital cameras. It makes perfect sense. Now look, connecting the dots, looking back.

0:12:44.0 TW: How long ago did that… I mean it wasn’t an overnight, but it was like, is that 10 years ago, five years ago? When did that happen?

0:12:53.8 MP: So APIs happened slowly and then all of a sudden, okay, so the concept of an API has always been there. You know I am sure that if you look at software in the ’80s in the ’90s, there was an understanding of what an API was. We just didn’t have the demand for it. So what changed in the last few years that generated demand such as APIs now are the number one way of using our services? Well, it was most likely, if I have to pinpoint it, it was Steve Jobs going on stage announcing the iPhone. Now you can build applications on your mobile applications that started the whole mobile revolution. And if you have apps on a phone and then of course Android and all that. But if you have apps on a phone, how do you make that application, on a device, how do you make that application work with your servers?

0:13:41.1 MP: Well, you have to have an API, it’s just not possible. And so mobile applications were the first wave that needed APIs since day one. Otherwise you couldn’t build any mobile app. And if you missed the mobile transition, your business would’ve failed, ’cause everybody’s now consuming through our mobile phones. And then after mobile, there was microservices and then after microservices, there’s now AI. And so really the demand for APIs is being driven by the experiences, the customer experiences that we wanted to build and the devices that we wanted to support. And before mobile APIs were still there, but they were an add-on, you know, it was not something that people were thinking as a main driver to a business motion or a main driver to a customer experience. But today, APIs are customer experience. So look at this Amazon, one of the most famous, if not the most famous e-commerce company in the world, whenever they’re pulling up a page for an item, they make 200 underlying API calls to fetch all the information that at the end of the day in a fraction of a millisecond is being assembled on the webpage so that you can see the items you’re buying, you can see the descriptions, you can see the reviews, you can see the prices and so on and so forth. That was something that didn’t exist 20 years ago, but now it is everywhere.

0:15:00.9 MK: So I do wanna talk a little bit very soon, more specifically about like the data space and APIs, but before we get there, because this is a really nice dalliance for us into an area we probably don’t get to really think about too often. So you’ve talked a lot about kind of how APIs started and it, like you said, it was all overnight. What has been the shift in the sort of the last few years? Like is it the scale is just getting bigger? Is it things are getting faster? Like what have been the improvements that you’ve seen in the last few years? Like being in the industry?

0:15:31.9 MP: Well, because APIs are in between every digital experience, every time I’m purchasing something, there is an API, you fly with an airline that the whole experience is driven by APIs. APIs became critical and when they became critical, it is for sure more scale. We get a lot more APIs. So how do we create, how do we make sense of all of these APIs? How do we implement a life cycle to create new APIs? Decommission the old ones, to document the APIs, access the APIs, but also performance became a lot more important because obviously the quicker the APIs are and the better customer experience you have at the end of the day. So if you are purchasing something in a fraction of a millisecond versus 10 seconds, customers are more incentivized to go to the product that has the quickest API infrastructure because that product can deliver the quickest customer experience, the best customer experience. And so being able to cater to that performance, it is something that became critical. It’s not a nice to have anymore. It is part of a modern platform. Back in the days when our application was down, the business was down, but today when our APIs are slow, our business is down. Slow is the new down. Being slow, it is essentially a death sentence to every customer experiencing the Internet today.

0:16:51.9 MK: But so like that Amazon example is really interesting. How did that happen before there was the use of this like 200 API calls? Was it just like they had to batch the data into bigger, bigger requests or it was just coming directly from a backend service? Like I’m not sure I understand how it functioned before.

0:17:11.8 MP: That’s a great point. There were still some APIs, but most of that rendering was not done on the client side. So today, the reason why the internet is pleasant to use it is because we can do something on our webpage or a mobile app and the UI can show immediate input and feedback as it’s loading the new data in such a way that it’s pleasant to use. Before all of this, you would press a button and then you would wait three seconds for that page to refresh, and then you would do some other thing and you would wait another two or three seconds for the page to refresh. Everything was generated on the server. Therefore there was no need of an API that connected our browser on our computers with the servers because the server was generating all of it and therefore the experiences were slower.

0:18:02.9 MP: The Internet 20 years ago is nothing like the Internet today. Just some things were not possible 20 years ago simply because the technology was not there yet. And so everything that we’re seeing now, the proliferation of mobile applications, the proliferation of new products and new startups every day, all of these and all those experiences are possible thanks to our APIs. So they did accelerate the industry, they made the customer experience a lot better and they allowed to extract more value from the industry, right? Because now you get more users in, if things are quicker, if things are nicer, you get more users. More people want the internet to do their things. And more people, as a matter of fact, stop doing things like they used to do them back in the days. They don’t go to stores anymore to buy their books. They go on internet to buy their books. Why? Because over time that experience got a lot better. And part of it, it is the usage of APIs to create better user experiences on the browser or the mobile application.

0:18:55.9 JH: So am I understanding it correctly, you’re saying that instead of the server doing all the heavy lifting because of that slow reload of the experience, each click takes three seconds until it reflects what was done. You’re saying that now the client or the website that you’re on, the interface, it’s using APIs to pull the data from the server and then the heavy lifting is done like there on your phone, on the app, what you are experiencing with? So it’s faster? Is that accurate?

0:19:23.2 MP: There is no, yeah, there is no refresh. It’s, it looks like it’s in real time because there is no refresh or server processing that happens in the delivery of the frontend experience. Before, the frontend experience itself was being delivered by the server and that created a very laggy type of experience. With APIs, we can now decouple the code base that runs on the client from the code base that runs on the server and APIs is the glue that connects these two different experiences together. So now we don’t wait, we don’t need to wait for the server to render every button on the page. The browser can do that in a much quicker way because the browser is on our computer. So by law of physics, it’s going to be quicker just because it’s here. We don’t have to wait for a server somewhere to do it.

0:20:07.8 MP: And the server now only returns the raw data that’s being assembled on the client. So the requests also got smaller because it’s much quicker and smaller to make an API call to only retrieve the structured data you want to represent on the client than it is to get the whole page already rendered with the data and everything else that’s being shipped to the client. So now we only get the bits of information that we need and then assemble them in real time on the browser or the mobile app in such a way that experience is quicker. So we consume less bandwidth as a result of that. The experience is quicker and it allowed for the proliferation of digital applications all over the world.

0:20:50.6 JH: Wow. So what also, so with my somewhat limited experience with APIs, I have run into some that are much more reliable than others. And I was going to ask, are there different types of APIs broadly, where you’re like, yeah, this type is great and new, this one’s archaic, don’t use it. And if there are different types, what makes some better than others?

0:21:12.9 MP: We’re seeing this is a mindset problem more than a technology problem. Let me explain why. Developers used to build lots of APIs because in their mind APIs were something that they would use internally to generate the experiences we just spoke about. But APIs over time, they became products themselves. The product is the API, look at companies like Stripe or Twilio. These are API first companies where the API is the product and APIs, if they become a product, they need to be versioned properly, they need to be monitored properly, the performance has to be improved continuously. And many developers are not thinking of an API as a product. The ones that do, are the ones that can deliver a great experience and the ones that don’t, are the ones that don’t have the infrastructure in place to deliver reliability, performance, accurate results simply because they’re not looking at an API as something that they should curate to that point.

0:22:09.7 MP: The problem is given that APIs run everything we do and given that APIs, is at the end of the day, the product we’re using to power all of these experiences, if we don’t evolve our thinking of APIs, then we are going to be left behind. And companies that do it are the ones that succeed. Look at, let’s go back to Amazon. Amazon wasn’t the first e-commerce company in the world, but Amazon was the first e-commerce company where AWS could be possible. Why? Because Amazon recognized since a very early day that APIs were products and everything they were doing inside of Amazon should have had an API. Because if everything has an API, then you can assemble those APIs together to create new products, new experiences in a much quicker way than if you didn’t have that. And because of that, everything is an API. Amazon was then able to take a subset of those APIs and make them available for consumption as a product to every other enterprise organization in the world. AWS or the cloud is all APIs. It’s an API to start a server. It’s an API to store some data. It is an API to retrieve that data. Everything is an API and the APIs are products. And so the difference between the ones that are not doing it right, it’s exactly what you have explained Julie.

0:23:27.5 MK: So would you say that it’s fair then that the people that are doing APIs well, the engineers have the right mindset around that. It basically is a product in and of itself and the demonstrations or the ways that you might see that are through really good documentation, version control, support resources. Is that basically, if I’m Julie and I’m trying to figure out whether an API is a good one or not. Are those the indicators we should be looking for to understand if one’s, we’re gonna have success with one or we should probably not bother with this particular one ’cause it’s gonna be messy or they’re gonna make a bunch of changes to it, not tell us, and then we’ve built a connection with it and everything goes haywire?

[laughter]

0:24:06.9 MP: Breaking changes are a huge problem with APIs because you create an API, you start using it in app and APIs also allow us to become platforms. So you may have third parties building on top of your APIs that are not employees of the company. There are partners, the ecosystem, the developer community. And the problem with APIs is that once they’re being created, it’s really hard to change them because at the moment they get updated, everything else stops working. And so whoever is building an API has to start since day one thinking about, okay, there’s, it’s inevitable APIs will get updated. It’s a fact of life. How do we design an API today such as we can extend it in the future without creating a breaking change? These are very hard problems that developers have to solve.

0:24:58.3 MP: Now, companies that do APIs, right, and the ones that don’t do it so well, they understand that developers, their job is to build the API but not to build the infrastructure for API, the biggest problem is that when developers are being tasked with creating an API, more often than not, they’re also being tasked with creating the infrastructure of that API, what’s an infrastructure of an API? It is how it’s being consumed, how it’s being version, how it’s being documented, how it’s being monitored, how’s the performance is going to be improved and so on, how it’s being cached. And developers should not be builders of infrastructure. They should be consumers of infrastructure and builders of APIs. So when a developer is being assigned with this enormous task of building an API and the company is not taking care of giving the developer the infrastructure to succeed, then the developers will start cutting corners. And quite frankly, it’s not their fault because their job is building the API but not building the infrastructure of an API.

0:25:51.0 TW: But it it does seem like, because as you’re talking, there’s a lot around the versioning and the managing and the managing of deprecation presumably. And I think Moe, what you brought up to me it sounds, it’s managing it so that any update to the API automatically gets documented. You can tell when you’re looking through documentation whether this is, oh, somebody had to go update the documentation or no, this was part of the process. But there’s this other piece, and I think you were starting to touch on it there, that the underlying design or architecture you’re needing to build something that needs to be extensible for years into the future. And if that isn’t an elegantly design, not future proof, but robust fundamental structure, then you wind up with, I’m now, I’m thinking of cases where… I remember Fitbit completely their API was so terrible that they just basically threw it out and started over.

0:27:00.3 TW: And there were cases where, it’s, oh, you’re using the old API and the new API and it takes them forever to turn off the old API because so many things are are hooked into it. So outside of the managing the versions and the pieces, is there a, this is an elegantly designed such that we don’t know exactly where this is gonna go, but we see the future enough that this thing can be extended without it starting to crater. That feels like this pivotal moment early in the existence of an API that could make or break you five or 10 years down the road.

0:27:42.2 MP: Not just APIs, but every software anybody builds features are easy to build, architecture is hard to change. And for APIs, that is true. When an API is being created, it has to be architected. The abstractions have to be in place. The primitives that we’re building in the API have to be of the right type that allows us to scale in the future. And if that initial architecture or design of the API is not correct, then it’s going to be a very messy and painful refactor down the road when inevitably that API changes. Now, I think someone, we have to approach this like any other product development life cycle. API is our products, so everything else applies. Do we want time to market? Do we think we have something that’s so innovative where time to market matters more.

0:28:30.1 MP: Then let’s go ahead put something out there first. You know that you will have to change that down the road. So at one point there’s going to be a time where we’ll have to address that pain point. And in some other cases, we can develop APIs that are built to scale because, it’s not the speed of the API that matters to us, but more the reliability of the API. Some APIs are high volume, but low value and some other APIs are high value and low volume. Let me give you an example, the Twitter API, if I’m consuming the API and some tweets are not being retrieved. And each tweet is fundamentally a low value type of data, but it’s high volume, right? So we can afford for some unreliability. We can also start changing things and introduce some pain points along the way.

0:29:16.8 MP: That’s never ideal, but it’s not going to break the bank, so to speak. Look at a company like Intuit. Intuit is, or TurboTax, it’s one of those products that nobody uses for the whole year and then all of a sudden there is four weeks every year where everybody submits their tax reports and it’s extremely high value, on a high value API transaction. We cannot break that API because every request that we miss or fail, it is not just a tweet that’s not being sent or retrieved. It is the tax return of someone from the US that it’s not being received by the IRS with potential ramifications, right? And so what type of API system are we building? If it’s high value, we have even more so built the right architecture, otherwise that pain is going to be enormously bigger down the road.

0:30:10.8 MP: If it’s low vol, if it’s a low value but high volume and we think that time to market matters more, then we can make the trade off. But the trade off has always been made with open eyes. It’s something that we recognize and we decide to prioritize speed versus proper architecture. But we do that with an open eye. We know that there’s going to be pain down the road and you know what, we are willing to take that pain. It makes sense, business sense. So, this is up to the termination.

0:30:38.1 MK: I’m actually so surprised because that was gonna be my next question of whether API development slows down, ’cause in product and tech we always talk about MVPs and shipping things fast and shipping wet paint and yada yada yada. But with APIs there’s so much of a higher cost to shipping fast because you don’t have that same ability to iterate on your product. I guess to some degree you do, but you can’t make as significant changes when there are all these other things that are then stacked on, other services stacked on top or other products that are relying on it. So I’m actually really surprised by that, ’cause it sounds like it’s a similar mindset, but I would’ve thought maybe that API development as a product needed to be thought about a little bit differently.

0:31:25.7 MP: Well, I think that all of these pain points are things that can be solved. The difference is do we want our developers to solve it for us? Going back to the original topic, are we asking our developers to build API infrastructure or not? Proper API infrastructure, which is one of the reasons why we’re funding success with Kong. And one of the reasons why I’m building what I’m building at Kong, it is because API infrastructure can unlock economies of scale such as some of these problems. How do we version them? How do we monitor them? How do we secure them? How do we get notified if something goes wrong? All of that is being baked into underlying infra and developers don’t have to go and build it every time they create a new API. And the more APIs we build and the bigger the value of proper infrastructure is going to be, because the more APIs, the more scale we have there and the more urgent is the need to have the right infrastructure.

0:32:19.3 MP: And so some of these areas can be solved by baking them into the underlying infra, which gives the tooling and the automation for the developers to do the right thing. So for example, we have customers today that are supporting the API development lifecycle by integrating our infra with automation such as APIs that are not documented in a certain way, that can’t be published, APIs that are not secured in a certain way that cannot go public. APIs are a huge cybersecurity risk as we all know. Many of the cybersecurity attacks where customer data was being stolen, where the services were down involves the APIs. APIs are the number one, one of the highest if not the highest vector for attacks in cybersecurity today. And without infra, that’s a disaster waiting to happen because without infra, we’re essentially asking our developers go build this car, but at the same time, go build every street in the world that allows you to drive this car. So build the car and the infrastructure to run the car essentially. And that’s just an unrealistic proposition. And so we need to be able to support the developer productivity for APIs because we want, to your point, avoid having to make these changes down the road or having a cyber attack risk down the road or all of these problems that eventually will happen. It’s inevitable and proper infrastructure allows us to solve for that.

0:33:45.4 TW: You said monitoring is part of that and brought up the cyber attacks, where does that fit to say, when I’m making a call to an API, say I’m doing, I’m just from a program and occasionally I’m like, oh wow, I want to… Their API limits where it says you can only whatever the API is, is that an infrastructure thing that says, is it the infrastructure that limits the number of calls per second or per minute or per day? Is that an infrastructure for the API or is that the API itself that does that limiting? And related, is there analysis that happens on APIs of saying what aspects of the API are being used and in what ways? Are there API analytics of we have this API out there and 95% of the people are using this, 5% of the features of the API and maybe we can deprecate some other stuff ’cause it’s rarely used? Where does that monitoring or analysis of the usage actually happen?

0:34:58.6 MP: Infrastructure.

0:35:00.3 TW: Okay.

0:35:04.9 MP: You nailed it. It allows us to essentially create tiers of access to our APIs. So with this tier of access, you can get up to this amount of requests. With this other one you can make a little bit more. It gives us the infrastructure to be able to change that over time, to blacklist users that we don’t want to allow, to consume the APIs. It allows us to extract analytics, metrics, information about the API so that if the API is down or if the API is slow, we have the right tooling to be able to detect where it went down, when it went down. The ability to set up distributed tracing so that we know exactly, what’s all the chain of requests, ’cause one API may consume another API, which may consume another API.

0:35:44.9 MP: So basically you have APIs, consuming APIs as well and you need to know exactly where in that chain the API went down and why it’s slow. API security, it’s about Auth n, it’s about authentication, authorization, Auth n, Auth z, it’s about being able to create these access control tiers, the ability to traffic control so that we can redirect a certain subset of traffic to a different version of an API or fail over to a different data center. It is the ability to have a service mesh in place that allows us to implement a zero trust security layer where basically all the communication is encrypted with mutual tls certificates that are being issued to every service or every client or every API that’s making a request to another API. So it is a multi-dimensional problem that is an L7 problem, but also L4. And to cater to all of this, we need infrastructure.

0:36:40.9 MP: The alternative, ’cause look, these requirements are there with or without an infrastructure. So without the right infra, we’re essentially asking our developers to go and figure this out by themselves. And with the proper infra, we can take some of these away from the developers and make them more productive, ’cause now they’re focusing on the customer experience. They’re focusing on what APIs they need to build to deliver the best customer experience, not what is the underlying infrastructure control that I need to build so I can manage this at scale. And without infra it’s not possible. And by the way, we’re seeing this with AI today. I think that AI today, is like APIs were 15 years ago we’re seeing the beginning of, gen AI adoption across the board. And we’re seeing teams today, the progressive ones that are using Gen AI. They are also building the underlying infrastructure for AI. And eventually organizations will realize that they need an infrastructure for consuming AI. The same way they need an infrastructure for consuming APIs that does a whole series of things to make the developers more productive and to build more reliable applications at the end of the day.

0:37:50.7 TW: So that’s an interesting progression. So if I’m hearing you’re saying that in the early days of an API within an organization or a product, and the same thing with Gen AI, the developer is just kinda making it work and there is a point where they say, wait a minute, the infrastructure piece does it tend to go from the developers doing it to, Oh, this internal resource who is more of a DevOps or infrastructure person? Maybe they’re, that builds, becomes part of a team and then it’s just grows to the point where there needs to be third party layers on top of that are much more infrastructure management? Now you’re making me think of like AWS being infrastructure in some ways. Is there a growth curve, a maturity curve where it starts out with, Hey, we made this work. And then pretty quickly, Oh, somebody better help make that piping be more robust. And then this is big enough that it really needs to have its own dedicated investment to the infrastructure side. Is that right?

0:39:02.2 MP: Yeah, you’re spot on. I think this is how every technology starts. Most of the times, Hey, let’s put an engine in two wings and we have a plane. And then eventually as we’re building more and more planes and we’re doing more and more flights, that’s not enough anymore. And so today building an API without infrastructure, it’s like stitching together wings and an engine together and you can call it a plane because it flies but it will also fall down at one point if you don’t have the right supply chain, the right infra to be able to scale that operation. And in AI, we’re seeing that there is, ’cause every technology adoption starts with enthusiasts that are adopting it to unlock new use cases, and the organization has not realized yet, because they’re lagging behind, they’re not realized yet what developers need.

0:39:48.9 MP: The developers are on the cutting edge of technology all the time. And what the organization should do is identify the patterns of adoption and then start supporting these developers. Hey, maybe you need this, maybe you need that, in such a way that over time those developers do less and less of that infrastructure work and more and more of the actual business logic work. This is every technology in the world, whether it’s computing or not, whether it’s software or not. In AI, we’re seeing the same. Developers are now using AI. They’re building all these new intelligent applications, but it’s a subset of developers in the broader developer population of every organization that’s doing that. The others are still figuring it out. And the ones that are building those Gen AI applications, already today we’re seeing issues.

0:40:35.7 MP: Okay, how do we make these AI requests faster? Well, we need semantic caching. Well, it turns out that you need semantic caching not only for this Gen AI app, but for all the others as well. So we need to make that as part of the infra. Otherwise, nobody’s going to get velocity by building infra continuously. It lowers the productivity, not only of the organization, but the developers in the organization, and it introduces risks. I’m sure that any architect or platform owner that’s listening to us fully agrees with that. Their challenge is to be able to support the developers without slowing them down, which is a whole different topic. How do we support with infra our developers, but at the same time, giving them the freedom to innovate, giving them the freedom to use the best tool for the job without infrastructure being a limiting factor, but making sure infrastructure is always a supporting function. And I think that that is the challenge that happens at scale between platform and developers.

0:41:35.7 MK: Do you think businesses understand this dynamic of making sure that the developers are not the ones that are also responsible for the infrastructure for APIs? I imagine that you work with lots of businesses in this, you know, who are going through this learning curve. Like, what’s your intuition tell you about what’s happening? Are companies getting it or are they largely still asking their developers to be doing the infrastructure too, and that’s part of the problem?

0:42:02.4 MP: I think companies are getting it. Companies are sometimes struggling to identify what the developers need. Developers, the problem with developers, and I’m a developer myself, so, we have these, we like building stuff. And so when an opportunity to build things is being presented to us the answer is, Oh, yeah, I can do it. And then you do it once. And then forget about it, right? Because you’re not fundamentally… That’s not what your job should be. And so the thing about infrastructure is that you have to build it, you have to maintain it, you have to continuously update it. And developers, they don’t care about any of that. They build it once and then they move on to the interesting things that they’re building, the end user experience they’re building.

0:42:45.2 MP: And so organizations are realizing that there needs to be infrastructure. Some of them are more mature than others. For example, highly regulated industries like the financial services industry, the banking industry, there is a lot at stake with the lack of proper infrastructure. And so they are the ones that are ahead of the curve when it comes to the governance and compliance and the rollout of this infrastructure and some others are catching up. But the thing about infra is this, some organizations lack the leadership to determine when is the right time to standardize. Organizations, they tend to provide infra to the teams, but they don’t want to slow their teams down in their innovation, which makes sense. It’s great. As soon as some of these innovation goes to production and becomes part of our business, it becomes the right time.

0:43:40.9 MP: Now that we have demonstrated that this is the right technology to use, it becomes the time to standardize it over a global infrastructure. Organizations are not doing that. They are afraid of upsetting the developers because you’re taking away something from the developer’s control of the infra, and you’re baking that inside of a different team. And when you take things away from people, it’s our DNA. I think it’s, you know, I want everything for myself. And so there’s going to be some kicking and screaming. The thing is, when developers build infra, they’re not thinking about the strategy of the organization. They’re not thinking about other teams. They are in their own silo and they’re building something for themselves. And they’re not willing to take responsibility for disruptions in the infra.

0:44:26.1 MP: So sure, you can go and build the infra. You are accountable for every cybersecurity attack. You’re accountable for every data leak. You’re accountable for anything that happens because you decided to go build it yourself. Now, if you frame it that way, as a developer, you know what? I just want to build this thing. You figure it out for me. And I’ll go build the application. But organizations, they are lacking the leadership to make the teams accountable, but also make them a design partner of the infrastructure. And the organizations that are doing it right are the ones that continuously listen to the developers because the developers become the internal customers of the platform team. So they continuously listen to what the developers need. But sometimes you have to say no, and it’s okay to say no.

0:45:05.6 MP: Many organizations, they are not willing to do that because either they don’t want to take responsibility for that, they’re not thinking strategically long enough, or they’re not willing to, you know, it’s a leadership, technology adoption is a leadership problem. Go back to Amazon. Why did Amazon create APIs? You know why? Because the CEO himself, Jeff Bezos, created a famous mandate and told the entire organization, from this day on, you create an API for everything and this API has to be built in a way that it can be exposed. And if you do not agree with me, you can leave the company. So, at one point, the organization, I’m not saying, that’s an extreme, right? I’m not saying that someone should always be dictatorial in the way they approach leadership issues in the organization.

0:45:56.8 MP: But at some point, someone has to own the vision of the company. And who is the owner of the API vision today in the organization? Who is the person that’s responsible for developing an API vision from now to five, 10 years from now? Who is that person? Who is that team? And more often than not, you will find that that person does not exist.

0:46:16.1 TW: So Amazon being kind of that, you’ve come back to as kind of the success story in many ways, is Twitter like historically the failure, like the farewell for the early years of Twitter? Was that fundamentally an API infrastructure issue? And if you fast forward to now with Grok, which seems like it’s kind of… It’s AI that gets kind of held up as being kind of a train wreck as well. Like, is Twitter like the textbook case of where consistently they tend to fall off the appropriate API or API infrastructure implementation? I don’t know. Is that, that clearly just occurred to me now that, that’s where failures seem to happen and it comes and goes, but is that an example of where… I’m trying to think of where do APIs not go well. Is Open AI, and anthropic, and Google, and meta, and Amazon. Are they all mature partly because they really have the right balance and management of the API and including the infrastructure and organizations that don’t, you visibly see an inferior product. Or am I overly generalizing?

0:47:33.5 MP: Yeah, look, we’re working with more than 800 customers. Most of them are enterprise. And you will be surprised too, once you unpack it, how many organizations in the world, they keep working not because of their great infrastructure, but despite their great infrastructure. So I can’t speak of specific companies or specific examples, but every time we’re using a mobile app, and the mobile app is not working, or we get an error, or it’s not loading, or everybody has experienced something like this, chances are that there is an API somewhere that’s failing. And sometimes the API fails because the underlying database, for example, that the API is using is also failing, right? So it may not necessarily be the API problem. It may be something down the road, down the line that the API is using.

0:48:27.8 MP: It could be another API that the API is using. Netflix was very famous for enabling this new practice called chaos engineering, where basically they would randomly shut off production instances from their AWS account, because they built an infrastructure such as if you did shut down a server randomly, unexpectedly, that infrastructure was able to self-heal and self-recover so that the uptime of the service was always there. Now, Netflix is a very mature company when it comes to APIs. Not every company can do that, but we must build our software in a way that’s resilient and reliable and there is no way to do that without proper infra. Some organizations are not reliable or not as fast because the infrastructure is not there. I mean, that’s certainly part of the equation. Maybe it’s not the whole equation, but it’s certainly part of it.

0:49:23.2 MK: I need to just specify for listeners at home that can’t see the visuals that both Julie and my jaws dropped to the floor when Marco just said that about Netflix. Shock and awe and also a lot of profound respect now for Netflix’s engineering team.

0:49:43.6 JH: I mean, how could you not go to bed and have like nightmares of like, but what if this shuts off? Like wake up in the middle of the night with cold sweats. That would be crazy.

0:49:52.0 MP: But I think it makes tons of sense ’cause when you think about it, things can happen anytime. The underlying cloud vendor, the region may have problems, right? So if we are building a reliable business that runs on APIs and Netflix, by the way, it’s all APIs, like pretty much everything, every organization, every vertical, every industry today is powered by APIs. Netflix is another heavy user of APIs. If we’re building infra such as it’s always reliable and up and running, then we need to be able to tolerate unexpected failures. And some of these failures could be somebody shutting down a server, for example. So you are shutting them down to see how the system behaves in a more complex situation in such a way that if you see that there is a weak link, you can harden that link. So when it does happen in production, you then are already prepared for it.

0:50:41.7 MP: Because sometimes problems happen in unexpected areas of the business. So you shut down an instance or a cluster on AWS US East. And if you’re big enough of an organization, that may cause a completely unrelated failure somewhere in a different areas of the org that you haven’t planned for. And how do you plan for it? You have to do these disaster simulations. Companies do this in the financial teams all the time. For example, I know that Google simulates the hypothetical scenario of World War III where all of the US is being nuked, right? Is Google going to be able to support operations elsewhere in the world financially? And they found out during one of these financial scenarios that if that were to happen, the team in Ireland didn’t get some level of access such as they couldn’t independently keep carrying the operations financially because that level of access was missing.

0:51:43.7 MP: So organizations that are mature, they do this in other areas, like the financial area in this case. And we have to also do it in our infrastructure. I think it’s a great exercise to do. And more often than not, we don’t do it because we’re scared to see what we find. But either we find it or someone else will, a hacker, for example.

0:52:06.3 JH: Will AI have to go through those same growing pains? Are there some things you’ve seen with APIs that you kind of see coming along the AI curve, like you were saying, they need to think about this chaos engineering or disaster simulations and things like that. Is that coming for all of the generative AI stuff?

0:52:22.9 MP: Yeah. First and foremost, AI is APIs because whether we use AI or AI talks to something else, the way that can happen is through an API. So the more AI and the more API there is going to be in the world, the more API adoption there is going to be. API is another use case, like mobile used to be back in the days. AI builds on top of that, and everything, if we want to use AI, it is API. So even more so, we need to have the proper API strategy, vision, and infrastructure. And with AI itself, we’re seeing today organizations that are multi-LLM, so they’re using different foundation models because they’re trying to cater to different tasks, different levels of intelligence that they want to achieve. And today, some of these organizations are implementing AI infrastructure, such as they can implement failovers across different models or failovers across different LLM providers.

0:53:19.4 MP: So if I’m running my self-hosted instance of an LLM because I want to fine-tune my model because it’s cheaper to use it in a self-hosted way, it’s more performant, but it’s self-hosted, if something were to go down, what happens then? I want an automatic failover to an equivalent model that runs in the cloud and vice versa so that the Gen AI use case is always up and running. The same things happen with AI as well. We’re seeing it at Kong because besides API, we also provide AI infrastructure. So we are building some of this infrastructure that allows for some of these use cases to happen.

0:53:56.4 TW: All right. Well, this is fascinating. And now I feel like we need to do a whole episode on like disaster modeling and chaos engineering as well, but that would go on for, we can’t do that today. So Moe thinks she has one more question.

0:54:12.5 MK: I have one more question because I thought we were gonna cover it in the show. And full disclosure, I am 99.99% sure that I was the person that said we should do a show on this. And we have not talked about any of the things I thought we would talk about, which is fine because it’s been a super fascinating discussion. What I would love to hear, though, from your perspective, Marco, because we have been really focused kind of on APIs and engineering and I suppose my interest in this topic comes for that like lowly analyst that’s kind of sitting on their own, like we talked about at the start of the show, maybe they’re working on a spreadsheet.

0:54:48.5 MK: And I remember this feeling so deeply. The first time I opened up documentation for an API, and I’m very confident it was Twitter’s documentation, and being really overwhelmed and being like, okay, maybe my spreadsheet option and exporting isn’t so bad and maybe I should just keep doing that ’cause it’s probably easier than reading the documentation and figuring out how to build a connection to this API myself and extract the data. So for that person who is currently in that situation, what advice would you give them?

0:55:25.9 MP: Well, that problem will not exist for much longer anymore because AI will be the client of API. So you tell AI what you want and AI will make the API calls to get to that outcome.

0:55:38.4 MK: Oh, shit. I don’t know how I feel about that.

0:55:45.6 TW: Okay.

0:55:45.7 MP: So you program the outcome. So this is what we’re working on at Kong. This does not exist yet, but it’s something that we are… Because it’s one of those things that I start thinking about it, and then I cannot unsee anymore. Today, developers that are integrating with APIs, they are building against this API, that API, and for each one of them, they have to figure out how to use it, how to consume it, how to keep up with all the changes, and so on. But what if APIs can be primitives of a model that knows how to make those requests? So we tell the model itself, I want to get to this outcome, and the model figures out what APIs to consume to make that happen. If we were to do that, the API becomes a primitive into this model, the same way our data is a primitive in an LLM.

0:56:32.3 MP: So the LLM takes all this data, assembles it, and then gives an outcome based on the data that you fine-tuned the model with. What if we fine-tune a model with APIs, documentation with API interfaces? We still build the APIs, but the consumer of that API it’s being harnessed by AI. It’s not being harnessed by a developer who specifically goes and builds against each one of these APIs. And so, for example, let’s say that you want to order on Uber Eats the most popular food for the most popular restaurants in your area. As a developer, you need to basically assemble together, okay, location services, where is this user at? What restaurants are here?

0:57:18.6 Intro: Let’s use the Yelp API. Then let’s use the Uber Eats API to figure out. Or you can feed the Yelp API, the Uber Eats API, the Google Maps API, instead of model and tell the model, do it for me. And the model will do the right calls to be able to give you to that outcome. That is inevitable. Now, whether it’s Kong that provides this infrastructure or someone else, I cannot see how this does not happen in the future. So it’s going to happen no matter what. The question is, who’s going to be leading the innovation in this area?

0:57:50.2 MK: I think, Julie and my head’s are both going to explode.

0:57:54.3 JH: That is wild.

0:57:56.1 MP: And it’s a layer of intelligence. It’s a layer of intelligence that we’re adding. You know how we have the L1 to L7 stack? This becomes almost like an L8 layer in the stack, which is the intelligence of everything that’s below it. So you’re not harnessing the services and the data. You’re harnessing this new dimension, the intelligence of the organization. And you’re harnessing that intelligence straightforwardly by asking it what you want to do.

0:58:21.9 TW: Okay, so before anyone’s heads explode, given time, too late.

0:58:27.0 MK: Too late.

0:58:27.6 TW: Everybody’s exploded. So this is a great discussion. And there’s, I think we all have a million other questions and would love to chat further, but we also are the Analytics Power Hour, not the Analytics Power Day. So we’re gonna need to head to wrap. But before we do that, we like to go around and have everyone share a last call, something of interest, something they found that might be worth sharing and of interest to the audience. And Marco, you’re our guest. So do you want to go first? What’s your last call?

0:59:02.6 MP: It could be anything? I’ve been reading this book that’s very fascinating. It’s called To Have or To Be from Eric Fromm, which is a philosopher from the 1900s. And basically, he’s observing how humankind can live two different types of lives, one that’s focused on being versus one that’s focused on having, and how the being mindset versus the having mindset fundamentally are in contradiction with each other. And it illustrates pitfalls and it does an analysis on these two different ways of living. And I think that this is especially contemporary given the capitalistic society we live in. So I think I just find it fascinating. And the reason why I’m reading it, it is because as the company grows, I, myself, I’m always learning not only for technology and software, but also learning how to be a better leader. And sometimes you can find good hints and good observations by exiting the industry and finding inspiration elsewhere, ’cause at the end of the day, it’s a human journey. Building a business is a human journey. And so anything that can make us better in that human journey, it’s going to help.

1:00:22.1 MK: Okay, Tim, just one small follow up question. Marco, what’s the writing style like in the book? Because I feel like the topic is super interesting. Is the writing quite heavy or academic?

1:00:35.2 MP: It’s not heavy, but it’s not academic. It’s more of an analysis of these two different ways of living that humans have at their disposal. And I think that’s actually quite interesting to read and it’s easy to read. So it’s not necessarily something that’s heavy. But at the same time, I mean, Eric Fromm is a very well-known writer and thinker of the 1900s. So I’m sure that some people may know him. He has a very accessible style, but it’s very intriguing. It’s very interesting. I don’t agree with everything that he says, but it’s a good point of view to learn about.

1:01:13.5 TW: That’s excellent. Kind of thinking of the, is there an API to access Eric Fromm’s thinking and thoughts or the AI?

1:01:21.1 MP: I’m sure you can fine-tune a model with Eric Fromm thinking, I’m sure.

1:01:27.4 TW: Awesome. Julie, what’s your last call?

1:01:30.9 JH: So my last call is actually an article from Business Insider, and it’s titled Big Tech Needs to Get Creative as It Runs Out of Data to Train Its AI Models. Here Are Some of The Wildest Solutions. And it links to a really great paper by Epic, I believe. And it was pretty crazy because in the end, it says many leading AI systems have been trained on vast supplies of online data, but by 2026, all the high quality data could be exhausted, which is pretty eye-catching. And then you read further and it was really mind-blowing to me, at least, that they said one of the possible solutions would be generating synthetic data.

1:02:08.3 JH: The two sides of this argument are, one, if you can get over, they call it the synthetic data horizon or event horizon, then the model’s smart enough to, like, make good data, so it’d be fine. But of course, the other side of the argument is that synthetic data is kind of like the cycle that you’d get stuck in and it would reinforce anything bad or biased or wrong in the system. So I was really shocked to read that. And I thought it was really, really interesting.

1:02:39.0 TW: Option two leads us to WALL-E, the movie.

1:02:46.5 JH: Right. Exactly.

1:02:48.2 TW: Wow. Moe, what’s your last call?

1:02:49.0 MK: Okay. Full disclaimer, hashtag, this is an ad. I, a couple weeks a go for my husband’s 40th birthday decided to make him a very adorable video and I spent many hours compiling it. But full disclosure, it’s the first time I have actually really used Canva’s video feature and I was just blown away, like, I mean, I do so much stuff in Canva, but I have not done the video stuff at all. And it just was like super easy. And I ended up like cutting snippets together and this person saying this and this person saying that and like weaving this whole story. And it was actually like genuinely quite enjoyable. So anyway, as I said, hashtag, ad. On to you, Tim.

1:03:37.8 TW: I like it. Okay. My last call is a little tool that Nathan Yao, flowing data made called simulation for probability of success, which is, basically, the sort of thing that kind of melts my brain a little bit, where it’s simulating kind of if you had a given success rate, like if you had a 20% success rate and you attempted something five times, how often would you wind up getting success? And it’s kind of based on a thing that Andrew Huberman did some math on the fly and it didn’t kind of work out. So it’s this little interactive tool where it’s kind of fascinating to run simulations and attempts, and it kind of broke my brain a little bit on how probability works.

1:04:31.6 TW: So I’ve added it to my list of things like the birthday paradox that I can’t quite wrap my brain around, but I someday will internalize it, and it’s a fun little tool to play with. So that was a very broad range of last calls today. But with that, this has been a great discussion. Marco, thanks so much for coming on the show. That made me think a lot about what’s going on behind the scenes. And I think I might be now terrified.

1:05:03.8 MP: Thank you for having me here.

1:05:08.3 TW: Awesome. No show would be complete without thanking our producer, Josh Crowhurst, who will make all of this come across smoothly. And maybe some of my statements will make sense if he does a lot of editing. To those who filled out our listener survey, if you’re listening to this before the end of June, there’s still a couple of days left to fill it out, but we’ve gotten some great responses already. So thank you for those who did that. We always would love to get your feedback and connect so you can reach out to us on LinkedIn or on the Measure Slack. Or if you just want to publicly give us feedback, consider leaving a review on whatever platform you listen to the podcast on.

1:05:51.5 TW: I will actually note, I’m going to do a try something. We had a review on the Apple podcast. So it was a kind of lengthy one, but it was very touching from CRC. And it said a piece of it was one thing that isn’t talked about enough in analytics is the courage it takes to be fearless and not knowing the answer, solving the problems in new ways or learning your 80 millionth reporting tool or programming language. Bravo to this team for being real and courageous enough to talk about this. So I think we’ve showed some real courage today being terrified about APIs. So whether you are connecting to your API for the first time that you’re aware of, or whether you’re just now realizing that you’ve been connecting to APIs, hundreds of them every time that you shop, for myself, for my co-hosts, no matter how you’re connecting to APIs, keep analyzing.

1:06:45.8 Outro: Thanks for listening. Let’s keep the conversation going with your comments, suggestions and questions on Twitter at @analyticshour, on the web @analyticshour.io, our LinkedIn group, and the Measure chat Slack group. Music for the podcast by Josh Crowhurst.

1:07:02.9 Charles Barkley: So smart guys want to fit in. So they made up a term called analytics. Analytics don’t work.

1:07:07.2 Kamala Harris: I love Venn diagrams. It’s just something about those three circles and the analysis about where there is the intersection, right?

1:07:19.1 MK: Marco, I have to say, do you guys have a jar in the office for how many times you say the word API? Do you get fatigued with it?

1:07:30.2 MP: No, it’s okay. I’m excited about it. It’s not something that bothers me that much.

1:07:37.3 TW: Rock flag and API is APIs.

The post #248: The Fundamentally Fascinating World of APIs with Marco Palladino appeared first on The Analytics Power Hour: Data and Analytics Podcast.