The Changelog: Software Development, Open Source - Kong, APIs, Microservices (Interview)

Episode Date: December 5, 2015

Ahmad Nassri from Mashape joined the show to talk about Kong, an open-source management layer for APIs and Microservices.

I'm Ahmed Nasri, and you're listening to The ChangeLog. Welcome back, everyone. This is The ChangeLog, and I'm your host, Adam Stachowiak. This is episode 185. And on today's show, we're talking to Ahmed Nasri, talking about Kong, the open source management layer for APIs. We're talking about what it is, why it exists, the open source management layer for APIs. We're talking about what it is, why it exists, and why MashApe is behind it. We had four awesome sponsors,

CodeShip, Braintree, Harvest, and also DigitalOcean. Our first sponsor is CodeShip, and they've got an awesome ebook totally for free for you to download today. Head to resources.codeship.com slash eBooks, and you're going to see a book there called Why Containers in Docker Are the Future. Now, this eBook is going to help you learn what the differences are between your traditional virtual machine and container stacks. You'll also learn about Docker and its ecosystem and why it's such a big deal. And you'll also learn about Docker and its community and how they're helping to standardize the container workflow. Now you can go to resources.codeship.com slash eBooks right now and download this eBook. And I shouldn't tell you this, but when you do that, you're gonna get

access to three other eBooks from CodeShip, diving deep into Docker, continuous delivery, and how to do all this with native Docker support. Head to resources.codeship.com slash eBooks and download those eBooks right now or head to our show notes for the link and tell them the changelog sent you. And now onto the show. All right, everyone, we are back. It's Jared here with another episode of the changelog. All right, everyone, we are back.

It's Jared here with another episode of The Changelog. Today, I'm joined by Ahmed Nasri, who is the head of engineering at Mashape and an advocate of all things open source. Ahmed, welcome to the show. Thank you for having me. So we're excited to talk to you. We also are excited about this little thing called Kong, which sounds really cool, also is a little bit nebulous to me,

so I think this will be a good opportunity to learn all about it. Kong is an open-source management layer for APIs, which delivers high performance and reliability. We'll get into Kong in a little bit, Ahmed, but at first I'd like to just get to know you a little bit and hear a little about your history because you have what I think is somewhat of a fascinating history um what do you think where should we start sure we can go back as far as you want so uh well let's start where you're at right now. So you live in Canada. That's right. I live in Toronto. Okay.

And as we were talking, kind of setting this call up, you were in London for a little while. But that was just a, was that vacation or work related? It was work related. I actually travel a lot for conferences, events, and as part of the MassShape clientele and work we do. We also have teams across the globe and clients across the globe. So we actually have a team in London as well, as well as the company itself is based out of San Francisco. So if I'm not in Toronto, I'm usually on a plane heading somewhere or on the way back. Yeah. But you're not a Toronto native. You were originally from Syria. So maybe let's go all the way back your childhood. You had what I think

was an interesting childhood, especially with access to PlayStation magazine that other people didn't have. Give us some of your backstory of how you came from Syria to Canada. Sure. So I was actually born in Damascus, Syria. And back in the 80s, I was born in 85. Syria was still kind of in the pre-crazy state that it is now, but also pre-opening up to the world. So growing up in Syria was, you know, normal childhood, normal life. We never really had any problems or issues. This whole concept of terrorism and terror in general and fighting and war was really foreign to us. Um, and, and, you know, just like, um, for me as, as a child growing up, you know, I'm, I come from a Sunni Muslim background, my family's Sunnis. I went to a Shiite school, uh, and most of my friends were actually

Christians. Um, so you can, you can tell there's a big diversity there in the country. So I actually got a little bit of worldly education growing up within Syria before even leaving Syria. But, you know, I think for me, there's always been more to see in the world, more things to explore. And I kind of gravitated towards the technology space and the Internet in general. I remember when I was still like 12, 13 years old, we never had internet in the country. We didn't even have cell phones back then. And the only way you can get access to the internet is through long distance dial up to the neighboring country, which is Lebanon, and which was highly illegal as well.

So I used to actually sit in my dad's office office uh and uh long distance lebanon just to get access to the internet uh from a service provider called siberia at the time which is a weird name to choose given that we're in the middle east but anyways um so siberia was my internet access provider my very first one which was based out of lebanon and it was this was highly illegal so the government had the kind of secret services and like the like the internal police is what they call what we call them and they would go around and make sure they listen in on all the phone communications in and out of the country because you know it's a dictatorship and they're paranoid about everything so of course internet

access was really forbidden because why would you want to know about the world why would you want to be educated about you know how sciences and the rest of the world actually lives? So they would go around and try to shut these down. And I remember being, you know, a 12-year-old sitting in my dad's office late at night, browsing the Internet, looking up Yahoo's homepage, trying to learn things about technology and computers. And, you know, the knocking on the door would be like at 12 o'clock at midnight and you just go quiet and you turn off all the lights and you just pretend you're not there because otherwise they would really try to break through

and get in there. Really? Like they're actually coming after you? Oh yeah. Wow. But the reality is they're not coming after you to punish you. They're coming after you for bribery so that you can bribe them and then they go back to their friends and and families i guess oh i see so it's it's illegal but

also the enforcement of it is somewhat lawless so they're not going to you know do it by the books they're gonna exactly it was completely corrupted um which is why a lot of people got away with it because essentially you bribe your way through it and you're fine a few years later we started getting internet service from the government, provided by the government and, you know, cell phone service started becoming the norm. And then, you know, for me, like that just evolved into actually getting into the entrepreneurial mindset of actually using this thing called the internet to my benefit and trying to capitalize or monetize on it.

So one of the things I used to do as a kid, I used to go online and find all the cheat codes to computer games or PlayStation games and then sell them to my friends who didn't have internet access, didn't even know what the internet is. So there was this thing called PlayStation Magazine back in the day. And I used to access it online and they had like a big directory of all the passwords and all the games and their cheat codes. So I would actually access that online and get all the information from there and follow the articles through. And then as my parents travel or as we go out as families to trips, we would usually go to neighboring countries, to Lebanon, who had less of a global boycott and restrictions on trade as Syria did. So they actually imported a lot of things. And two of the main things I used to just love grabbing when I was in Lebanon visiting our PlayStation magazine, the actual physical copy,

and Pepsi, because we never had any Pepsi from Syria. Not Coca-Cola? Come on, man. No, no, it's all Pepsi all the all the way are you still pepsi to this day or have you still pepsi to this day so you're still on the dark side okay uh so you're getting these playstation magazines and you there are cheats in the back of them is that right i remember psn but i wasn't a reader yeah i was so mean, it was also all fully in English and I was still kind of learning English at the time. So, you know, it was both kind of an adventure for me to learn English and read better these kind of magazines

as well as go online and discover things online that are predominantly in English. But also as being a kid and playing video games, that was kind of my only way to see what's coming up next. So I'll be talking about the next Tomb Raider version that's coming down in a couple of months, but we probably won't see it for another year and a half or two years until the smugglers get it into the country. And that's how you got everything back then, because, you know, it was a boycott situation.

There was no trade, international trade happening. So electronics were illegal unless they came from other communist countries, which of course they don't have PlayStation there and they don't have video games there. So yeah, that was kind of the early childhood and the early kind of foray into leveraging the World Wide Web for entrepreneurship purposes. So you would actually sell these codes to your friends, is that right? That's right i would sell sell them the cheat codes and and or trade them for uh for treats and candies and kind of toys and what's the what what's the uh what's the market value of like a single cheat code back in the day do you remember well i i went with like the uh the lowest paper bill, which was the five Syrian pounds paper bill.

Okay. If I do the conversion rate, at the time, a single Syrian pound, sorry, a single US dollars equated 50 Syrian pounds. So it was pretty cheap. Pretty cheap. Yeah, but for the economy of the country that was actually not very not very cheap because especially for kids who don't actually have money they're like early teens type kids like 13 year olds you know is that the kind of the age group that you were you're

dealing into a 12 13 year old and younger uh obviously the older kids wouldn't wouldn't pay you any attention so right but the younger kids are more gullible so it's and sell more to those so i mean it's putting a trend here we we recently had mitchell hashimoto back on the show to talk about auto let's see what episode that was 180 and he got into the game kind of uh selling cheats as well to a certain degree um but he was basically writing bots for neopets nice and that was kind of what his entrance into maybe not his entrance into software but uh something that he you know remembers as kind of a launching off point you started off with these playstation magazines and other such things and

talk about knowledge is power that knowledge is like literally money in this case that's right um how did you and you're leveraging that how did, how did it turn into software or coding or where'd you get past like video game consoles and, and into software? So the, the, the cheating industry itself evolved at the time, more like the, uh, the tooling around it evolved. I remember there was a thing called the shark that you actually plugged into the back of your PlayStation to get, you know, a database of cheats automatically enabled on your device. And that required a little bit more of a hardware hacking, a little bit of hardware knowledge. And then also the PlayStation itself, because we were in Syria, you can't get the original discs for games. You have to get copies. And there was like hardware

kind of restrictions in place to prevent that from happening. So I had to learn more about both the hardware aspect and the software aspect of how these tools work, namely the PlayStation device itself, the internal of the motherboard on it and how actually all the protections in place were. And by looking at that information up online, as well as kind of working and collaborating with other people doing the same thing,

we kind of self-taught ourselves how these things work. And of course, there's tutorials online for almost everything, even back in those days. So that kind of evolved into a little bit of hardware hacking. And then that itself, along the years, I kind of transitioned from the video game stuff to, especially as the country started getting cellular service to mobile phones and mobile devices. And I remember one of my very first devices was a smartphone back then. It was called the Nokia 7650, which was this Symbian S60 operating system, if anybody remembers that anymore.

And that was basically where people didn't even know what a smartphone is and the limitations of the, there was no marketplace, there was no app store, there was nothing like that. But people still built software for that. minds off with it because they never imagined their phone could have games and other applications and calendars and things that they can use it beyond just making phone calls. So that kind of evolved as well into both another entrepreneurial adventure of figuring out how to build and make applications for the Symbian S60 and then just also selling that, of course, because they all became part of the the same mindset of find the technology leverage the technology to your needs and then win and profit sounds like uh sounds like you have way more of an entrepreneurial spirit than i do i i probably

would have just uh taken the playstation sheets and went and cheated at the game by myself and never went anywhere from there. But you've gone quite a ways. I mean, now you live in Toronto, so that's a long ways from Syria. Why don't you tell us how you came to be a Canadian, so to speak? So my parents actually applied for immigration to Canada before I was even born. But since the immigration process back there, and even back then, was just so convoluted and took so long, they never actually heard back and eventually forgot about the whole thing.

And then, you know, obviously had me and my brother and, you know, life goes on. And then I remember just before my 20th birthday is when they actually got a letter from the canadian embassy saying oh yeah i remember that thing you applied for 19 years ago yeah you're you're here you're good teen years yeah so they uh wow they finally got like the the green light to actually come to canada and because at the time they applied before we were even born my brother and i didn't have to reapply on our own because otherwise we have at least for me i would have to apply again as an adult because i was over 18 so um yeah that

was we basically had my uh 20th birthday in in damascus that was the last birthday i ever had in damascus And a couple of months later we were on a plane and we came to Canada and we just pushed the reset button and started our lives all over here. Wow. So nobody in your family had ever been to Canada. Is that right? No, we've actually had like distant cousins and family members who kind of came here years and years ago. So like my dad's cousin, second removed. But I mean, in your immediate family, like your parents hadn't come and visited or had they?

Okay. No, it was fresh, literally fresh off the boat and all, and all sense of the word. So the four of you moved from Damascus to Toronto, sight unseen, just picked up and just started life over again in Canada. Yep. That had to be some wild ride. It is. And, you know, it's not like in today's world, in today's media, they like to portray the

Middle East and that part of the world as being completely disconnected from Western culture. It isn't. The reality is we were very engraved in Western culture as it was, whether through obviously the production of TV and Hollywood movies and all that, or just by, you know, being part of the world, of course, we were very aware of culture around the world. And my dad has actually been like in his youth, he traveled around the world. He's seen a lot of places around the world.

He had never came to Canada, but, um, he lived a while in Paris. He lived a while in London and he traveled in all, all over Northern Africa. So, you know,

I got a little bit of a foundation to start on, but obviously there's, there's a, there's a bit of a culture shock that you get as much as, as much as you think you are prepared. There's a little bit of a culture shock that you get as much as you think you're prepared there's a little bit of a culture shock that when I first walked along downtown Toronto and I looked at the skyscrapers, I just couldn't

look down. I was just continually looking up because it was amazing. We have buildings in Damascus. We have tall buildings in Damascus but not really to the extent of the skyscrapers that we have in Toronto today. Of course, in developed cities around the world as much as we do. But that was kind of the biggest, one of the very first memories I remember coming to Toronto is the skyscrapers.

It was so huge and massive. So that's one part of it, obviously like the, the scenery changes around you. And then there's the other part that it was, you know, mid July and I was still walking around with a heavy, thick winter coat because I was freezing my ass off. Right. Having grown up in the middle Eastern kind of temperatures and weather, uh, coming to Canada to go out to adjust to the cold. Yeah.

We have a friend who lives pretty much on the equator over in kenya and he visits here pretty regularly and he cannot adjust to the cold at all i'm you know omaha nebraska so more temperate than where you're at but still gets cold in the winter and it doesn't even matter what time of year it is dude's always cold yeah i can certainly relate so that brings you to toronto and um no doubt you've had a bit of a career since then you're now the head of engineering at mashapes so briefly and then we're going to get into kong right after the commercial break but briefly can you just uh tell us like career-wise how you went from okay i'm moving to toronto age 20 and now i'm head of engineering at mashShape?

So the obvious push from my parents was for me to go into university and continue my education. I had done a year of computer science in Syria, but at the time, the universities here just didn't accredit everything that I've done. So they wanted me to start from scratch, even go back half a year in high school, which I found to be unacceptable. So I basically said, screw that. I'm just going to go and do my own thing and went back to my best friends, the internet and going online and connecting with people around the world. And basically I got myself into PHP before I even came to Canada. I was starting to develop things and building custom stuff for people on custom websites.

And then I continued that in Canada. And slowly I went from just hacking little PHP projects on things like Odesk and services online to people to joining a company in Toronto and actually just full-time job and doing PHP development as green as I was at the time. And slowly just made my way through and growing and learning new technologies and new systems and meeting new teams and building new products. And it was all really around open source in general, but evolved from different languages and different systems and services

to where I am today working with MassShape, building APIs and tools for the rest of the development community. Very cool. Well, I think that's a good place to stop. We will take a break here from one of our awesome sponsors. And on the other side, we're going to dive full into Kong. So stay tuned for that. Braintree is all about making developer lives simpler with code for easy online payments. If you're searching for a simple payment solution,

check out Braintree. For mobile app developers out there, the Braintree V.0 SDK makes it easy to offer multiple payment types. Start accepting PayPal, Apple Pay, Bitcoin, Venmo, traditional credit cards, and whatever's next, all with a single integration. Enjoy simple, secure payments that you can integrate in minutes, and developers, they've got you.

Don't worry about taking days to integrate your payments. With Braintree, it's done in minutes. And if you don't have time, give them a call, and they'll handle the integration for you and walk you through it. Braintree supports Android, iOS, and JavaScript clients. They have SDKs in seven languages,.NET, Node.js, Java, Perl, PHP, Python, and Ruby, and their documentation is comprehensive and it's easy to follow. To learn more and for your first $50,000 in transactions fee-free,

go to BraintreePayments.com slash changelog. All right, we are back with Ahmed Nasri, and we are ready to talk about Kong. Now, I'd be remiss not to give a shout out to Justin Dorfman, who's a changelog member, who helped us line up this show. He's very interested in Kong as the developer evangelist at MaxCDN. Sounds like lots of people are interested in Kong. Can you give us the elevator pitch? What's it good for?

What's it do? Why does it exist? So Kong is the API management and abstraction layer for your APIs and microservices. It allows you to securely and easily configure APIs and microservices at scale without having to deal with massive deployments and re-architecting systems or even changing the way you design your APIs. It really works on the HTTP layer alone, and it's very unopinionated about how APIs are done or built, which is part of the appeal to a lot of people because in today's world of API technology, people come in from SOAP, people come in from REST,

people come in from different kind of mindset to what's the best architecture and format to deliver APIs. And in a lot of ways, a lot of the tools and services out there are very opinionated for various reasons. So what we did with Kong, we wanted to keep it unopinionated and wanted to keep it abstract and more associated with the HTTP layer, which is the spec that the entire web runs on. So that's what really Kong gives you, is the ability to control, manage,

and configure your APIs in a way that is completely agnostic to how your backend or actual APIs operate. So just notice that you use APIs plural there. So this is for somebody who has a handful, maybe half a dozen, maybe more different APIs that they're offering, either publicly or internally? So not necessarily. And this is, again, part of the chaos that the industry is in today.

It's not necessarily a negative state of chaos. It's just a kind of entropy state where things are just evolving and happening around us. So MassShape actually started out as, well, that first product was the API marketplace. And kind of the short pitch for that, it's eBay for APIs. So API providers and publishers can come in

and publish their API through the marketplace, whether it's free or monetized, and then expose it to a vast majority and a vast community of users. And then the consumers of the API or people who are building applications can come and discover and select APIs that fit their needs for building their applications. As part of being the marketplace, our tools and our proxies and our marketplace itself had to literally support every which way that API providers build APIs and had to support every which way that API consumers expect to consume APIs. So we can't be opinionated. We couldn't be more subscribed to a single way of building APIs or a single standard or approach. So all the talk about SOA versus microservices versus REST versus SOAP versus X and Y and Z,

we just say a thumbs up to all of that because we had to. Is there a real difference between SOA and microservices? Is there a distinguishable thing or are they just terms? You're touching on war territory here. Let's hear it. I don't have an opinion, so you can just state yours and we'll move right along. It'll be a war. My opinion is a bit deeper than that.

I think a lot of people in the industry have a big, big issue distinguishing between modularization, componentization, and microservices. So these three things are completely independent and overlapping in a lot of ways. Typically, in my view, modularization is more about the code. You modularize your code. So all the benefits that people talk about, about microservices is just a way that you can package things together. There's single focus and testable and blah, blah, blah.

Yeah, but that's more about being modular. So you can do that as part of codes and libraries and the way you organize your project. Same thing for components. Components are just a bunch of modules put together to serve a purpose. So you can talk about a module being a login module, or you can talk about a module being a username lookup module,

and another module being the password verification module. And then together they become the login component. And then in terms of services or microservices, as the term is today, same thing with SOA, it's more about how these components, which exist to compose multiple modules, are deployed and managed and operate independently. Now, the only thing microservices introduces

that's a little bit kind of, at least if you're here to listen to some of the advocates, it's a little bit different than SOA is that it's entirely focused on the HTTP layer, as opposed to SOA doesn't really prescribe to being over HTTP or not. It just happens to be in a lot of cases, but microservices focus on, no, no, no, let's just do things as the web has evolved over HTTP. Let's do things as well over HTTP between our products and tools and services within it. So I think, you know, generally speaking, and again, because we had to be the marketplace for so long,

we were fine with all of that. You know, obviously people have personal opinions, but at the end of the day, if you're building a product that's serving, solving a problem for your users, they don't really care about, are you RESTful or are you SOAP or are you microservices or SOA or so on. The point is a product.

And that's kind of our message that we carry to people. When we talk about an API, an API is a product. It's not just a data output. It's not just a extension of a product. This is a product of itself because the users of that product are the developers who are supposed to be interacting with it. So just as we have product teams and marketing teams and kind of big initiatives around product marketing, we should have the same thing for APIs because we do see them as products.

So when you have a company that builds APIs for extending their offerings to the bigger market and the bigger community, if they don't put the same effort they put behind their iPhone application or the Android application or the website in terms of marketing, in terms of product management, then most likely is the API itself is not going to be as loved or as there's not going to be as much attention being paid to it as a product on its own. So for us, we look at APIs as these individual products. However you want to look at it, whether it's a multitude of microservices or a big monolithic API or SOA or so on, it doesn't really matter. Yeah. I think we run into just name namespacing issues when it comes to terms like

modules and components and and we we move uh fluidly up and down the stack in our conversations with each other that oftentimes things become conflated because perhaps you're talking about modules at a network layer or i'm talking about them at an application layer or even inside of a code you know a library or something so yeah it becomes we can mince words and i think it's it's still important to talk about these things and and try to come to like one understanding on certain terms um but i think what you have here with kong and what you guys are focusing on with microservices is let's keep it http and then on in lieu or in light of that,

let's realize that all these APIs, which we view as products, individual products, they all share these common attributes, these common needs. And so why are we all implementing auth and logging and rate limiting over and over and over again in different ways when you could have a layer that sits in

front of your apis and provides that is that does that paint the right picture yeah that's precisely it and kong actually evolved in the marketplace itself because you know as virtue of being able to offer monetization services for api providers through the marketplace that means we had to manage their their api calls as well meaning proxy so everything has to go through the marketplace, that means we had to manage their API calls as well, meaning proxy. So everything has to go through our system so that we can track it and appropriately charge for the API calls and so on, and then process it for the consumer. So we actually built Kong for ourselves. And because, like I said, our need for the marketplace was to be everything for everybody and actually not be opinionated at all. That went into the DNA of making Kong.

So the idea that we have the authentication and rate limiting and caching control and all these kind of things built into the core really started up because of the marketplace need. But then what happened is as the product of the marketplace grew and our clientele kind of became more diversified, we had more enterprise clients who wanted to have things running with their own infrastructure. We had people who were worried more about the latency and they were perhaps using regions on AWS that are not as close to our regions. So then we had to worry about how do we actually become

a global distribution of proxy service across multiple regions without adding any delay or without losing any context of the data. And all these things played into the kind of the makeup and the DNA of Kong. So like you said, it's this idea that when you're focusing on building a e-commerce product or you're focusing on building even a mobile application or an API for a mobile application, your goal is not to do authentication. Your goal is not to do logging, your goal is not to do authentication. Your goal is not to do logging. Your goal is not to do transformation or rate limiting. Those things you have to do because of the nature of how the web works and you want to have security and you want to perhaps add some protections to your API layer.

But the reality is, in many cases, you have to reinvent the wheel every single time in either doing that or luckily in today's world we have libraries and tools that you know maintained by the open source community that give you a lot of this functionality but at the same time you're still responsible for the maintenance of them so think in a scenario where there's a company that has uh don't go too far talk about netflix they're one of the greatest kind of examples of massive distributions and api management tooling that they've built yeah they have multiple data centers across the world they have multiple clients multiple of massive distributions and API management tooling that they've built. Yeah. They have multiple data centers across the world.

They have multiple clients, multiple applications, whether it's, you know, PlayStations or mobile phones or desktop TV, smart TVs calling their systems and their APIs to get the data out and get the streams going. They probably have, you know, a heck of a lot of APIs that they have to maintain serving different purposes. So for each one of these APIs, they probably have to heck of a lot of APIs that they have to maintain serving different purposes. So for each one of these APIs, they probably have to have an authentication layer.

For each one of these APIs, they have to have some logging mechanism. They have to have some control over what the API is doing. And perhaps as they evolve and as they grow as a company, they want to change these APIs, add new versions, add new functionality. All of a sudden you're faced with this massive interconnected web of dependencies and repeatable

things that you're doing over and over and over again. Obviously, like you said, the examples that rank true for a lot of people is authentication is one of the simplest ones. You have multiple systems, multiple APIs. They each have an authentication. It's the same authentication mechanism. You're doing OAuth on both, or perhaps you're doing JSON web tokens or something similar, but it's the same thing. Why does it have to live in two different places?

And then as part of having to be on the application layer itself, it has to also scale with it. So scaling problems become also an issue and how do you maintain the session and the information across servers and all that stuff. So with calling, the idea is that you abstract all of these things away and you move them to the proxy layer. And the reality is a lot of people are already running Nginx as their HTTP server or their proxy server. And that's also why we chose Nginx as the core for Kong. So Kong actually runs on top of Nginx.

And what it gives you is the ability to configure Nginx servers and configure runs on top of Nginx. And what it gives you is the ability to configure Nginx servers and configure the proxy mechanisms of Nginx dynamically through a RESTful API of itself. So in the olden days, you can actually just set up Nginx and configure it to do everything you want, including customization of things like authentication beyond just the basic authentication. You can use Lua as the scripting language with OpenResty on Nginx to customize it. But you would have to do it in configuration files. And you have to deploy these configuration files

across your cluster, and you have to make sure they're all in sync, and you have to make sure everything is updated at the same time. And sure, there are tooling that help you with that, things like Chef and Ansible and CloudFormation on AWS. But that's now becoming a big, massive undertaking for a small team or even a bigger team in an

enterprise company. Now they have to deal with different departments doing different things, perhaps between development and DevOps and IT and so on. So with Kong, you literally have one thing to deal with, which is the API. You actually make a call to the Kong admin API in itself and tell Kong to create a new endpoint. You tell Kong to add authentication. You tell Kong to add logging and so on. And you do that through RESTful API calls, which we're all familiar with.

We can easily make an API call in the command line using curl. And these things are automatically synced up across all the clusters without the need for you to redeploy or do it again for every node in the cluster. So let me stop you there for a second, because I'm trying to make sure that I have the mental model down right. When I first started reading this and looking at your diagrams, I thought, okay, Kong is kind of like network address translation that a router might do, where you have multiple services sitting behind it but one representation but now i'm starting to think maybe if i had let's say i'm netflix

and i have two public apis i have a search api so you can find movies and i have a q api so you can you know see what's in your queue and maybe those are separate would i have two kongs or i have a single kong with multiple endpoints, one representing each of those two single, yeah, single Kong, multiple endpoints. So isn't it, is, is Nat kind of a good analogy to think of it as a, I know you said proxy, which makes a lot of sense too, but as a single entity representing multiples. Yeah. I mean, that's a good analogy, of course. Um, so you can, you can, and this is the part about us not being opinionated. You can use it as a single entity that represents multiple,

or you can use it as just the translation service to point things in the right direction and or add logic on top of the request lifecycle. So what happens when you have that one, you know, stubborn API that wants to do its authentication just a little bit different than the other ones or has a you know you always have these edge cases where yeah these three things are 99 the same but that one percent is super important um do you set up a separate con at that point are there ways that you can have some diversity in your authentication

for instance so let me give you some you some numbers for the audiences as well to kind of get the concept of the scale that we're operating within. So in the marketplace we have, I think, something around 170,000 active developers. We process a lot of transaction, monetary transaction for paid APIs, I think around an average of $85 per transaction. And we have hundreds of public, sorry, thousands of public APIs and hundreds of thousands of private APIs that are not published as part of the public marketplace. We process, I think the

last numbers we were looking at, I think somewhere around like 10 billion calls per day. And a lot of these APIs are even heavy APIs. So for example, Imgur uses the API marketplace for their paid API. So if you ever use the Imgur paid API that goes through Mashhape's infrastructure, meaning all these people that are uploading

and downloading images for displays in the mobile applications, we have to process that. That entirety of the scope I'm describing now between hundreds of thousands of developers and billions of calls is operating on four medium-sized AWS servers running Kong. Four.

Four. And that's, to be completely fair to Nginx, that's really mostly Nginx's efficiency. It's not really, you know, nothing. There's no special sauce that we're adding in Kong that's making Nginx more efficient. This is really Nginx proxying being super efficient and super lightweight.

So the layer that we're introducing, even though it is a layer, it's not really adding much in terms of resource usage. And of course, depending on your network setup, it's not really adding anything in terms of network latency at all. And as part of the plugin architecture that we've created in Kong, the idea is that you can add and remove logic pieces on top of API routes as you wish.

So you might have, like you said, you might have two APIs, two different endpoints or upstreams, and you want to make an authentication for one but not the other. That's the whole point of the plugins. You can enable them per API. And then you can even make it more granular so you can enable and disable things per consumer. So say we have this concept of consumer in the system, and consumer is this

abstract notion of anybody or anything that's accessing your APIs. So it could be a user. That means you create a consumer that matches every user in your system. Or it could be an application, or it could be a system or another server that's trying to access your APIs. It's just consuming your API. So you can set up rules and enable the same whole plugin configuration for each of these consumers. So as an example, and I use this all the time when we're doing our webinars,

a typical use case is to have rate limiting in an API. So you would want to enable rate limiting on your API. So you have API A that has a rate limiting and API B that has rate limiting that's more appropriate to the different use cases of these APIs. But say you've identified a troublesome consumer that's, you know, just making too many calls or perhaps sending you bigger bodies or doing nasty things that you don't like. You can make the exception for the rate limiting specific to that consumer to introduce even more harsh rules on the rate limit per the minute and per the hour. So you can actually become very granular in the way limit for the minute and for the hour. So you can

actually become very granular in the way you design your API interaction and your logic. And Kong becomes kind of the protection system in front of your APIs, not just to protect you from number of calls that's going to hit your backend, but to design the experience around your API as well. So one of the things we offer as well is a transformation plugin. So you can actually change the request before it even hits your upstream server. So say you're doing one of the biggest problems that people deal with is versioning. So you know, as your application evolves, as your products evolve, you want to change things up and add more features and functionality. But if you're an API provider, you don't want to break the experience for older application developers or users of your API. So with tooling like transformation, you don't want to break the experience for older application developers or users of your

API. So with tooling like transformation, you can actually bridge that gap. You can make it so that if somebody is making calls with the wrong object name or the wrong request bodies, you can actually change those up before they hit your upstream. So you're always in a green lifecycle on your application in the upstream on your actual application stack, but you can expose different things on the API proxy layer that can still benefit people who are still in the transition period of going up to your most recent kind of documentation, most recent version of your API.

Yeah, that sounds great for keeping your application code super streamlined and dealing with the complexity of those, basically normalizing those version calls at the at the proxy layer, that sounds like a pretty big win. So what about something a little more? I don't know a little more complex than authentication? And what about authorization? Not who am I? But what am I able to do? Is that something that you guys have found makes a lot of sense at a Kong layer? Or does that tend to have to be application specific?

It depends really on the kind of application you're trying to serve behind Kong. So we have clients and customers and users of Kong that fit both scenarios, which is going back to the consumer thing that I was talking about. That's why we made it an abstract thing. So one of the features of the consumer entities in Kong is that each consumer can have multiple credentials across multiple authentication methods. So meaning you can have a single API that you can enable basic authentication on

as well as OAuth authentication, as well as JSON web tokens on, and you can have a single consumer that can have a credential for OAuth and multiple credentials for basic authentication, maybe multiple credentials for OAuth as well, and multiple credentials for JSON web tokens. So the benefit of that is, if you think of scenarios where, and this is one of the things I was helping one of our clients with, if you think of a scenario where you have a mobile

as a product, if you think of your products as mobile and then Android as a platform and iOS as a platform, but it's the same product and you want to apply the same rules to the product in general, rather than creating the consumer that represents the Android application and the consumer that represents the iPhone application, you just create one single consumer that represents the mobile product. And then that individual consumer has different authentication methods for the different platforms. So the granularity there becomes, you know, really up to you of how you want to control that. The other aspect of this becomes, you know, if you have a partner, like you're, you know, you're a company A or Acme and you want to give access to another company. You know, they have 15 developers.

Are you going to go and create 15 consumers for each of these 15 developers? Maybe. Or maybe you can just create a single consumer and give them 15 credentials. That sounds like, you know, going generic and making it easily customizable in this way makes a lot of sense when you're trying to fit all those different use cases and you can kind of put the puzzle together the way that makes sense for your product um as we all know every you know software development design decision has trade-offs have you found any draw drawbacks to the consumer

idea and just this very generic uh system in general yeah Yeah. In fact, it's sometimes, obviously, once people get it, once people get how flexible it is, they love it. But just to get people through that journey of getting there, and I think it's just undoing years of bad practices. And unfortunately, what the rest of the API tooling industry, it's undoing all the brainwashing that, you know, let's call them the competitors have been doing in terms of saying, no, this is the better way of doing things, which is our way.

And typically what you see in similar products out there, which, you know, Kong is the only really the only one that's open source and free and fully supported by a company with all its backing behind it. What you see is these companies offer you products that, you know, does the similar thing as Kong does, but they're monolithic applications. They're very opinionated. They're very heavy on resource usage. And they want you to basically go back to the drawing board and redesign how your application

logic works or how you build your APIs. So the adoption scale there becomes, you know, a very high ramp up for people to adopt these tools and these products. And part of that, what ends up being the result is developers end up thinking in that one solo way of thinking or just one line of thought of, okay, well, this is how we do APIs and this is how we do API management. And then of course, having been paying hundreds of thousands of dollars for these tools for so many years,

somebody in the accounting department finally says, enough is enough, go find some alternative. And that's when we start coming into the conversation as they discover Kong and talking about the open source and the fact that it's free. Obviously, that's the starting point for a lot of people. And then we get into this conversation about consumers' objects and Kong being unopinionated,

and it's really up to you to design your architecture the way you want it. In a lot of cases, developers take a step back and say, that sounds too loosey-goosey. I don't want to get into there. Just tell me what the better way to do it is. And that's just really, like I said, undoing years of bad practices or things that were shoved down on the developer community by these tooling providers. And that's also partly why we decided to make Kong free and open source.

Because we see API management and tooling as a commodity that everybody should really have access to. It shouldn't be something that you have to pay millions of dollars of per years for pay hundreds of thousands of dollars for license fees for, to get access to it. So that's kind of the drawback, but it's also the same in the same breath. It's also the incentive for a lot of people is that, yeah,

you actually get the freedom to do whatever you want. Yeah. Very good. Well, let's take a break here. When we get back, I want to talk about some of your technology choices. You gotua in the mix you got cassandra in the mix also talk about the enterprise edition and kind of the business side of this from mash's perspective and how that fits into

the open source stuff so that's on the other side of the break and we will be right back if you thought harvest was only about time tracking, check again. Fast invoicing and payments. You can easily create and send invoices and accept payments with PayPal, Stripe, and many more. You got expense tracking without the mess. You got an iPhone or an Android app to go on the go with you. Snap photos or receipts and store them in the Harvest app. You can also connect favorite tools like Slack and use chat commands to start and stop your timers.

Head to GetHarvest.com and start your free trial. And once that trial is over, use our code CHANGELO to save 50% off your first month. All right, we are back talking about Kong. And I want to talk to you a little bit about the technology choices. You already mentioned Nginx as a little bit about the technology choices. You already mentioned Nginx as a huge aspect of what Kong is. Notice that you're almost 100% Lua in the code base.

Curious about that decision and then just your thoughts in general on Lua as a programming language and how it's been to build Kong with it. So the choice in Lua was in a lot of ways made for us years before. The Nginx community has actually been the adopters of Lua as the scripting language. And for those who are not familiar with Lua,

Lua is a really fast and powerful, lightweight, embeddable scripting language and it's meant to be embedded within other applications. So for example, Adobe actually uses it a lot in their products. And it's actually made its way into a lot of embedded systems and embedded application as a scripting layer on top of the application itself. So it kind of already fits that model of Nginx. It's a HTTP server.

It's configuration-based. It doesn't really have that dynamic aspect or dynamic language aspect to it. So OpenResty was one of the first application servers that ran on top of Nginx and using Lua, of course, it was written entirely in Lua. So it just introduces the bindings to the internal Nginx objects and systems. So essentially Kong is written entirely in Lua

with OpenResty on top of Nginx. So it actually uses OpenResty? Yes, correct. Okay. I remember I checked out OpenResty a while back and I thought it looked really cool. It was like a little bit too low level than what I needed. And I didn't necessarily need the performance at the time,

but I thought this is very interesting. I wonder if anybody's going to build anything interesting on top of it. So it's kind of funny to find out. Here it is, still actively developed, I assume, and here it is sitting inside of Kong. One of the, actually a number of the core OpenREST contributors are also contributors to Kong as well. So that's kind of a validation as well for what we're doing

in terms of going in the right direction. And generally speaking, the DevOps community and the IT community, that's usually been more of where the HTTP server management lies, as opposed to developers who are going to dive in and script or configure Nginx. The Lua adoption is already the highest there is. So everybody's on that train, I guess. And recently, some people might be aware

that Nginx actually announced that they're adding JavaScript as a scripting layer to Nginx, which was met with a lot of raised eyebrows and confused looks. Some consternation, yeah. Yeah, I think, I don't know if it's really a trend of, hey, let's JavaScript all the things.

Don't get me wrong, I'm a fan of JavaScript, but I don't really if it's really a trend of, hey, let's JavaScript all the things. Don't get me wrong. I'm a fan of JavaScript, but I don't really understand fully their motivations. And I didn't actually get to speak to them at all recently. So I want to have that conversation with them just to understand it more. But the early feedback from the community trying the beta of Nginx with JavaScript was that the performance was just simply not there.

And we're talking about 100x performance differences between scripting something with Lua versus doing it with JavaScript. And that's probably because they're doing their own virtual image as well. It's not exactly JavaScript because it's missing a lot of the ECMAScript standards and specs in there.

So I'm sure they're going to get there and they're going to make more improvements on it. So if Nginx and JavaScript becomes more of the standard and a better performant one that is which is the most important thing for us then of course you'll see JavaScript make its way into Kong as well

huh so at the plugin layer? or as actually cutting over to JavaScript for codes? I think more likely at the plugin layer because with OpenResty, we got a good solid foundation. But the idea that people can come in and write their own plugins, which they can already do in Lua,

although not everybody is familiar with Lua. So JavaScript just bridges that gap a little bit. I can definitely see why the Nginx people would want to add JavaScript just from a perspective of adoption and use of the scripting side of NGINX, making it more powerful for more people. Absolutely. That being said, I've looked at Lua when I was checking out Open RESTing stuff, and it seems like it's a really nice little language. It doesn't seem like the hurdle to learn it and get started would be too much to jump over. How do you feel about that?

It was a hurdle for me to jump over it just to get going into it. But once you recognize some of the similarities to other languages, and it's really just the syntax at the end of the day, that's kind of true to all scripting languages and high-level languages. If you're familiar with a high-level language,

then it's not hard to jump to another high-level language. If you're familiar with a scripting language, it's not hard to jump to another scripting language. If you're familiar with a scripting language, it's not hard to jump to another scripting language. It's usually the cross reference there where it becomes a bit more complicated, where somebody has been doing C sharp or Java and wants to do JavaScript or Lua. They find that a little bit jarring, but once they get over it, then they realize they're not going to get the nice things that they have in Java or C sharp. Then they can start actually being productive. Let's talk about another technology choice when it comes to dependencies,

aside from Nginx, of course, is you have a hard dependency on Cassandra. Can you talk about that? Yeah, so as I was saying earlier, one of the marketplace kind of challenges is because we had to proxy everybody's API calls, a lot of people serve APIs and have their servers in locations around the world that may or may not be close to where our servers were. So network latency became a problem. And the solution was that was to basically deploy

across multiple regions. And we are hosted on AWS. So we wanted to be on all the AWS regions. We literally have people sending traffic from every region in AWS around the world. So it made sense for us to be there. So the challenge there was, of course, in the case for monetized APIs especially, is they monetize usually based on number of API calls or certain data being sent or anything else that they want to monetize on. But what happens if you have a data center far in the east and another data center far in the west, and a user making API and the same user making calls to your API from both of them? Say a user

or a consumer built a mobile application and that mobile application became popular and now people around the world are using it, you want to charge the developer of that mobile application according to their usage, but his users, his end users are all over the world. So the traffic is not always coming from the same direction or the same source. So the challenge of keeping the servers in sync became a bit of a problem to solve, architecturally speaking, as well as a cost center for us, because now we have to invest a lot, not only in engineering solution, but also maintaining that solution and scaling it up as the system grows. So Cassandra just became kind of the natural choice for that, because it was a database

that was designed from the ground up to solve that problem, solve that problem of concurrency, to solve that problem of clustering and multiple regional data center data sharing. So you can solve that problem with Postgres, you can solve that problem with MySQL or any other databases, but it's typically a bigger investment for you to go and try to solve that with, let's say, Postgres and deal with sharding and deal with distribution of data and deal with syncing of data. So we researched a lot of databases.

We experimented with a lot of them, and Cassandra just was one of the kind of easier choices. And we also had to consider a developer experience of somebody, especially for the Kong side of it, who will just want to be able to run Kong and get started in five seconds. What are they going to have to do? So we didn't want to choose something that was too complex either. And Cassandra became the obvious choice. Again, just as with the Lua and the kind of the unopinionated architecture that we did kind of placed both to the benefit and to kind of intimidating newcomers.

Somebody who's not familiar with Cassandra as a database choice might find it a little bit more intimidating to grab their head around. My example of that was go back to, it's kind of the same thing as when people were moving from subversion to Git. This idea of a decentralized system

is just so bizarre and out there for somebody who's always used to having the central point of truth. Same way as you would have an SVN versus Git, it's the same that you would do with SQL-based databases and relational databases and what Cassandra has to offer and decentralized databases have to offer.

So the same kind of effort that a lot of developers go through in crossing that bridge is probably the same experience they've had in switching from SVN to Git or from centralized version control to decentralized version control, as we all did over the years. So you have dependencies on Cassandra.

That does seem to make some sense. You have Nginx, of course. But as far as what this will run on, it sounds like any, you know, StarNex system. Yeah, pretty much. Anywhere that Nginx would run, basically. And, you know, to the point about Cassandra,

now that Kong is established and it's out there and people are using it, one of the most popular issues on the GitHub project is to add support for Postgres. So we are actually doing that, and that's going to be coming in the next couple of months to add support for Postgres

and other SQL relational databases. Obviously, with the caveats of, you've got to be worried about your own distribution and so on. But the reality is not everybody has to solve that same problem. So for many people, they're using Kong internally only. They don't even need to expose it to external users. They just want to use it between their own

internal systems. So a simple Postgres database would solve that problem for them just fine. Right. No, I think that's a pragmatic choice. I think you can kind of liken that to what them just fine. Right. No, I think that's a pragmatic choice. I think that you can kind of liken that to what we just talked about with Nginx, you know, adding JavaScript, scripting support. It's just to make a great tool available to a broader group of people.

You know, when I see Cassandra as a dependency, just the messaging and my knowledge of that database, and I think this is probably not a tool for me because Cassandra solves problems that I rarely have. Exactly. base and and i think this is probably not a tool for me because cassandra solves problems that i rarely have exactly um as as a contract developer working for small businesses and startups um and so that's just like an implicit message that goes out i'm like oh this is for people with big data you know quote unquote problems um and i think adding this postgres support is a pragmatic choice and that's that's pretty cool um tell me about the plugin architecture it's plugin oriented you guys you know provide a bunch of first-party plugins ones we discussed such as authentication and rate

limiting and such how do the plugins work and how do you write them yourself so the plugins are essentially uh in the simplest terms they're just events and part of the request lifecycle that operate custom code that you write or the ones that we package with the system. So we talked a lot about the authentication plugins, but there are many other plugins in there, including things like rate limiting, request size limiting, or transformations. They can modify the request and response, logging plugins in case you want to write logs to files. Essentially what they do is in the request lifecycle,

you have a number of events. To simplify that, you have pre-request received and then request sent and then response received and response sent. These are the four major events that you would probably want to listen to. There are more, like first header received from the upstream and so on. So you essentially subscribe to events in the request lifecycle,

and your plugin logic will trigger at that point of the event request lifecycle and do whatever the custom logic that you've written in the plugin to do. So in many cases, the authentication methods, these trigger as soon as the request has finished processing into the Kong layer, but before it was sent to the upstream server. So that's when you do the authentication. And then if everything is good and well, you just continue down the lifecycle and process other plugins logic, or just send it to the upstream, receive the response back. And then perhaps, and then at the end of the receiving of the response,

that's when you'd run the logging plugins, for example, because you want to log the entirety of the request lifecycle, not just part of it. So it really is event-based, and depending on the lifecycle of the request is where you can introduce logic into the flow. One of the best parts about open source is when you know some person you'd never met before comes along and makes your software better you know best of all if you're sleeping and you wake up you know and you have a pull request where oh man my project's better than it was when i before i went to sleep um seems like you guys have a lot of pull requests open on kong have you guys had

any awesome plugins that were created by third parties that you'd like to highlight as like, oh, this is something that either we didn't think of or we're glad some other third party came along and wrote this plugin? Yeah, we're actually... Like I said, we have the first party plugins that we created and then we have third party plugins for our

own products as well because we have more products than just Kong. We do offer Galileo, which is our API analytics service, and Gelato, which is our developer portal service. We have those also as plugins in the system. But like you said, we have a developer community that's actually quite active. From the day we launched, which was I think it's about eight months ago now, in the first three months, we just went on the hacker news

and everybody ended up posting about it everywhere. And within the first couple of months, the star count on our GitHub repo, whether you think that means anything or not, went up to like 2,000 stars. I think now it's at around 3,500 stars or something like that. And people started coming in and actually started reading about it and contributing to it.

And then initially they highlight all the, all the things we did wrong. So like, Oh, your documentation here is wrong. You miss mislabeled this thing, or you have an issue here. And that's where,

you know, initially the feedback from the community ends up being, but then slowly over time, we're seeing a lot of the things people are building on top of conk for their own use cases within their own corporations and businesses, of course. And I think in the next couple of months, we're going to be announcing a number of third-party

integrations and services that are being built on top of Kong. Obviously, the reason we're having this conversation is because the guys at MaxCDN are looking at it and they're building kind of plugins and services that benefit MaxCDN users and Kong users. We have RunScope building plugins. We have Datadog.

We have a number of these kind of tooling and service providers around the world that kind of fit the same target audience of API tooling and providers who are building all these products and plugins to Kong now. So I think in the next couple of months, you're going to see a lot of these third-party plugins start to surface. And I think it's going to be pretty exciting for us to see those go out there. Awesome. Yeah. It looks like you also have an Nginx plugin. Yeah, we have Nginx. Nginx Plus is a premium service from Nginx too. And it offers you monitoring access to Nginx. So that's also available on Kong. And I was going to say, one of the things people always end up rebuilding is a GUI interface for Kong.

Because Kong, like I said, it's only interfaces and API. So people are actually, there's like one, two, three, four, five, six front ends to Kong that people have built across all the different front end frameworks, whether it's Angular or Python or Node.js or anything else they started building with. Are you going to bring those in

and have some sort of like some front end deathmatch and then announce one is the canonical blessed mash ape front end or what's going to happen there we're actually working with all of them um we're seeing a lot of things people are building with kong that are quite innovative and interesting there's actually a company in belgium that's building kind of a multi-tenanted uh api directory on top of kong as well and they're open sourcing that there's these all these GUIs that people are building

and the front ends of people are building that we're just encouraging them to build. I don't think we're going to have a deathmatch, but we do every once in a while nudge them and say, hey, that other guy has implemented these new features and you haven't. Maybe you should take a look. That's the entrepreneur in you again,

bringing out the competition to make everybody better. A little bit of public shaming doesn't hurt anybody. And people are building integrations with it, and that's really exciting to see because it's things we haven't thought about. And that's why we want it to be open source, and that's why I love open source,

just to get that, like you said, you wake up in the morning and you see the surprise, and it's like, wow, this is cool. Yeah, let's talk briefly about the open sourcen to get that. Like you said, you wake up in the morning and you see the surprise and it's like, wow, this is cool. Yeah. Let's talk briefly about the open sourceness of this. You know, the difference between personal projects and business projects is an open source business project has to justify its existence. Obviously, if this was a proprietary thing, the existence could be, well, we'll sell this

to people and make money. What's the business-oriented decision from MashApe to open sources? You touched on it briefly, but if you could restate that and give, where does this fit into MashApe as a company? So like I said, MashApe as a company, we have a number of products and services.

We have the API Marketplace. We have an API Analytics product called Galileo. We have a developer portal product called Gelato and a few other products as well. Open source has been in our DNA from the start. We even have a product called UniREST, which is not really a product, but just a series of open source HTTP client libraries. They're actually quite popular. The Node.js one gets about a million downloads a month or something. And the PHP one gets about 30,000 downloads a day.

We enjoy building open source as part of being developers and engineering driven as a company. And we have a number of things. I can't even remember half the open source projects that we maintain. But as a product strategy, we obviously are not the only company in this space. We're not the only ones that offer API tools and services. There are many others.

The reality is, though, when you look at all these other providers and services out there, they are, even some of them do have some open source into them, but they're not fully entirely open source. What they do, they just want your paycheck so when you have a conversation with them about using their products and tools they basically want hundreds of thousands of dollars to millions of dollars based on your usage and based on how your api is or how big your company is they just want to bleed you for money and because of our individual teams kind of backgrounds coming from the open source world and coming from kind of bootstrapping and building things on your own and being entrepreneurial, most of us don't think of the software world as the way to make billions of

dollars out of companies of just, you know, bleeding them for money for buying your product or using your service. So in open source and Kong, we're basically saying, hey, look, these kind of tools are not the kind of tools that we should charge the community money for. These are not the kind of tools that people should be paying hundreds of thousands of dollars for. These are commodities. These are part of the necessities for building API products.

If you want to make money and monetize things, then monetize based on services. Monetize based on value add you're adding to people. The reality is all of our clients are developers too. And there's nothing stopping our developers and our clients of going on and building their own API management solution. They can. The question is, do they have the time and the energy to invest in building something like that for their own needs? And many people do. But the reality is their real focus of a development team is to solve problems of the product or solve problems of their own consumers

or their own clients. So for us, open sourcing the HTTP management and the API management layer just made sense because it is a commodity. It's not something that people should be, you know, charging enterprise level contracts with and paying hundreds of thousands of dollars for. So we just wanted to give it out for free. So you said the Kong Enterprise Edition. There's actually not a difference in what we call

the enterprise service on Kong versus what Kong is. It is the same products. It's open source. It's free. There's no strings attached. You can use it today in production or in development. We don't care. Have fun. Enjoy it. Let us know what problems you have and we'll help you with it. But what we do offer is the value add. So the value add that we think people want for open source products is more around the support and more around customization, more around professional services. So for a bigger company or a bigger team,

they might have a production system running on Kong, and many people do. They come to us and they say, look, we just want to have you in kind of our production level environment so that if something happens or if we need your help with something or there is a demand to change things on the fly, instead of managing the relationship and maintaining this product internally with our teams, we'll just have your team come and be part of maintaining the product and helping us answer questions. So it becomes a support relationship for people in a higher production kind of standards and requirements.

At the same time, there are a lot of people who may or may not need or want to invest into Lua or customization or they just may not have the time. They have other priorities to focus on. So if they really need to have something customized

or something developed for their own needs, that's where they engage us for the kind of professional services aspects so we can come in and help them with the integration or the customization of the product. And to us, that's providing value to our customers rather than putting a barrier in front of their adoption of saying,

no, no, no, you need to pay for this before you use it. I think that's a good place for a break. On the other side, we will talk about getting started with Kong. I also want to ask about future roadmaps and where Kong could be going in the future. Stay tuned. We will talk about that on the other side of the break. I have yet to meet a single person who doesn't love DigitalOcean. If you've tried DigitalOcean, you know how awesome it is. And here at the Changelog, everything we have runs on blazing fast SSD cloud servers from DigitalOcean. And I want you to use the code CHANGELOG when you sign up today to get a free month, run a server with one gig of ram and

30 gigs of ssd drive space totally for free on digital ocean use the code changelog again that code is changelog use that when you sign up for a new account head to digitalocean.com to sign up and tell them the changel load sent you. All right, we're back and we're ready to wrap up this conversation about Kong. But we do need to know how the heck do you get started with it

if it's something that is interesting to you? So you've sold me. I'm interested in Kong. I want to try it out. What do I do? What are my first steps? So first step is you go to getkong.org

or simply go to mashave.com and find the link to Kong from there. The website will provide you linkage to the GitHub repo and everything else about the documentation. But just if you already know what you want to do beyond learning about what Kong does, we actually offer a number of distribution packages for a number of Linux distros.

So depending on what Linux distribution your server runs on, you can actually download it for Debian, CentOS, Red Hat, so on. We even offer a cloud formation template for AWS users. We even offer an AMI for AWS users as well if they don't want to build servers from scratch. And we even offer Dockerized versions versions of kong and cassandra as well that you can just simply run with two command lines and that's actually what i use most of the time for my development purposes i just run the dockerized version locally and just go from

there um we're also working and then you if you want to develop for kong and run you know build your own plugins and run it locally then we actually have full instructions of how to run the source and run it within Vagrant as well for Windows users because Nginx doesn't run natively on Windows. That's it, man. It's as easy as that. It's super easy.

That's what we like to hear. Looks like you don't yet support DigitalOcean, Heroku, Microsoft Azure, but these things are coming soon, FreeBSD. We do support them. Obviously, DigitalOcean runs on Debian 2, and Azure as well gives you a Debian-like system that you can set up with Linux and everything. So we do support them.

But what we want to do is just automate that process and having kind of the one-click launch scenario that we've done for AWS. So if you look at the CloudFormation example, you go to the CloudFormation page on the installation page and you literally click a button and it takes you to a form on AWS's side. You fill it up and then your servers are launched. So that's what we're actually aiming to do

with the Google Cloud Platform and Azure and DigitalOcean as well. I see. So you have a little flag there, banner, that says soon on those. That's because you haven't fully automated the process yet. Correct. But typically speaking, almost all the cloud providers have either Debian or CentOS and we do have those. So you're good to go. Let's talk about the status of Kong. Production ready, I assume. API finished. Is it still under heavy development? Do you have multiple rounds? What's your future plans? Where it's at right now? So it is production ready. We are using it ourselves

in the marketplace and many of our customers, including governments and financial institutions and healthcare providers are using it in production. So, um, and obviously we have an ongoing relationship with these customers to make sure we get their feedback and learn from them and incorporate all these learnings into the product as well. Just because it's an open source product, it's not one of those side project things. We actually have a full team dedicated and working on Kong, myself included. A lot of our engineers are working on it day and night. So it is really, even though it's an open source project, it's also a core product that we offer. So people are working on it all the time and adding new functionality and features. In terms of roadmap and the next

releases and what we're aiming to do, right now, Kong nodes are kind of stateless. So they rely heavily on Cassandra to kind of share the state and share the information across them, specifically for information about the APIs and the configuration. In the next release, we're adding cluster awareness for the Kong nodes. So each node in the Kong cluster would be aware of all the other nodes. And when events happen in the system, like an invalidation of the cache event, the nodes can talk to each other and invalidate each other's caches or reset each other's caches, which makes the system even more dynamic and introduces more kind of functionality for building plugins and

features across it. Beyond that, like I said earlier, we're introducing Postgres as well as a database choice for developers and people who want to run Postgres in production. And we actually try to publish our roadmap in our wiki on the GitHub repo. But typically, it's always changing and evolving because the more people who discover Kong and the more people who come and look at the Kong project, they end up contributing back in issues and questions and feedback. So we have kind of two main channels for talking to our community, which is the GitHub issues, of course. And then we have a Gitter channel for live chat with our community. And really, the community is the one that drives our roadmap we don't actually go

behind closed doors and say okay here's what we think we're going to do and what we think the community wants we actually just look for the community for guidance and feedback of what they want what they need and of course depending on how loud people are to certain issues and certain requests uh then that's just takes higher priority than others So if you look at the Postgres issue in our GitHub repo, I think there's something around a couple hundred plus ones on the issue because people just keep on going, it's like, yep, plus one, I want this. And so that obviously became a higher priority

because clearly there's a lot of demand for it. And that's how we actually drive our roadmap. We look at people and what they're building and what they want to build, what's lacking, what's limited you know, limited, what's, what needs to be expanded on. And we prioritize accordingly and just do it by the community's feedback. Well, let's, let's cut straight to the chase and talk about when is GitHub going to implement, uh, up voting and down voting on their issues. I mean, come on, the plus ones are ridiculous. There is a, there's a GitHub

plugin called Zen hub, which is kind of gives you the, the Trello view of GitHub issues. I mean, come on, the plus ones are ridiculous. There's a GitHub plugin called ZenHub which kind of gives you the Trello view of GitHub issues and actually has a dedicated plus one button that kind of superimposes on GitHub issues so you can just do that instead of people coming in and manually typing in plus

one into the issues. So I find that always funny. ZenHub, huh? It's a cool tool to use. I'd highly recommend it. Yeah, so tell GitHub if you're listening, hire the Zen Hub guy. He'll implement your plus one feature for you. That's right. Very cool.

So we're about to move on to our closing questions, but any closing thoughts for you on Kong or MashApe as we transition to the closing questions? Anything else you want to say? The one thing I would say is, you know, kind of building on that community relationship

is that, you know, Kong is an open source product and obviously we're championing it as the company behind it. But we also want people to be more engaged and be more involved so that, you know, we're not just the only ones building it. We already have a number of contributors, a number of people in the community who are actively building and introducing things to the product.

But we want to hear from you. We want to hear from even the people who don't like it, even the people who don't want to use it. I'd love to have that conversation. I'd love to see what is the feedback that you saw on the product or the information that doesn't really fit your needs? I want to learn from the community as much as I want to share the knowledge and learning

that we have as an API company to the community as well. So I would encourage anybody to jump in and give us feedback, talk to us on the chat, open issues for anything that you think is lacking, or just email us and let's chat or go for coffee and talk about APIs and technologies in general, because we're all API nerds at MassShape and we love talking about this stuff all the time. All righty. Well, closing question time and the compulsory question that we just love to ask

everybody is who is your programming hero and why? All right. I don't have to think too much about that because i i always quote this person all the time so my programming hero is grace hopper who if you're not familiar with who that is it's uh it was she was back in the and the uh u.s navy uh one of the early programmers back there and she's usually credited for creating or inventing the word debugging and kind of reference to what we do today in debugging programs and applications although there's also the other story of how the encryption back in the days of earlier the war encryption there was an actual bug in a system um that's that's where the word bug came came from but the word debugging uh kind of came from grace hopper and that's usually that's where the word bug came from, but the word debugging, uh, kind of

came from Grace Hopper and that's usually what she's credited for. But what I love her the most for, and the more I learn about this person, the more amazing she, she becomes in my mind, um, is the one quote that I actually just found by Habstance. And then I got to know more about Grace Hopper is, um is the quote about management and leadership. And the famous quote basically says, you manage things, you lead people. And that was kind of in context of how in the software development culture that we have today, we have developer managers, we have product managers, we have project managers. And, you know, in a broad sense, those kind of people are generally tasked

with the purpose of managing the developers or managing the technologists on their teams. But to big failure and to lack of love from development team, they just don't like that relationship and ends up being a poisonous relationship in a lot of ways, not always. But generally speaking,

that's kind of the core part of it is because the idea of managing things or being responsible as a person to manage things doesn't translate well to human beings. But if you want to be a leader, then that's a different conversation altogether. And the reason that kind of rang true to me, because in my career, I kind of evolved from, you know, different roles and responsibilities along the way. And in many places, you know, my role was always been the development manager or the team lead, or, you know, the manager kind of suffix always made its way through to the title. And although I don't actually think of myself that way, I used to think that used to be a skill that I had because the business owner or my bosses would come to me and say, oh, we seem to have a good business lingo and understanding

of the business. And you can talk to us like normal and we can understand you. But at the same time, you go and talk this geeky language with the developers and they understand you. So, you know, you seem to make a good manager. And I used to think that was a skill that I had. I used to think that was a positive thing. But of course, over time, I realized that's actually not because it's not so much that I'm able to kind of bridge that gap between business language and technology and kind of the motivations of developers versus the goals of business. But it was just the lack of the business people or people who are the business owners to understand the motivations and the kind of culture of technologists and hackers and developers. So that's how I came across Grace Hopper. And I keep reading more about her and what she did.

And that quote just rings true to me all the time. And I use it everywhere I go. It's just, you manage things. You don't manage people. You lead people. So that's kind of my mantra. I want to be a leader to my team. I don't want to be a manager.

So my title right now is head of engineering, but it really means nothing. I don't want to be a manager. So my title right now is head of engineering, but it really means nothing. I don't care about the title. I care more about my role to the team. And my role is to lead the team and help the team accomplish things. Not so much look at hours and input and output and production of the team members. Now that definitely rings true to me. And I think, you know, I've been in the position to both manage and to lead in certain aspects. And I found that I'm very bad at managing people. I don't enjoy managing people because it does feel very much like their things. And it seems like it's demeaning.

But leading, on the other hand, that's appealing. That's something that's challenging. That's something that's way more attractive. Also reminds me of, you know, one of my pet peeves is what's up with human resources? And like the idea of like, do you have any resources for this project? It's like, these are humans we're talking about here.

I realize we need to formalize on some terms for easy communications, but come on, can we just call them people? Well, to me, it's the whole lack of understanding of what motivates us as human beings but even more as technologists as hackers as developers like we i mean i'm sure some people are in it for the money but i highly doubt these people will make it far in this in a career in software technology the majority of us and you know i I'm going to make a statement and say, I think all real

developers and programmers are in this industry because they enjoy the aspect of creating and innovating and changing things and challenging the status quo by going in and making a program or an application or a product that solves people's problems and changes the world around you. That's really what we are doing it for. If we were doing it for the money, then we'd probably go to law school or study medicine and just make a bigger paycheck there. But that's not what motivates us. What motivates us is that opportunity to change the world around us and be innovative in what we're doing. And technology gives us that opportunity. But for a lot of businesses, a lot of people on teams, they don't necessarily touch on that so

what you see is that's where like your post comment about human resources they talk about you know let's incentivize developers by giving them pay raises or vacations or you know offsites and travel kind of budget yeah that's kind of nice but that's not really how you make a development team happy that's not how you lead the development team and champion the team itself and what they're doing into building better products and better services. Yeah, tease up my next question pretty well there, which is if you weren't doing what you are doing, which is being a leader of development at MashApe and whatnot,

what would you be doing? I can't even think about it because I wouldn't be happy in my life. I wouldn't exist. Like we were talking before we started recording, when I'm done work, I'm still sitting at my desk and I'm still writing code because that's what I enjoy doing. And my wife often doesn't even know the difference between me being in work mode and me being in just hacking and doing open source project work, because it is the same to me. And I love this

industry because it actually gives me that opportunity to do the things I enjoy doing the most. Yeah. I think that's funny because, you know, we have a video series called Beyond Code that is a very brief interviews that we shoot at conference after parties. And we ask the exact same five questions to everybody. A couple of them are kind of like the closing questions, like who's your programming heroes. One that we ask another one that we ask, and we ask it a little more pointedly than we ask this question.

It's pretty close to the same question, which is we simply say, is there something else that you'd rather be doing? And I've been shocked at how many people say no to that. Almost everybody says no, I love what I'm doing, there's nothing else that I'd rather be. And people that don't say no, they usually interpret it locally and they're like, you mean besides talking to you guys on camera? You know, they make that joke. But anybody who's answers that sincerely about career, they pretty much all say no, which is, I think, a testament to how enjoyable the work that we do is.

I don't find that surprising at all. Yeah, I think it was surprising at first, but now it totally makes it obvious in retrospect. I think one of the things, if I'm forced not to do what I'm doing today, if for some reason, let's say the developer community came around and decided that I'm not allowed to be in technology anymore, which would be very, very sad indeed.

The only other thing I can imagine myself doing is just spend as much time with dogs and animals as I can because I have a little dog and I love her. Her name is Ruby. Not an association to the programming language. I'm not much of a Ruby fan. But I just got... Because I never got a dog growing up.

I never had that pet relationship growing up. So I only got a dog as an adult and I love it. And it just feels like a little kid again. So if there was one thing I would do other than this, it would just be spending more time with dogs and animals. Maybe a dog walker or just a dog there you go take caretaker very cool op-ed well thanks so much for joining us this has been a blast i think kong looks really cool and i hope it has a lot of success in the future uh thanks for taking your time and joining us we also want to thank everybody who helps makes this show possible our listeners uh our

changelog members we appreciate you a lot as well as our helps make this show possible. Our listeners, our changelog members, we appreciate you a lot, as well as our awesome sponsors. This show could not be possible without these four sponsors. That's CodeShip, Braintree, Harvest, and DigitalOcean. They support us. We all should support them. Thanks so much, you guys. And until next week, let's say goodbye.

Goodbye. watch you guys and until next week let's say goodbye goodbye you