 OK. I guess we can start. My name is Marco. I am the CTO and co-founder of Macheape. Macheape is one of the makers of Kong, the API gateway. And today, we're going to talk about microservices. We're going to talk about Kong gateways and how the two really work together. And we're also going to show a demo of Kong running on top of Mesas. So I've got my environment running. So we're going to see Kong in action. We're going to add an API on top of Kong and see how all of this fits together. So before I even start, why are we talking about gateways and microservices? What's happening right now? Well, so microservices are the software answer to more and more complex demand, to more and more complex requirements that our software has to take care of. APIs got very popular in 2007. You had a mobile app. You had a public developer community. So how do we make these developers consume, these applications consume, our APIs? And sometimes APIs used to be an afterthought. Hey, we have to create an API so that developers and mobile apps can consume our system. And then as we onboard more and more partners, as we support more and more platforms, software becomes more complex. And microservices really in 2014 start this huge trajectory and adoption. And do you know why it's happening in 2014? Well, Docker was released a year ago, a year before, I'm sorry, in 2013, which means that Docker and containers are finally giving the tooling for everybody else and for the rest of the world to engage into this transition to microservices. Some companies have done it before. Think of Amazon, think of Netflix. Some companies were progressive enough to adopt microservices before this tooling was in place. But really, containers are what enable the rest of us to adopt microservices and move forward with this new way of building software. Somebody said that moving from monolithic to microservices, it's like moving from a chicken to chicken McNuggets. So you have this whole chicken. You have your monolithic app. And you're transitioning now to smaller components that are working together with each other. And the whole thing is, during this transition, which is a very painful transition that pretty much every enterprise is doing right now, this transition, you have to keep the chicken alive. You can't kill the chicken. You need to keep supporting your clients. You need to keep your applications running. You have to engage into this transition by making your system working, keep working. And there are different strategies to move to microservices. There are three main strategies, I would say. I've been talking with lots of people, lots of companies who are approaching this transition now or have approached the transition before. And usually it comes down to three different options. There is the ice cream scoop strategy. So you have this huge ice cream cup and you need to extract from your monolithic app individual components and microservices that now can leave and be scaled separately, they leave separately, that can be built separately. And then there is the nuclear bomb strategy. So some companies are deciding that monolithic it's not a solution anymore, and so how about we just rewrite the entire software in microservices so they get rid of their monolithic app and they transition 100% to microservices. And then there is what I like to call the legacy macro service. So you only build new technologies, new software, new products in a microservice-oriented architecture. So you keep your legacy monolithic app there instead of your system as a gigantic service effectively that works together with those new microservices that new teams are creating. You know, by the way, transitioning from monolithic to microservices it's not just a technological change. It's an organizational transition. When you're transitioning and making this transition to microservices you are also changing how your teams are built, how your teams are working together and how your organization, it's communicating with each other. You effectively transition from large teams to smaller pizza teams. And these smaller teams they can experiment with different technologies but effectively they're working on separate code bases and they need to publicize to the other teams an easy to use interface for them to understand. Think of Uber. So Uber used to have a huge monolithic app that was baking together all of these different feature functions in one code base effectively and then they decided to extract all of these in thousands of separate microservices that now can operate independently from each other. Running microservices, right? Separating these monolithic apps into smaller P components it's really a little bit like running a city. You need to have roads for these microservices to use to communicate. You need to have fire departments. You need to have security police departments. You need to have an infrastructure in place that can make you successful with this new way of building software. So since this is one of those transitions that everybody's doing right now I have it here on my slide deck so we can do it together, right? So we start from a monolithic app with all of these components built in into one code base and then one team comes in and decides to extract one of these services outside of the monolithic app. And so we have these items microservice now that lives separately from all the other components. And guess what? Once you have these microservice it doesn't live in a vacuum. You need to have that infrastructure, that city in place in order to be successful. And so the same team will come in and build more and more logic that's complementary to this microservice's success. You build security features, authentication features. You build logging, transformations. You build all of that stuff. And then another team, or maybe the same team goes ahead and extracts another microservice. And now you end up with rebuilding over and over again these complementary features that every microservice will have to implement. With lots of fragmentation across the board, right? Lots of duplicated features, lots of duplicated code bases that eventually will create problems down the road. And so gateways and the API gateways can help in two different ways. Number one, they can help by becoming an abstraction layer that sits on the execution path of every request that's going to one of these microservices and centralize together into one place all of those common features that otherwise each team or each microservice would have to implement. So think of authentication, security again, logging, transformations, service discovery and stuff like that. In this case, the gateway, it's Kong and we call those features plugins. Plugins are effectively middleware functionality that you can dynamically apply on top of any microservice behind your Kong cluster. And then another use case for API gateways, it's aggregating and collapsing different responses into one response. When you have a microservice consuming other microservices, sometimes you will have to make requests to more than one upstream service. And so what the gateway can do, it can become that abstraction layer that you put in front of your microservice or architecture in order to collapse these responses into one response. So the client makes one request, but then the gateway itself will trigger other requests in your infrastructure and return one response. That's especially useful if you want to optimize for a bandwidth and for size because you do not have to retrieve or trigger multiple requests and keep track of the state of those requests from your clients because the gateway will do that for you. Gateways are also being used for a third use case which is decoupling that monolithic app under the hood without having clients to deal with these changes. So assuming you have a client consuming a monolithic app and assuming you are decoupling that monolithic app, now the client needs to know where to make those requests but the gateway can be that curtain you put in front of your monolithic application. The client will deal with the gateway only and then you can decouple your monolithic behind the curtain without having to worry about updating your clients. And this is especially useful if you do not control your clients. You know, when you think of gateways, you really think of something that stays in the edge because that's what API gateways used to do. So you know, back in the days, you had your monolithic app, you had your API, APIs sometimes were an afterthought and then the API management solutions you would adopt were monolithic blackboxes effectively. Close source, hard to extend and hard to scale in a way. But then with containers and microservices, something happened. First of all, the topology of our traffic, it's increasingly moving behind the firewall and not just outside of the firewall. You have a lot of critical information happening here behind your firewall and you cannot put a blackbox you can control. Effectively, you want to put something you can extend, something that can scale alongside your microservices into pretty much any container, containerization platform, Mesos, for example. You still have the external client use case, but that becomes one of the many clients that are now consuming those microservices. And the reason is, the reason why we have this increase of communication, well, you probably already know it, it's straightforward, microservices have to communicate with each other in order to function. A monolithic app doesn't have this problem. Everything, it's the same code base. So you don't really have to go on a network most of the times to provide what you have to do. And so actively this changed how gateways are being used internally. But when you think of gateways again, you usually think of a centralized layer, an extra hop in the network that are processing these additional features. But that doesn't necessarily have to be true. You can also run a system like Kong, for example, alongside your existing microservice process. You can effectively then get rid of that extra hop in the network and reduce the latency. Now latency, it's another important factor. Back in the days, if that solution added 100 milliseconds or 200 milliseconds of latency on top of your requests and responses, that was not ideal, but it's something you could live with. With microservices, every latency compounds. And so at the end of the day, you will end up with an enormous latency if you don't take that into account immediately. So I can show you how Kong can implement sub-millisecond latency on most of these features. Microservices can provide internal communication, private communication, or maybe external with two partners, for example, or with a public developer community. Or maybe you're starting to adopt functions as a service or server-less functions with AWS Lambda, IBM OpenWisk, and Kong supports all of these use cases. You put it in front and then Kong can handle for you all of those common features you need to execute on every request. Effectively, you are reducing the fragmentation of your system. You're moving from the picture to the left to the right. You are putting in one logical place all of these functionalities. So let's talk about Kong the technology. So what is Kong, really? Kong, it's an open-source API gateway. It's the most widely adopted API gateway right now. We have more than 300,000 running instances per month across the world. It's built on top of Nginx. And Nginx, it's a very solid foundation for us. Chances are if you have an API, you're really using Nginx. It's an Nginx process that starts up and then it's being extended with all of the gateway features. We call those gateway features plugins. And plugins are middleware features. You can apply dynamically on top of any API or microservice behind Kong. You do that with an admin API that Kong provides. So you have a JSON-restful API that allows you to provision new services on top of Kong, to provision new consumers, new credentials, to provision new plugins in a dynamic way. Doesn't matter if you have one Kong node or a hundred Kong nodes across five different data centers. The admin API will eventually propagate all of this information across every node, every Kong node, without you having to restart or reload those nodes, without you having to reconfigure those nodes. Cache, most of the dynamic information Kong has to deal with in the process, in memory. So after Kong warms up, and I'm gonna show you later in the demo, Kong will cache all of this information in the process. And for most use cases, we will achieve a sub-millisecond processing latency on top of those requests. We support pretty much every containerization platform. It's cloud-native. We have a native support for Mesos and for the COS. We also have an official Kong package on Universe if you're using Mesosphere. Extremely fast. And then Kong comes into different flavors, right? So we also deal with enterprise use cases across the board. You know, when you have an API, when you have a microservice-oriented architecture, it doesn't really matter what industry you're working into, right? If you're a healthcare, if you are IoT, if you are a government, if you are a bank, you will end up with the same set of use cases that everybody else has. And so Kong, it's being adopted by these customers all across the world in four different time zones, Asia-Pac, US-West, US-East in Europe to help dealing with these problems. So let's take a look at plugins. What are plugins? Kong is built on top of NGNX and Lua, on a system on a framework called OpenResty. And plugins are Lua, it's Lua code, effectively, that hooks into the lifecycle of every request and every response and then executes some sort of operation. It can also change how the request is being made. It can also change the response. So for example, there are authentication plugins. There are plugins of any kind. There's authentication, there's security, there's logging, but for example, authentication plugins. You want to, you have an API, you want to start authenticating those requests with a third-party OpenID Connect provider, or you want to implement auto-to-penal authentication on top of that API. You let Kong do that for you by installing those plugins on top of your microservice. Maybe you want to start invoking and reacting, reacting to events, and you want to trigger AWS Lambda function invocations. You want to trigger IBM OpenWISC actions. You can still do that on top of Kong and then add other plugins as well on top of your execution lifecycle to protect secure and rate limit how these functions are being invoked, for example. And this is really how you use plugins. So you've got this admin API which allows you to configure the system. So in this example here, I'm applying the rate limiting plugin on top of that specific API with that specific ID. I make this one request and I tell Kong, okay, every plugin has its own configuration, right? So in this case, I'm telling Kong, I want to allow 10 requests per second, 50,000 requests per hour. I execute this request and now Kong will dynamically apply this plugin on top of my API across every node. So effectively, if you have many data centers, you have just applied a distributed rate limiting feature on top of your entire cluster. It's platform-agnostic, runs pretty much anywhere. And most importantly, it can run in hybrid environments. We do have, you know, came across some use cases of customers that are transitioning to containers. Not everybody is as progressive as the people here in this conference. Some companies, some teams are slowly transitioning to containers. Some teams are still stuck with soap and, you know, they want soap to rest, right? So the word is 10 years behind what we're discussing here in containers. The word is moving there, so that's good news. And some companies, for example, want to run hybrid clusters of Kong. They're transitioning from bare metal to the cloud or bare metal to containers, or maybe they're playing with different containerization platforms and they can spin up a Kong cluster that runs across the board and shares data with each other node across these other installations, deployments. If you're using Mesosphere in DCOS, it's extremely fast to start getting up and running with Kong. You just search for Kong and it's one click deployment and you're good to go. So let's take a look at the architecture of Kong, okay? So Kong, it's a stateless server. You can run Kong, you can add Kong nodes, remove Kong nodes, nothing will happen. The state is being stored in either Cassandra or Postgres. You can choose it, either or. We recommend Cassandra for distributed and more complex use cases. We recommend Postgres for simpler use cases. Postgres, and the reason is Postgres, it's a master slave data store. So if you're running a Kong node in another data center, that Kong node will have to go all the way to the master DC of Postgres in order to write some information. With Cassandra instead, you have an eventually consistent distributed data store. It's master less effectively. You can write and read from any node and Cassandra itself will then take care of too to replicate this information across the board. And as long as your Kong nodes communicate to the same Cassandra key space or Postgres database, then you're good to go. They will all share the same data. Now the trick is, Kong doesn't make a request to the data store on every request that comes in. It only makes a request to the data store the first time and then it will cache this information in memory in the process. Which means that after Kong warms up, it won't have to go again on the data store. You can tolerate a data store failure and Kong will process all of this in memory. If you're changing the same data from a different Kong node, Kong understands that and will propagate an invalidation event across every Kong node, telling the Kong node, hey, this data has changed. The local copy you have in memory, it's not valid anymore. So refetch it again from the data store. Kong is built on top of Nginx and OpenResting. It's a very performant architecture. We're running Lua code on top of the LuaJit virtual machine. LuaJit, it's a very fast C implementation of the Lua virtual machine and we can embed that into Nginx to script how Nginx works. On top of that, we have added support for clustering in data store so you don't have to worry. Once you start a Kong node, you don't have to worry about restarting, reloading it, reconfiguring it. It's all dynamic and support for plugins. Plugins are written in Lua. They basically, a request comes into Nginx and plugins take over that request and response and they change it if they have to do so and then they proxied to the upstream service. And then when a response comes back, response plugin can take again ownership of that process, change what the response does and then return it back to the client. And on top of all of this, we've got the admin API. The admin API allows us to configure the entire system. You can provision APIs, you can provision plugins, you can provision credentials. Kong can run into different modes. You can decide, for example, to use Kong as your authentication store. So Kong will store all the credentials and for example, if you're using OAuth, it will store the access tokens, the refresh tokens. If you're using basic out, it will store the username and the passwords but that's not always ideal. You can also use Kong in a different mode by leveraging a third party authorization server to authenticate your request. So for example, any OpenID Connect compliant provider or OAuth to open an introspection endpoint compliant providers. When Kong starts, it listens on a few ports by default. These ports are divided into proxy ports and admin API ports. The proxy ports are the ports that your client will consume when he wants to consume an upstream service. So this is the one that will be made available to either other microservices or external clients. And the admin API, it's the one, it's the API you're gonna use for configuring the system and of course you will firewall these ports to prevent external access in production. So when dealing with Kong, we're going to deal primarily with a few entities. We're gonna deal with APIs, with plugins and with consumers. These are core entities that sooner or later you will have to deal with when using Kong. But then plugins themselves can extend the underlying DAO model of Kong by extending the system with new entities that you can use. For example, if you decide to adopt a key authentication plugin, well now you'll have a way on the admin API to provision and store those key credentials. And if you have, for example, again, OAuth 2.0, you will have APIs that allows you to create OAuth 2.0 applications, tokens, and authorization codes. All right, so I've got my demo environment running. It's on Apache Measures 1.3.1 on Amazon Institute. It's running, it's very simple setup. It's running one master, two slaves. And these are the URLs that I'm going to be using when configuring the system. We've got Marathon on port 8080, and then we've got the Kong Proxy URL and the Kong Admin URL on two different ports. So I'll go ahead now and load my terminal. So first of all, if I go here on my browser, we can see, this is Marathon, we can see the Kong application running. And if I click in here, we can see there are two different containers running. There is Kong itself, and then there is Postgres. So in this demo, we're going to use Postgres for storing all of these, all the Kong state. We only have one Kong node that's listening on two different ports. So this is the proxy port. So if you make a request to this port, Kong, it's empty right now, doesn't know where to proxy this request to. And then the other port, it's the admin API of Kong. So this is the default index page for the admin API. And for example, if you go on slash APIs, we can see that there are no APIs configuring the system. So I'll go ahead and add and provision a new API on top of Kong, and then I will secure this API, and then I will rate limit this API using Kong plugins. You can see a list of Kong plugins on the website. These are the ones that come bundled with the system. So these plugins are immediately available to you to be used, but you can also extend the system with your own plugins. So there is a guide in the docs which allows you to build new plugins. And so these plugins that you're seeing here in the plugins hub. So this is the guide for building new plugins. And these plugins you're seeing here, these are the ones that are the most common ones, the most used ones, but you can also go on the community on GitHub, for example, and find over 200 contributions to plugins, Kong plugins, to pretty much deal with any sort of use case. You can also extend and build your own plugins for your own internal requirements. So for example, there are many users that have to deal with legacy authentication systems, who have to deal with legacy transformations. You can build plugins that are available only to you in your system that deal with that legacy use case, for example. So it's a highly extensible, you effectively control everything about this gateway layer. Okay. So let's go ahead and provision an API. So for this demo, I'm going to use httpbin.org. I don't know if you are familiar with this service. It's a cloud service that effectively provides some endpoints, which we can consume to retrieve information about the request for making. So for example, there's a slash get endpoint, which returns back a JSON response with the headers, the client in sending, and this information. We can use this for debugging really what's happening between our client, Kong, and the final API. All right, so let's make a post request to provision our first API on top of Kong. Effectively, what I'm doing here, it's telling Kong, okay, post a new object, create a new API whose name it's httpbin, the base upstream URL, it's httpbin.org, and the mapping, it's going to be slash test. You know, when new requests come into Kong, the Kong needs to understand what upstream API we're trying to consume. And we can do that in different ways. We can create a URI mapping, we can create a host mapping, or we can create a method HTTP method mapping, or we can use any combination of these three to create our custom mappings. So effectively by doing this, I'm telling Kong, every request on slash test in Kong will have to go to this httpbin.org API. Kong can work very well with existing service discovery tools, or you can use Kong as well. It's some built-in discovery tool for resolving dynamically those host names. So for the demo, I'm just effectively putting Kong in front of a public API, but you can put it in front of any internal or external API as well. So if I make this request, we've got our response. Kong has provisioned the API in the system, and now it's ready to be consumed. So if I make a request to the other port, I can now consume that API. So we'll see how it works. If I just make a dumb request like this one here, without any specific URI, Kong will complain that no APIs are found with this value. Even if I do this, there is no API that matches that specific mapping. But if I make a request on slash test, which is the mapping we've created, slash cat, for example, Kong will understand that we're trying to consume the HTTPbin API. It will append on the base URL we've configured, the slash cat endpoint. It will strip out the slash test, and then it will reverse proxy to HTTPbin. So this is Kong proxying to HTTPbin. We can see how we have a few latency headers. We have 11 milliseconds for Kong, nine for the upstream HTTPbin. If we make requests with Kong, eventually the Kong latency will go down to zero. So this is the Kong in process caching mechanism that takes into effect. So Kong, the first time, needs to know from the data store what API we're trying to consume. It will cache this in the memory of the process, and then it won't have to go to the data store ever again. Okay, great. Now we have an API in Kong, simple reverse proxy. Let's start using some plugins to enhance what this API can do. So we can go on the plugins list, for example, and we can decide we want to protect this API with an API key. So we apply this plugin by making a post request to the HTTPbin API slash plugins, and we tell the system we want the key out installed, and we want to configure this plugin in a very specific way. Thankfully for us, we don't have any mandatory configuration parameter besides the name, so that would be enough to protect this API. So let's go ahead. Now there is an API installed, a plugin installed on top of that API. If I consume again, the same way I did before, this time Kong will complain there is no credential in the system, in the request. So let's provision a consumer, and let's provision a credential for this consumer. Think of a consumer as anything that can consume the API. So it can be a developer, or it can be another microservice, or it can be a mobile app. So I'll create a developer called demo in this case. And this demo user will have a key credential called secret123. As you can see, I'm effectively making requests to the admin API of Kong. It's a regular HTTP request. This also allows us to integrate Kong with our continuous integration systems, with our existing applications, or with scripts. You can automate how Kong is being configured in the entire cluster. It's just a reasonable API. So whatever can make a request to this API can also configure the system. So now we have a consumer, we have an API, we have a plugin installed, and we have a credential. So we can consume our API by appending this API key that we've just created, secret123. If we do this, Kong will validate the key, it will validate the consumer we're trying to use, and it will proxy the request to the upstream service. If I use a different key that does not exist, of course Kong will block me again. It doesn't matter if I had one Kong node or a hundred Kong nodes across five different data centers, across five different clouds on top of Mesos, for example, all of this information would be propagated dynamically. You don't have to worry about it. So let's rate limit now how many requests this consumer can make. And so for that, we can go pick the rate limiting plugin, which is here. And the rate limiting plugin allows me to configure a few configuration options, but effectively, I can configure how many requests per second, per minute, per hour, per day, per month, or per year. I want to use to rate limit the users. I can rate limit by IP address, by consumer, by credential. So this is a little bit more complicated, but let's go ahead and rate limit by, let's say, five requests a minute. I'm adding a new plugin. This time it's rate limiting on top of the same API. I consume with my key, like the same thing I did before. And this plugin will go into effect. It will dynamically be fetched, loaded, and it will rate limit how many requests it can make. It will also append some response headers, telling me what's the number of total requests it can make, and what's the number of remaining requests it can make. And so if I make more than more requests, we can see how the counter decreases. And if I make more than five a minute, the system will block my requests. Now, this is a very simple demo, okay? So I'm securing the API, I'm rate limiting the API. This can get way more complex if you want to do so. Maybe we have consumers that should be able to make more requests, or maybe we have internal clients that should be able to be blocked on specific URIs. We can stack together plugins, as we wish, to create these policies that will be then applied on the execution path. I believe that we don't have much more time. Five minutes, okay? Among the plugins that you can use with Kong, besides authentication, because besides security, you can also apply request termination, you can apply serverless invocation. So let's assume you want to be able to create a RESTful interface for your Lambda function, or IBM OpenWISC function. You can do that with this plugin, and then you can stack together other plugins, protect, secure, rate limit, how many requests these people can make. You can then also plug this in with monitoring and analytics solution. But if you have, for example, Splunk or the Elk stack, Kaban and Elasticsearch, you can use any of the logging plugins to push to these systems all the information about every request and every response in order for you to keep track of what's going on across your microservice infrastructure. We do also support dynamic load balancing and service discovery. So if you use Kong, you can actually tell Kong to be the dynamic load balancer for your upstream microservices. The admin API gives you endpoints to add and remove target nodes from a named upstream service that you can use on top of Kong. And you can then also create your own plugins again, and you can find plugins on the community as well. So this is a static page. What we're doing right now, we're changing this to make it a searchable hub. So you will be able to push your own plugins to the system, and you will be able to fetch and search for other people's plugins to use on your system. And this is it. We do have a booth in the hallway. So if you want to learn more, if you want to see a live demo, we can show you a demo there. There are a few guys from Kong as well really to answer your questions as well. Thank you. Can you put Kong in front of your user interfaces as well? Yes, you can. Kong, it's an HTTP proxy that supports any HTTP or HTTP2 service. So you can use these also for your web applications. What practical limitations are there to what you can do in a plugin? Like, what do you recommend you don't do? Like, could I go and host my entire web app as a plugin in Kong? Why shouldn't I do that? What kind of guidance do you give people? You could, as a matter of fact, you could use Kong as your function as a service platform. Think of a plugin as something that can also terminate a request with a custom response. So now, if you think about it, you can create functions instead of a plugins that can be invoked on top of an HTTP interface and run on top of Kong. Now, the nice thing about it is that you're running on top of a very efficient architecture, which is of Nginx and Lua. So you could effectively do that. You can also synchronously or asynchronously communicate with third-party services instead of a plugin. So you can receive a request. By leveraging the asynchronous IO of Nginx, you could make a request somewhere else. You could aggregate multiple requests. You can then return a custom response with whatever transformation you want to do in the meanwhile. So you could pretty much do any, you could also open new UDP or TCP ports in a plugin. So we don't recommend that, but you could do that. OK. I'll talk to you more later. So we looked at configuring the Admin API, and that's how you configure a whole Kong cluster. Is there any sort of authentication mechanism or role-based access control that you could find for Kong to protect the Admin API? Yeah, so the Admin API should be protected from external access because anybody who has access to that API will be able to mess with your configuration. We do have two different editions of Kong. There is a community edition, and then there is an enterprise edition. So this is the community edition of Kong. You can download it. You can use it. It's free to use. There are no limitations. And then there is an enterprise edition of Kong which extends Kong with some enterprise features. Among those features, we also have role-based access control for the Admin API so that you can control exactly what users, what teams, can access the Admin interface so they don't mess with it. The enterprise edition of Kong, it's also a full cycle API management and microservice management solution. So we also provide developer portals for your team, for external consumption, analytics, and so on and so forth. Last question. So how does Kong integrate with something like Marathon? Or is it just kind of up to you to orchestrate both of them at the same time? So Kong, it's being shipped with an official Docker image. So we provide a Docker image you can use pretty much anywhere. What we have done was to create a specific integration for the COS. And you just use Marathon to schedule your Kong cluster like you would do for any other Docker container, effectively. The system itself can run anywhere. So it's very simple. It's stateless. You can spin up as many Kong nodes or replicas of your containers on top of Mesus just by using Marathon or by using the COS. It's straightforward. Kong can integrate with that. So Kong can now to discover your upstream services. So we do have support for that. Thank you.