original address:Building an API is half the battle: Q&A with Marco Palladino from Kong (opens new window)

API gateways, service mesh, and GraphQL, oh my!

In networked software, APIs have become the foundation of every app. Whether those are the backend endpoints that power the app or third-party APIs that provide specialized services, managing them effective can mean the difference between a successful API product and death by 500 server error.

We spoke with Marco Palladino, CTO and co-founder at Kong, all about APIs past and future and what engineers need to do once their API endpoint has been built.

We’ve edited this conversation for clarity. This Q&A is also available as a video (opens new window).

*Ryan Donovan:* How did you get involved in the world of APIs?

Marco Palladino: When we started our journey with APIs, we started with an idea in 2009 to build an API marketplace like Amazon but for APIs. We imagined a world where APIs would be the main foundation block for every application that anybody creates in the world. In 2009, that was just about to get started, so people were asking us, “What is an API?” We built our first business called Mashape (opens new window), which was an API marketplace. If the world runs on APIs, then we need to have a marketplace for APIs. That product was the beginning of the Kong journey, because the Mashape marketplace didn’t work very well for us but the technology we built was very good in this new microservices and API world. We built it for ourselves and we open sourced it, so we extracted it and we pivoted into Kong as part of a transition we made in 2015.

*RD:* That’s very much ahead of the game. You must be excited about the innovations in Jamstack these days.

MP: Yeah, I mean there’s innovations that are happening pretty much across the board. Now in my space, which is the API space, what we’re looking at is APIs as fundamentally running pretty much every digital experience we can think of. 83% of the world internet traffic today runs on APIs. APIs are powering everything, as we all know, in our daily lives, in every category and every industry that we normally interact with.

*RD:* What makes a good API?

MP: Well we should think of APIs as user interfaces, except the user is a developer. Good APIs are easy to use, easy to understand, and not convoluted, and fundamentally they provide a nice abstraction on top of the service or the data that we want to access through the APIs. The ones that are bad are the ones don’t have any of these properties. They’re ugly, they’re hard to use, they’re inconsistent. There is no documentation whatsoever, therefore, it’s hard to consume them and hard to test them and debug them.

Ultimately, the criteria that separates the good APIs from the bad APIs is the consumption. At the end of the day, APIs are as valuable as the consumption that we’re able to create on those APIs. And if these APIs are not being consumed, it doesn’t matter how good the service is or the data is that’s behind that API. If the API is not being consumed, that API, quite frankly, is useless.

*RD:* Do you have an opinion on the various architecture styles or frameworks like the REST versus GraphQL, or even SOAP from back in the day?

MP: It’s funny to see the evolution of API protocols over time. We started with SOAP, but some in the audience may think we started earlier than that with CORBA. APIs as a concept have permeated our industry since forever.

Now with SOAP APIs, we have the emergence of web service for the first time. SOAP APIs were notoriously hard to use, hard to consume, very verbose, and so when mobile came out in 2007-2008, everybody needed to create mobile applications. It turns out that consuming RESTful APIs is a much easier endeavor, and we can leverage most of our existing knowledge and clients to be able to do that so we don’t need to have specialized SOAP clients to consume those APIs.

The problem is, as the number of APIs increases over time, it becomes very computationally and network expensive to make lots of requests to all the RESTful APIs that we have. So we started to see new patterns emerge, like GraphQL (opens new window), which allow us to essentially get multiple responses for multiple APIs in one request and one response. That allows us to save in bandwidth which is very important, especially for mobile, and also improve the latency because we’re not sending 50 requests across all the APIs but only one request. In GraphQL, the gateway is going to be responsible for aggregating all those other responses.

GraphQL is obviously one of those trends, but we’re seeing a lot more. Internally especially we’re seeing adoption of GRPC (opens new window), where we want to use faster protocols that do not require computationally intensive serialization and deserialization in JSON. We’re seeing events being used as a way to create asynchronous microservices by propagating state changes in the data, not via a service-to-service synchronous requests, but an asynchronous event that we can store in a log collector like Kafka. We’re seeing that APIs were SOAP only for a very long time, then REST came in, and then now it is many different protocols depending on the use case and the requirements that you have.

*RD:* When we’re talking about a large number of APIs, we’re usually talking about microservices. How do gateways, service meshes, and other architecture-level applications help manage microservice overload?

MP: Building an API is half of the job. Once we have an API, we need to expose the API and govern how we want these APIs to be consumed, either internally or externally. There’s lots of controls that we have to build in the API infrastructure that allow us to manage access to or revoke access, monitor and capture analytics, document the API, and create an onboarding flow for the API. All of these complimentary use cases are critical for that API to be successful. Having an API sitting somewhere does not mean that API will be successful. This is very important at the edge where we want to expose our API to partners, to a developer ecosystem, to mobile applications.

We want to have that whole product journey to the API to be very nice. APIs are products in a way, right? So we have to treat them with the same lifecycle that we treat every other product. How do we version them? How do we decommission them? How do we make them better? API gateways are great at this. API management is a function that allows us to productize an API, either externally or internally, and it allows us to create all these flows and highways to the consumption of the API. Now some of these APIs are going to be consumed internally within the applications themselves—so not across different applications, but within the application itself. There we don’t need to have this higher level management of the API, but what we need is a lower level that’s faster, lower level network management of the API, and that’s where service mesh comes in.

With service mesh, we can reduce and remove that extra hop in the network that we would have by having a centralized ingress. We can remove that and go from service to service via a sidecar model in such a way that we make that performance much quicker because there is less networking hops we need to do, as well as it allows us for a more fine grain, lower level management of the underlying networking. This allows us to implement zero trust. It allows us to implement observability. It allows us to implement across data centers, across cloud failovers. If you experience problems in one cloud, we can automatically redirect to the other cloud. Now the reality is we need both. We need to have a service mesh to create this underlying network overlay that’s secure, that’s reliable, that’s observable, and then some of these APIs we want to expose at the edge or to another team or another application. That’s when API management comes into the picture to provide all those other capabilities. So the way I see it, these are complementary technologies.

*RD:* What’s the security risk with lots of APIs?

MP: Yeah, as a matter of fact, APIs are the biggest attack vector for pretty much every product that anybody is creating these days. Every product runs on top of those APIs, so APIs become a great source of problems if we do not secure them properly. Security means many things in the world of APIs. Security means securing the protocol and the underlying transport, so we want everything to have an identity and we want everything to be encrypted over a secure HTTPS connection in the case of RESTful APIs.

We want to secure access to the API, so we want to make sure that we can create tiers of access for those APIs. We can assign clients and consumers to these tiers in such a way that we can control who consumes the APIs, but we can also then apply specific rules to a specific tier of consumers, such as, “This type of consumer can make x number of requests per second, but this other tier cannot.” There is a third level of security where we are looking at all the traffic that anybody’s making through our APIs and trying to identify patterns that are suspicious, for example, a developer trying to send random fields to an API to see if it breaks or not. Every attacker is going to be exploring and using APIs in ways that were not intended in such a way that they can find a vulnerability. Being able to detect these types of traffic patterns becomes very important to identify suspicious behavior.

*RD:* What’s the most work you’ve seen a single API do? (the largest number/volume of processes behind it)

MP So I’ve seen it all. There’s different types of APIs. There are APIs that are high frequency so there’s lots of value to those APIs, but fundamentally each response is not as valuable so we can afford to lose some of that traffic because it doesn’t really matter. For example, I’m sure that Twitter has lots of API requests whenever somebody wants to open a tweet or send a new tweet. It’s not a big deal if somebody cannot see a tweet; they can just retry. That is high volume but low value for each transaction.

Then there are low volume but high value transactions, for example, when we send a tax return using one of those tax return services. We are never going to use that app and that service ever throughout the year but that one time that we’re going to be submitting our report, and that request happens once a year for each user but it’s very high value. So in my experience working with enterprise organizations and customers, Kong today is the most adopted API gateway in the world in the open-source community, but we also work with great enterprise organizations around the world that are building their API infrastructure on our technology. And I’m seeing all of these use cases so it’s very hard to pinpoint a specific one, but I’ve seen responses of gigabytes of data. So you make one request, you get gigs back, you get this huge response back. I’ve seen APIs taking days to be processed because those APIs probably should have been replaced with a job queue system. There’s pretty much everything out there.

*RD:* For those high-value APIs, how do you ensure reliability without sort of duplicating effort?

MP It’s very important to provide the right API infrastructure. This is why building an API is only half of the job. The other half is to make sure that these APIs are reliable. How do you make them reliable and secure? Well, we need to build that for every API that we have. And there is a series of things that have to happen to make sure that APIs are reliable, but first and foremost, reliability intended as security that has to be in place. Reliability intended as low latency and performance, we need to be able to trace the full stack of our requests to determine where potential bottlenecks could be located in such a way that we can fix them. And then there is reliability intended as being able to measure the API response status codes and response parameters in such a way that we can detect those types of anomalies and then act upon them. For high-value APIs that are low frequency, we’re working with customers where every 500 error is an open investigation that may take two or three weeks to be resolved, because they cannot lose any API request because it would create harm in their reputation and to the final end user. There are different levels of reliability that we want to achieve.

Being able to also replicate our infrastructure across multiple clouds and multiple regions in such a way that we can tolerate unpredictable failures in the underlying infrastructure becomes very important. When we have lots of APIs, it’s very hard to think of these problems on an ad hoc basis for each one of these APIs and it becomes much easier to provide this reliable infrastructure for APIs to the whole organization in such a way that we can cater to everything that’s creating APIs and not just a subset of it.

*RD:* In the next five to ten years, how will the ways that software services talk to each other change?

MP I am speaking with customers that are telling me in the next five years they’re going to be creating more APIs in the organization than all the APIs they’ve created up until now. So what we’re going to be seeing in the next ten years is an incredible amount of scale. And scale is both exciting and frightening. Scale is exciting because it allows us to build faster and better, and this is why we’re adopting APIs. APIs allow us to turn every product and every silo into a platform. There is lots of value in that because we can build products faster on top of that, we can create ecosystems that are much more efficient, like partner ecosystem across the globe. There is lots of business value in that scale that we’re going to be creating, but there is also a requirement to have the right infrastructure in place so that that scale can be enabled in the first place. If we are not making the application teams that are building all of these APIs extremely productive whenever they ship a new API, then the application teams are going to be worrying about all these complementary concerns that they shouldn’t be worrying about. That’s not their job. So it’s very important that as we prepare for this type of scale we make sure that the application teams are builders of APIs but not builders of infrastructure. We want them to be consumers of infrastructure and builders of APIs.

*RD:* Was there anything else you wanted to touch on before we sign off?

MP No, this has been a fantastic conversation. APIs are fundamentally changing and shifting the way we think of software. The way I see it, APIs are providing us the opportunity to create an assembly line of software where you pick and choose different pieces like an assembly line, and put them together to ship new applications in a better way, in a faster way. They are fundamentally changing how we are building software in the digital world. So thinking about APIs really is thinking about the future of the business, because without an API vision there is not going to be a business vision that is going to be successful, because that business vision has to rely on an API to be successful. So it’s becoming very strategic for every organization these days.