I'm Ahmad Dasri and you're listening to the Change Log. Today I'm joined by Akhbet Dasri, who is the head of engineering at Matchape, and an advocate of all things, Open Source, Akhnet, 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 a little bit nebulous to me, so I think this is 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, Akhnet, but at first I'd like to just get to know you a little bit and hear about your history, because you have what I think is somewhat of a fascinating history. What do you think?
Where should we start? Sure, we can go back as far as you want. So, let's start where you're at right now. So you live in Canada.
That's right, now live in Toronto. Okay, and as we're talking and sitting this call up, you were in London for a little while. That was just a vacation, our work related. I was working late.
I actually travel a lot for conferences, events, and a spot of the Matchape 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 the company itself as we go. So, if I'm not in Toronto, I'm usually on the plane heading somewhere or on the way back.
But you're not in Toronto native. You were originally from Syria. So maybe let's go all the way back to your childhood. You had what I think was an interesting childhood, especially with Access to PlayStation Magazine, and other people didn't have.
Give us some of your back story of how you came from Syria to Canada. Sure, so I was actually born in Damascus, Syria. Back in the 80s, I was born in 85. Syria was still in the pretty crazy state of this now, but also pretty opening up to the world.
So growing up in Syria was normal childhood, normal life. We never really had any problems or issues. This whole concept of terrorism and terror in general and fighting at war was really foreign to us. And for me, as a child growing up, I come from a Sunni Muslim background, my family is Sunni.
I went to a Shi'at school, and most of my friends were actually Christians. So 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 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 access the Internet is through long distance dial-up to the neighboring country, which is Lebanon, and which was highly legal as well. So I used to actually sit in my dad's office and long distance Lebanon just to get access to the Internet 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, Siberia was my internet access provider, my very first one, which was based on Lebanon, and this was highly illegal. So the government had the secret services and the internal police is what they call what we call them. And they would go around and make sure they listen in all the phone communications in and out of the country, because it's the leadership and the 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 how the sciences and the rest of the world actually lives? So they would go around and try to shut these down. I remember being a 12-year-old sitting in my dad's office late at night, browsing the Internet, looking up at Yahoo's office, and looking at the Internet.
Looking up Yahoo's homepage, trying to learn things about technology and computers and the locking on the door, which 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? They're actually coming after you.
Oh yeah. Wow. But the reality is they're not coming after you. They're coming after you for bribery so that you can bribe them and then they go back to their friends and families.
Oh, I see. It's illegal, but also the enforcement of it is somewhat lawless. So they're not going to do it by the books. Exactly.
It was completely corrupted, which is why a lot of people got away with it because you brought your way through it and you're fine. A few years later, we started getting Internet service from the government to provide a government and a cell phone service started becoming the norm. And then for me, that just evolved into actually getting into the entrepreneurial mindset of actually using this thing called the Internet to my benefit, 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 play session 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. I used to access it online. They had 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 traveled or as we go out to our family's secretes, we would usually go to neighboring countries to Lebanon who had less of a global bycaught and restrictions on trade as they were. 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. Not Coca-Cola.
Go on, man. No, no, it's all Pepsi all the way. Are you still Pepsi to this day? Are you still on the dark side?
Okay. So you're getting these PlayStation Magazine and there are cheats in the back of them. Is that right? I remember PSN, but I wasn't a reader.
Yeah, I was so, I mean, it was also all fully in English. I was still kind of learning English at the time. So 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, 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 would be talking about the next Tomb Raider version that's coming down in a couple of months, but being probably one seed 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 it was a white concentration. 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 didn'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. And then you could actually sell these codes to your friends. Is that right? That's right.
I would sell them the cheat codes and or treat them for treats and candies and toys and things. What's the market value of a single cheat code back in the day, do you remember? Well, I went with the lowest paper bill, which was the five Syrian pounds paper bill for the conversion rate at the time, a single Syrian pound, sorry, a single US dollars equated 50 Syrian pounds. So it was pretty cheap.
But for the economy of the country, that was not very cheap, especially for kids who don't actually have money. Early teens, type kids, like 13 year olds, that kind of age group that you were doing. Yeah, 12 or 13 year old and younger. Obviously, the older kids wouldn't pay you any attention.
So, but the younger kids are more gullible, so sell more to those. So that man's fighting a trend here. We recently had Mitchell Hashimoto back on the show to talk about Otto. Let's see what episode that was, 180.
And he got into the game kind of selling cheats as well through certain agree. But he was basically writing bots for Neopets. Nice. And that was kind of what his entrance into, maybe not as entrance into software, but something that he remembers as launching off point.
You start off with these PlayStation magazines and other such things and talk about knowledge as power and all these literally money in this case. That's right. How did you, and you're leveraging that, how did it turn into software or coding or where did you get past like video game consoles and into software? So, the cheating industry itself evolved at the time or like the tooling around it evolved.
Everybody was, I think, called the shark that you actually plug into the back of your PlayStation to get 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 disks 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 the, 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, you know, along the years, kind of transition from, you know, the video game stuff to, especially as the countries are getting cellular service to mobile phones and mobile devices. And I remember like one of my very first devices was a smartphone back then, it was called the KS7650, which was this Simeon 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 build software for that. And I started getting to the business of finding applications online for this operating system and installing it for people for money and just blowing their minds off of it because they never imagined their phone could have games and other applications and counters 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 Simeon S60 and then just also selling that, of course.
And they all became part of the same mindset of find the technology, leverage the technology to your needs and then win and profit. Sounds like, sounds like you have way more entrepreneurial spirit than I do. I probably would have just taken the PlayStation sheets and win and cheated 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, obviously had me and my brother and life goes on. And then I remember just before my 20th birthday is when they actually got leathered from the Canadian Embassy saying, Oh yeah, I remember that thing you applied for 19 years ago? Yeah, you're here. You're 18 years.
Yeah. Wow. They finally got the green light to actually come to Canada. And because of the time they applied before we were even born, my brother and I didn't have to reapply on her own because otherwise we have, at least for me, I would have to apply again as an adult because I was over 18.
So, yeah, that was basically my 20th birthday in Damascus. That was the last birthday I ever had in Damascus. And a couple months later, we were on a plane and we came together 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 my dad's cousin, second removed.
But I mean, in your immediate family, like your parents hadn't come and visited or had they? No, it was fresh, literally fresh off the boat in 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 the, in today's world and 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.
We're 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 travels around the world and he's seen a lot of places around the world. He never came to Canada, but he lived a while in Paris, he lived a while in London and he traveled all over North Africa.
So, you know, I got a little bit of a foundation to start on. But obviously there's a bit of a culture shock that you get as much as you think you're prepared. There's a little bit of cultural shock that when you, 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 had, we had buildings in Damascus. We have tall buildings in Damascus, but not really to the extent of the skyscrapers that we have in Toronto today. And of course, you know, 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 these skyscrapers.
So huge and massive. So that's one part of it, obviously, is like the, the scenery changes around you. And then there's the other part that it was, you know, mid-July and I was walking around with a heavy, thick winter coat because I was freezing my ass off. I think having grown up in the Middle Eastern kind of temperatures and weather coming to Canada to go out to adjust in the cold.
Yeah, we have a friend who lives pretty much on the equator over in Kenya. He visits here pretty regularly and he cannot adjust to the cold at all on, you know, on Nebraska. So more temper 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 tell you about it. So that brings you to Toronto and no doubt you've had a bit of a career since then. You're now the head of engineering at MASHAPE.
So briefly, and then we're going to get into con right after the commercial break. But briefly, can you just tell us like career-wise how you went from, okay, I'm moving to Toronto, H20, and now I'm head of engineering at MASHAPE. So the obvious push for my parents was for me to go into university and continue my education. I had done a year of computer science in Syria.
But my, 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 I continued that in Canada. And slowly, I went from just hacking old PHP projects and things like Odesc 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 make my way through and growing and learning new technologies and new systems and new 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 Mashi, building APIs and tools for the rest of the development community. Very cool. 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, roll 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 developers out there, the Braintree B.0 SDK makes it easy to offer multiple payment types, start accepting PayPal, Apple Pay, Bitcoin, Venmo, traditional credit cards and whatever is next, all with a single integration. Enjoy simple secure payments that you integrate in minutes and developers, they've got you, don't worry about taking days to integrate your payments, but Braintree is done in minutes. And if you don't have time, you have the McCall and the Hanyone integration for you and walk you through it.
Braintree supports Android, iOS and JavaScript clients. They have SDKs and several 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 braintreefamous.com.com. . Alright, we are back with Ahmed Nasseri and we are ready to talk about Kong. I'll be remiss not to give a shout out to Justin Dorfman, who's a changelog member who helped us line up his show.
He's very interested in Kong as the developer evangelist at Mac CDN. Sounds like lots of people are interested in Kong. Can you give us the elevator pitch? What's it good for?
What's it to 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 unappinionated 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 coming from soap, people coming from rest, people coming from different kind of mindsets 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 unappinionated and wanted to keep it abstract and more associated with the HTTP layer, which is the spec of 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 have 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.
And it's not necessarily a negative state of chaos. It's just a entropy state where things are just evolving and happening around us. So Matt Shape actually started out as, well, our 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 just 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 in and discover and select APIs that fit their needs for building their applications. A spot 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 expected to consume APIs. So we can't be opinionated.
We couldn't be more subscribed to a single way of building APIs or something standard or approach. So I'll talk about SOA versus microservices versus REST versus SOA versus X and Y and Z, where we just say it thumbs up to all that, because we had to. Is there a real difference between SOA and microservices? Is there a distinguishable thing or just terms?
You're touching on the war territory here. That's here. I don't have an opinion. So you can just state yours and move right along.
It will be a war. My opinion is a bit deeper into that. I think a lot of people in the industry have a 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 a single focus and testable and blah, blah, blah.
Yeah, but that's more about being modular. You can do that as part of code and libraries and the way you organize your project. Same thing for components. Components are just a bunch of modules, but together to server purpose.
So you can talk about a module being a login module, or you can talk about a module being a user named 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, 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 a few here to listen to 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 law cases. And the microservices focus on, no, no, no, let's just do things as the web has evolved over HTTP. Let's do things as well, where it should be between our products and tools and services within it. So I think, you know, I'm truly speaking, and again, because we had to be the marketplace for so long, we were fine with all that.
You know, obviously people have personal opinions, but if you're building a product that's serving a problem for users, they don't really care about are you restful or are you so poor, are you microservices or so on, point as a product. And that's kind of our message that we carry to people. When we talk about an API and APIs, a product, it's not just a data output, it's not just an 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 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 and so on. 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 someone, doesn't really matter.
I think we run into just name spacing issues when it comes to terms like modules and components. And we move fluidly up and down the stack in our conversations with each other. Sometimes things become conflated because perhaps you're talking about modules at a network layer, or I'm talking about them at an application layer, even inside of a code, a library or something. It becomes weak and means words and I think it's still important to talk about these things and try to come to one understanding on certain terms.
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 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 a picture?
Yeah, that's precisely it. And Kong actually evolved in the marketplace itself because as virtually we're being able to offer monetization services for API providers through the marketplace, that means we had to manage their API calls as well, meaning proxying. 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 pinnied 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 kinds 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 the people who were worried more about the latency and they were perhaps using regions on AWS, they're 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 makeup and the DNA of Kong. So like you said, it's this idea that when you're focusing on building an e-commerce product or 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 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 have some protection to your API layer. So the idea is in many cases to reinvent the wheel every single time and either doing that or luckily in today's world, we have like reason tools that maintain body 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 I think in a scenario where there's a company that has, don't go too far, talk about Netflix, they're one of the greatest examples of massive distributions in an API management tooling that they've built. They have multiple data centers across the world. They have multiple clients, multiple applications, whether it's 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 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 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 something you're faced with this massive interconnected web of dependencies and repeatable things that you're doing over and over and over again. Obviously, the doc used examples that rank true for a lot of people as authentication is one of the simplest ones. You have multiple systems, multiple APIs, they each have them as an indication.
It's the same authentication mechanism. You're doing all of them both, or perhaps you're doing JSON tokens or something similar. But it's the same thing. Why does it have to do it 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 in how to maintain the session and 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 engine X as their HTTP server or their proxy server.
And that's also why we chose engine X as the core for con. So con actually runs on top of engine X. What it gives you is the ability to configure engine X servers and configure the proxy mechanisms of engine X dynamically through a RESTful API itself. So in the olden days, you can actually just set up engine X and configure it to do everything you want, including customization of things like authentication beyond just the basic authentication.
You can use Lua as a scripting language with open REST on engine X to customize it. But you'd have to do it in configuration files. And you have to deploy these configuration files across the 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 tools 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 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 con, you literally have one thing to deal with, which is the API. You actually make a call to the con admin API itself and tell con to create a new endpoint.
You tell con to add authentication, you tell con to add logging and so on. And you do that to RESTful API calls, which we're all familiar with. We can use an API call in the command line using a curl. And these things are automatically synced up across all the clusters without the need for you to redeploy or do it again in the cluster.
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 on your diagrams, I thought, okay, con is kind of like network address to 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 have, 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 queue API so you can see what's in your queue and maybe those are separate. Would I have two cons or I have a single con with multiple endpoints, one representing each of those two single, single con multiple endpoints?
So is Nat kind of a good analogy to think of it? As I know you said proxy, which makes a lot of sense too, but is a single entity representing multiples? Yeah, I mean, that's a good analogy, of course. So 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 you always have these edge cases where, yeah, these three things are 99% the same, but that 1% super important. 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 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 thousands of public APIs and hundreds of thousands of private APIs that are not published as one of the public marketplace. We process, I think the last numbers we're looking at, I think, somewhere around 10 billion calls per day, and a lot of these APIs are even heavy APIs.
So for example, Imager uses the API marketplace for their paid API. So if you ever use the Imager paid API that goes through MASH shapes infrastructure, meaning all these people 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 column. Or four.
So, and that's to be completely fair to NGINX, that's really mostly NGINX's efficiency. Not really, you know, nothing. There's no special sauce that we're adding in the column that's making NGINX more efficient. This is really NGINX proxying being super efficient and super lightweight.
So the layer 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, two APIs, two different endpoints or off streams, and you want to make an authentication for one but not the other.
That's the whole point of the plugin. So you can enable them per API. And then you can even make it more granular so you can enable and disable things for a consumer. So say we have a specific consumer in the system, and a 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 you could be an application or could be a system or another server that's trying to access your APIs. It's just consuming your APIs. So you can set up rules and enable disabled plugin configuration for each of these consumers. So as an example, and I used this all the time when we're doing our webinars, you know, a typical use case is to have Raythimiting and an API.
So you would want to enable Raythimiting on your API. So you have API A that has Raythimiting and API B that has Raythimiting that's more appropriate to 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 Raythimiting specifically that consumer to introduce even more harsh rules on the Raythimit for a minute in pretty hour.
So you can actually become very granular in the way you design your API interaction in your logic. And con 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 back-end, but to design the experience around your APIs as well. So one of the things we offer 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 think of as versioning. So, you know, as you do 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 can actually bridge that gap.
You can make it so that if somebody's making calls with the wrong object name or wrong request bodies, you can actually change those up before they hit your upstream. So you're always in a green life cycle on your application in the upstream and your actual application stack. But you can expose different things on the API Proxilator that can still benefit people who are still in the transition period of coming up to your most recent 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 Proxilator.
That sounds like a pretty big win. So what about something a little more complex than authentication? 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 con layer, or does that have to be application specific? It depends really on the kind of application you're trying to serve behind con. So we have clients and customers and users of con that fit both scenarios, which is going back to the consumer thing that I was talking about. That's why we made it the donab-strack thing.
So one of the features of the consumer entities in con 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 G7 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, multiple credentials for G7 tokens. So the benefit of that is if you think of scenarios where this is one of the things that I was helping one of our clients with, if you think of scenario where you have a mobile as an organization, a mobile as a product, if you think of your product as mobile and then Android as a platform and iOS as a platform, it's the same product.
And you would not 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 really up to you of how you want to control that. The other aspect of this becomes if you have a partner, like you're a company A or Acme and you want to give access to another company, they have 15 developers.
Are you going to 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 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.
As we all know, every software development design decision has trade-offs. Have you found any drawbacks to the consumer idea and just this very generic system in general? Yeah, in fact, it sometimes, obviously, once people get it, once people get flexible, 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 the competitors have been doing.
In terms of saying, no, this is the better way of doing things, which is our way. Typically, what you see in some of the products out there, which is the only one that's open source and free and fully supported by a company, what's all that's backing behind it, what you see is these companies offer you products that, you know, those are similar things as Condes, but they're model-thick applications, they're very opinionated, they're very heavy on resource usage, and they want you to basically go back and 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, when it 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 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 in fact, that's free. Obviously, that's the starting point for a lot of people. And then we get into this conversation about consumer's objects and Kong being underpinning it, 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-usey, 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 shut 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 per year 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 breadth. It's also the incentive for a lot of people 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 got Lua in the mix.
You got Cassandra in the mix. Also talk about the Enterprise Edition and kind of the business side of this from Magic'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 that go in the go with you.
Snap those receipts and store them in the Harvest app. You can also connect favorite tools like Slack and use chat commands to start and stock your timers. Head to githubist.com and search for free trial. And once that trial is over, use our code, change the level to save 50% off your first month.
All right, we are back talking about Kong. And I want to talk 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 doctors of Lua as the scripting language. For those who are not familiar with Lua, Lua is fast and powerful, and lightweight, embeddable scripting language and meant to be embedded within other applications.
For example, Adobe actually uses it a lot in their products and actually made it into a lot of embedded systems and embedded applications as a scripting layer on top of the application itself. So I already fixed that model of Nginx. It's an HTTP server. It's configuration based.
It doesn't really have that dynamic aspect or dynamic language aspect to it. So, I think that the first entity was one of the first application servers that ran on top of Nginx and using Lua for us was entirely Lua. So it just introduces the bindings to the internal Nginx objects and systems. So essentially Kong has 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 a little bit too level than what I needed. And I didn't necessarily need the performance at the time, but I thought this is very interesting. I don't know if anybody is going to build anything interesting on top of it. So I was going to find out here it is still actively developed, I assume, and here it is sitting inside of Kong.
One of the core OpenResty contributors is 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 red 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. And recently, some people will 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.
It's some consternation. I don't know if it's really a trend of, hey, let's JavaScript all the things. 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 more.
But the early feedback in the community doing the 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. Now, 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 make more improvements on it. So if Nginx and JavaScript becomes more of the standard and better performance one, that is, which is the most important thing for us. Then, of course, you'll see JavaScript make its way into calling as well. So at the plugin layer?
Yeah. Or as I actually cut over to JavaScript for codes. I think more likely at the plugin layer because with OpenRasty, we've 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.
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. That being said, I've looked at Lua when I was checking out OpenRasty and stuff, and it seems like it's a really nice little language. It doesn't seem like they're hurdle to learn and you'd start it 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, it's really just a syntax. At the end of the day, it's kind of true to all scripting languages and high-level languages.
If you're familiar with the high-level language, then it's not hard to jump to another high-level language. If you're familiar with the 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's 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, 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. As I mentioned, X, 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 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 makes sense for us to be there. So, the challenge there was, of course, in the case for monetized APIs especially, is that 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, a foreign to ease, 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, that mobile application became popular, and now people are on 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 these 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 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 an database that was designed for the ground up to solve that problem, solve that problem of concurrency, to solve that problem of clustering in multiple regional data center data sharing. So, you can solve that problem with both of us, 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 concs of it, who will just want to be able to run a con 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 unappinated architecture that we did, kind of placed both the benefit and to kind of intimidating newcomers.
Somebody who's not familiar with the San Andreas database choice might find it a little bit more intimidating to grab their head around. My example of that was to go back to it's kind of the same thing as when people were moving from subversion to get 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 is 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 and crossing that bridge is probably the same experience they've had in switching from SVN to Git or decentralized version control to decentralized version control as we all did over the years.
So, you have the PNX Exoc Cassandra, that does seem to make some sense. You have Nginx of course, but as far as what this will run on, some like any, you know, StarNix system? So, I think anywhere that Nginx would run, basically. And to the point of Cassandra, now Con is established and it's out there and people are using it.
One of the most popular issue 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 caveat of you get a pure idea about your own distribution and so on, but there is not everybody has to solve that same problem. So, many people are using Con 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 we just talked about with Nginx. Adding JavaScript and support, it's just to make a great tool available to a broader group of people.
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. And so, that's just like an implicit message that goes out. Like, oh, this is for people with big data.
Quote unquote problems. And I think adding a Postgres support is a pragmatic choice and that's pretty cool. Tell me about the plugin architecture. It's plugin oriented.
You guys provide a bunch of first party plugins once we discussed such as authentication and rate limiting such. How do the plugins work and how do you write them yourself? So, the plugins are essentially in a simple 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 about a lot about the authentication plugins, but there are many other plugins in there. It's really things like rate limiting, request size limiting or transformations. They can modify their request response, logging plugins in case you want to write logs to files. Essentially what they do is in their request lifecycle, you have a number of events to simplify that.
You have pre-request received and then a 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 their request lifecycle and your plugin logic will trigger at that point of the event.
So, at that point of the events like Quest 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 conga layer, but before it was sent to the upstream server. So, that's when you do the authentication. And 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 at the end of the receiving of the response, that's when you run the logging plugins, for example, because you want to log the entirety of the request lifecycle and just part of it.
So, it really is event based and depending on the left cycle of the request is where you can introduce logic into the flow. One of the best parts about open source is when some person you've never met before comes along and makes your software better. Best of all, if you're sleeping and you wake up and you have a pull request where, oh man, my project's better than it was when I went to sleep. Seems like you guys have a lot of pull requests open on conga.
Have you guys had any awesome plugins that were created by third parties that you like to highlight? Is this something that we didn't think of or were glad some other third party came along and wrote this plugin? Yeah, we're actually, so 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 conga. We do offer Galileo, which is our AP Analytics service and gelato, which is our developer portal service.
We have those also as plugins in the system. But like I said, we have developer at developer committee 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 hacker news and then began posting about it everywhere. And within the first couple months, we like the star count and I'll get how people, whether you think that means anything or not, like 2000 stars, I think that will sit around 3500 stars or something like that.
And people start coming in and actually started reading about it and contributing to it. And then initially they highlight all the things we did wrong. So like, oh, your documentation here is wrong. You mislabel this thing or you have an issue here.
And that's where initially the feedback from the comedians are being. But in slowly over time, we're seeing a lot of the things people are building on top of conga for their own use cases within their own corporations and businesses, of course. And I think in the next couple months, we're going to be announcing a number of third party integrations and services that are being built into conga. Obviously, the reason we're having these conversations is because the guys at max CDN are looking at it and they're building plug-ins and services that benefits max CDN users and conga users.
We have Rust code building plugins. We have data dog. 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 conga. So I think in the next couple months, you're going to see a lot of these third party plug-ins 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 engine X plugin. Yeah, we have engine X plus is the premium service from engine X2 and offers you monitoring access to engine X, so that's also available in con.
And I was going to say one of the things people always end up rebuilding is a GUI interface for con, because con, like I said, it's only interfaces in API. So people are actually, there's like one, two, three, four, five, six front ends to con. Nice. So people have built across all different front end frameworks with its Angular Python or Node.js or anything else they started building with.
You're going to bring those in and have some sort of like some front end death match and announce one is the canonical blast match eight front end or what's going to happen there. We're actually working with all of them. We're seeing a lot of things people are building with con. They're quite innovative and interesting.
There's actually a company in Belgium that's building kind of a multi-tenanted API directory on top of con 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 death match, but we do every once in a while, nudge them and say, hey, you know, that other guy has implemented this new features and you haven't.
Maybe you should take a look at it. That's the entrepreneur in there and you again saying, you know, bring out the competition. Yeah, just to make everybody better. A little bit of public shaming, doesn't it, anybody?
And people are building integrations with it. And that's really exciting to see because it's things we haven't taught 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 I said, we're going to be given the morning and you see the surprise and it's like, wow, this is cool. Yeah, let's talk briefly about the open source and this 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 source? You touch on it briefly, but if you could, you know, restate that and give like, where does this fit into mashape as a company? So, like I said, mashup is a company. We have a number of products and services.
We have the API marketplace. We have API analytics, a product called Galileo. We have a developer called gelato and a few other products as well. It open source has been an RDNA 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. Node.js one gets about a million downloads a month or something and the PHP one gets about $30,000 a day. We just, we enjoy building open source as part of being developers and engineering driven as a company.
And, you know, 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're conversational 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 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 money. So, you know, bleeding that for money for buying your product or using your service. So, in open source and con, 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 the kind of necessities for building API products. If you want to make money and monetize things, then monetize based on services, monetize based on value added to people. The reality is, all of our clients are developers, too.
And there's nothing stopping our developers and our clients are going on building their own API management solution. They can't. 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 player just makes sense because it is a commodity. It's not something that people should be charging enterprise level contracts with and paying hundreds of thousands of dollars for. So, we just want to give it up for free.
So, you said the enterprise edition, there's actually not a difference in what we call the enterprise service on con versus what con. As 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 con and many people do. They come to us and they say, look, we just want to have you in our production level environment so that if something happens or if we need your help or something or there is a demand to change things on the fly, instead of managing relationships and maintaining the products internally, with our teams, we also have your team come and be part of maintaining the product and helping us answer questions.
So, it comes to support relationships 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, they need to have something customized or something developed for their own needs.
That's where they engage us for the professional services aspects. So, we can come in and help them with the integration of 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 for a user. I think that's a good place for a break.
On the other side, we will talk about getting started with con. I also want to ask about future roadmaps and where con 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 Change Vault, 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 1D and 30 gigs of SSD drive space, totally for free, on DigitalOcean, use the code, ChangeLog.
Again, that code is, ChangeLog, use that when you sign up for our new account, head to DigitalOcean.com to sign up and tell them to change the code. We're back and we're ready to wrap up this conversation about con, 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 con. I want to try it out.
What do I do? What are my first steps? So, first step is you go to getcon.org or simply go to mache.com and find the link to con from there. The website will provide you a link 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 con does, we actually offer a number of distribution packages for a number of Linux distos. So, depending on what Linux distribution your server runs on, you can actually download it for W and CentOS, but have so on. We even offer a cloud formation template for AWS users. We even offer an AMI for AWS users as well.
They don't want to build servers from scratch. And we even offer Dockerized versions of con 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.
We're also working on a new, if you want to develop for con and run, you know, build your own programs and run it locally, then we actually have full instructions about to run the source and run it with invagrant as well for Windows users. Because, in Genex, it doesn't run natively on Windows. That's it, man. So, do you feel that?
It's super easy. That's what we like to hear. Looks like you don't yet support digital ocean, Heroku, Microsoft, Azure, but these things are coming soon for BSD. We do support them.
Obviously, digital ocean runs on Debian too. And Azure as well gives you an Debian-like system to set up with Linux and everything. So, we do support them. But what we want to do is just automate that process and having 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 actually click about the Nxito form on AWS side. You fill it up and then your servers are launched. So, that's what we're actually aiming to do with the Google CloudForm and Azure and Digital Ocean as well. I see.
So, you have a little flag there, man. It 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 other 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? 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, 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 at the end 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. And the next release we're adding cluster awareness for 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 invalid each other's caches or reset each other's caches, which makes the system even more dynamic and introduces more functionality for building plugins and features across them. Beyond that, like I said earlier, we're introducing Postgres as well. It's a database choice for developers and people who want to run Postgres in production.
And we actually try to publish our Wookiee and Roadmap, sorry, we try to post our Roadmap in our Wookiee 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 GitHub channel for live chat with our community. And really, the communities, the ones 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, then that's just takes higher priority than others. So, if you look at the Postgres issue in GitHub repo, I think there's something around a couple hundred plus ones on the issue because people just keep on going, I'm like, yep, plus one, I want this.
And so that obviously became a hard priority because clearly there's a lot in the match 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, what needs to be expanded on. And we prioritize accordingly and just do it by the community's feedback.
Well, let's cut straight to the chase and talk about when is GitHub going to implement up voting and having on their issues. I mean, come on, the plus ones are ridiculous. There's a GitHub plugin called Zenhub, which kind of gives you the troll view of GitHub issues and actually has a dedicated plus one button on the kind of super-imposed. 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 highly recommend it.
Yeah, so GitHub, if you're listening, hire the Zenhub guy to 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 match shape 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 champing 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.
Or 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, you know, 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, you know, give us feedback, talk to us on the chat, open issues for anything that you think is lacking, or just, you know, email us in this chat or go for coffee and talk about APIs and technologies in general, because we're all API nerds at match shape and we love talking about this stuff all the time. Alrighty, well closing question time and the compulsory question that we just love to ask everybody is, who is your programming hero and why? Alright, I don't have to think too much about that because I always quote this person on time. So my programming hero is Grace Hopper, who if you're not familiar with who that is, she was back in the US Navy, one of the early programmers back there.
And she's usually credited for creating or inventing the word debugging in 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 early, in the war and encryption, there was an actual bug in a system. That's what a word bug came from, but the word debugging kind of came from Grace Hopper, and that's three people she's created for. But what I love her the most for and the more I learn about this person, the more amazing she becomes in my mind, is the one quote that I actually just found by Hapstance and then I got to know more about Grace Hopper 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 the 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 in a broad sense, those kind of people are generally tasked with the purpose of managing the developers or managing the technologies on their teams. But to a 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 really 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 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 different roles and responsibilities along the way. And in many places, my role has always been the development manager or the team lead or the manager kind of stuff I always made it sway 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 boss 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 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 it's actually not because it's not so much that I'm able to kind of bridge that gap between business language and the business. And the 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'm, you know, keep reading more about her and what she did.