Hello, thanks for joining. today we will be navigating the world of API gateways. So I hope you enjoy, let's get started. over the years, applications have transitioned from monolithic architecture to. microservices and cloud native environments as the number of services grows. So that's the complexity of managing API traffic, security and performance. So, in the scope of, these, presentation, we will answer the question. What is API gateway? Why do we need them? Then we will, compare, five, open source API gateways. And, in the end of presentation, we will look at, future trends of, developing the, API gateways. Yeah. let's get started. why do we actually need, API gateways? There are, a lot of challenges that, modern systems face every day. the first is, uncontrolled API traffic, then, security risks, performance bottlenecks, and, lack of observability. So API gateway tries to solve. those problems. So API gateway, is a reverse proxy that sits between clients, which are users, applications, or external services and, backend, services acting as a centralized traffic manager. it controls how API requests are routed and authenticated, transformed and monitored. API gateways are essential in microservices architecture, cloud native applications, and distributed systems. as I mentioned before, it solves those problems, the problems like traffic management and request routing. API gateways route incoming API requests. to the correct backend services based on URL paths, headers, query parameters, user identity, and other, requests, properties. they also support L7, AKA application layer, routing for REST, gRPC, GraphQL, WebSockets, and even. TCP, UDP traffic, and they also provide traffic splitting, enabling, AB testing, blue green deployments and canary releases. API gateways also, improve performance, by load balancing requests across multiple backend instances, by caching frequently used responses. By compression, to reduce response payload size and also request response, transformation like, changing headers, payloads, or protocol versions, and, also, they act as a central security layer for all API calls implementing, authentication mechanisms like OAuth2, JWT, OpenID Connect. MTLS and, many others. and they also, provide detailed, analytics for, on API traffic, like metrics collection, logging, tracing, and they usually provide real time, dashboards for, API traffic insights. and they're usually, extensible and customized. they provide built in plugins for rate limiting, authentication, logging, and so on. And, they also provide you with the capability of, writing your, own custom plugins to extend. the functionality. so we will, discussing, in the scope of this presentation, we will be discussing five, open source, solutions. And, but first we would need to answer, why open source? Why I chose, open source API gateways in the scope of, this presentation. So first of all, it's a cost effective, large, enterprise, enterprises save millions annually, by switching from commercial gateways to self hosted open source solution solutions. also, it's, transparent. So no black box. So you can, See the code, you can, I don't know, add, your own feature or bug fixes. and, and it's community driven. open source projects usually evolve faster than commercial products and, large developer communities contributes new features regularly. So we will be discussing five, open source API gateways. And, I chose, Apache API 6, Con, Tick, Kraken D and, Glue Edge. So let's start with the first. Apache API 6 is an open source, high performance API gateway built for cloud native, multi protocol and high throughput applications. It provides dynamic configuration, rich, plugin support. While maintaining, ultralow latency. so key, technical details you can see on the screen. it's written in, open rest team in Jinx plus, logic. it's, licenses, Apache 2.0, which means that it's, fully open source. storage options is, etcd and, files configuration options, admin API, YAML files or declarative configuration like, Kubernetes, CRDs if deployed to Kubernetes, plugin system. contains built in plugins for security, traffic control, observability, and transformations, and it supports custom plugins written in Lua, Go, Python, and WebAssembly. For security authentication, and authentication plugins, they have, OAuth2, OpenID Connect, JWT authentication, API key based authentication, and many others. For observability, they have metrics collection with, Prometheus plugin, also OpenTelemetry. data doc and, for distributed tracing, skywalking. And, I want to, I want to pay your attention that this, presentation, it contains the links to the official documentation. Of API, of API six and, other gateways as well. So you can, go, to these links and, see what they actually provide because, obviously I couldn't, add, everything to this present. presentation, it would be, not readable at all. So I just, mentioned the main things and, hot reload is supported. So you can apply dynamic updates via admin API without restarting. You can add, plugins, you can change your routing configuration and so on, and it will not require the restart. So let's move on to the second API gateway, it's Kong. It's also a high performance open source API gateway designed for scalability, security, and extensibility. It's built on Jinx and OpenResty. It offers a powerful Plugin system, multi cloud compatibility and enterprise ready security features. licenses, Apache 2. 0, as previous one, for storage, options, they support, DBLS, storage, they, support, their own storage, connect, also you can use, database like Postgres. For, persistence, and, yeah, for configuration options, the files are available, Kubernetes CRDs and, admin API. plugin system, has over 50, built in plugins for rate limiting, caching, security, traffic, traffic control, and it also supports, custom plugins written in Lua, Go, Python, and WebAssembly. among the authentication plugins they have OAL two JWT OpenID Connect, L-D-A-P-A-H-M-A-C, and, other authentication mechanisms. For observability, for metrics, they support Prometheus, OpenTelemetry, Datadog, and Zipkin for distributed tracing. They also support hot reloading via admin API and you can also apply dynamic updates without restarting. So The next, gateway is, TIC, TIC, is, a high performance open source gateway designed for scalability, security, and multi protocol support. it's built in Go, not, Lua and Jinx like previous API gateways. It provides native GraphQL support, authentication, and rate limiting. And flexible deployment option for cloud, hybrid and on premises environments. as I said, it's written in Go, high performance and multi threaded. The license is MPL. For storage, they use Redis. It's used for caching, rate limiting and state management. And, also optionally for, dashboard, for analytics, they, use MongoDB and, SQL, database. So configuration options are admin API. and declarative configuration using, JSON, YAML, or Kubernetes, CRDs, plug in, system has, built in middleware, plugins for security transformation and observability, and, it supports, supports custom plugins in Go. Python, and JavaScript, Lua, and also WebAssembly. they provide a lot of authentication plugins like Vauth2, JWT, MTLS, authentication tokens, and, like advanced rate limiting plugins, throat link, quota enforcement, many others. You can see, by the link provided in the. presentation, for metrics, they support Prometheus open telemetry, data doc, and also just visit, the links and, you will see the whole list. I want to also mention. that, this, gateway supports, GraphQL, natively, and also, gRPC proxying and, transformation. TIC supports hot reloading via API and dashboard dynamic updates without restarts. the next, gateway In the list is Kraken D. It's a lightweight, high performance API gateway designed for API aggregation, request transformation, and stateless architecture. It's built in Go as well. It's optimized for low latency microservices, offering high scalability with minimal resource consumption. yeah. the licenses, Apache 2.0, storage option, is, stateless. So they don't require any, database, configuration options, are, files. Jason O or IL files. and, you can also actually, specify configuration in environment variables and, in Kubernetes, CCRD if, deployed to Kubernetes, they, have the middleware based architecture for plugins and you can write your own plugins, using, go. They also provide. Provide the, JWT validation, plugins, API key authentication, MTLS, Auth0, like a lot of, plugins for authentication mechanisms, for, monitoring Prometheus, OpenTelemetry, Datadog, and many others. interesting that, they do not support, the hot reloading. they have this option, but, on their documentation, they say that, it's not recommended for prod. It can be used only for, development, purposes. And the last but not least, API gateway in the list is, Glue, Edge, it's high performance cloud native API gateway built on Envoy proxy designed for Kubernetes multi cloud and hybrid environments. It offers a deep integration with Kubernetes, advanced traffic control and enterprise. price security features. So yeah, it's written in Go, built on Envoy Proxy, multi threaded. The license is Apache 2. 0, so also fully open source. Storage options are Docker for. Storage options are, sorry, files, file based configuration, like YAML, or Kubernetes CRDs. Configuration options is declarative, declarative configuration via Kubernetes CRDs, or Helm charts. Yeah. And, you can write plugins, In goal, among the security and authentication, plugins, they have the O2 JWT authentication and LDAP for observability, for metrics support. they have Prometheus, Grafana, and, Datadog, plugins. sorry. they also support the hot reload and zero downtime, configuration. yeah, when, choosing an API gateway performance is a critical factor, especially for high traffic applications, microservices and latency sensitive workloads. here's how the API 6, Con, Tick, Kraken D and Glue H compare. In terms of latency and, throughput. So I, I ordered, those API gateways, from, the fastest ones to slowest. of course, like I, I looked at the benchmarks, on their websites and, I looked at the information on the. internet, and, it seems like the situation is like this. API 6 is the first, is the fastest API gateway because, it's built, on open resting Jinx and Lua JIT, it's, optimized for ultra low latency. this G Jett, compilation just in time compilation in Ji, it runs, plugins faster than traditional Lua used by Kong. So Kong, is, the latest, the last in this, least. so why is D fast cracking D is optimized for API, aggregation and stateless performance make it ultra fast. So it's it's fully written in Go. no scripting overhead, unlike Lua based gate, gateways, it's stateless. so no need for etcd, Postgres or Redis, and it's designed for API aggregation. It merges multiple API calls into a single, response efficiently. And it's, it has the high concurrency, thanks to coroutines. It can handle thousands of, simultaneous requests. with, low resource usage. so why is tick a strong performer? tick balances, performance and extensibility. It's built in go and u and usually, in, many properties, go is, faster than law based. gateways. yeah, it's optimized for security heavy workloads, but it's slightly slower than API 6 and cracking D in a raw performance. yeah, glue edge optimized for Kubernetes. It's built on and avoid proxy. And so provides strong Kubernetes native performance. it's highly optimized for L7 routing, and, yeah, it's best suited for Kubernetes heavy deployments. And, why is Korn slower than, API 6 is because, it's based on OpenResty without JIT, JIT compilation. So slower than API 6 and it relies on Postgres, for persistence. That's database latency, but, it's worse saying that DBLS, mod improves performance, but it's still not as fast as APS XO or Kraken D. And it's, it also contains like a strong plugin ecosystem, but plugin execution, adds overhead. And you can see, I specified here, the. Links to benchmarks, those are, benchmarks in their official sites. and, some of those gateways provide, versus like comparison. APS six, versus cone, crack, crack and D versus cone and versus tick versus cone. it, it can be useful like, day here. they use, different, machines, different configurations. So it's hard to say who, who is, the best, but this is the general picture. And, if you see the. Con benchmarks, they had, done a lot of, a lot of tests in a lot of, machines, with different configurations. So worth checking. So the second thing I want to mention is WebSocket support. Cracking D, doesn't support it in, open source version, only in enterprise version, for gRPC cracking D, doesn't support it as well. and also, the license for TIC, you may have noticed that, it's MPL and, it's, less permissive than, Apache. 2. 0, and I think that it's also useful to see, which customers, like which, technologies use, those, gateways in production. So here's the list and maybe it will help to, to make decision, when choosing the right gateway. yeah, let's move on to the final part. So future trends, as modern applications evolve, API gateways must adapt to new challenges in performance, security, and scalability. And here the key feature, Trans shaping API gateways. So first is a AI powered API gateways like, AI will predict traffic patterns and auto scale APIs dynamically. And, AI driven, anomaly detection will prevent failures before. They impact users. and I saw actually in the documentations of those API gateways that API 6 and con also already look in this direction, but, and they already have some plugins for this, but. Those plugins are just, simplifying access to LLLM, providers. So they, work, only on transformation, like adding headers, transforming, requests, body to, to make the. requesting those, APIs, more eff efficiently. yeah. So the next thing is, Kubernetes, gateway AP API replacing, ingress. as, as, and, I actually checked this, last year and, gateway, API but by Kubernetes was, in beta. But, now it's not. they provide the gateway API and, this gateway API will, replace traditional, ingress controllers that, have, some. Trade-offs. So a, Kubernetes gateway, API, aims to resolves, to resolve, those, trade-offs. yeah, API Gateways will fully integrate with Kubernetes NA native net networking. and actually. glue h and con ingress controller are early adopters of the Kubernetes Gateway API. The next thing is GraphQL and gRPC native support. REST APIs are no longer the default. It's the standard more API gateways will support GraphQL and gRPC natively, including GraphQL query introspection and validation, gRPC proxying with real time transformation, GraphQL caching and schema enforcement. And, I already mentioned this, TIC has full GraphQL support and API 6 offers GraphQL rate limiting and query filtering. And the last but not least is API monetization and marketplaces. So companies are turning APIs into revenue generating products. so API gateways will provide, built in, monetization, including billing and API usage metering, subscription based API models and, self service API portals for developers. for example, TIC and Con Enterprise, already offer. yeah, this is it for my presentation. I hope you enjoyed it and, maybe took, some, something, useful for you. so yeah. If you have any questions, or, I provided the link to, my, LinkedIn account and, yeah, here the references, the links to references I used, for, this presentation. yeah, thank you for attention. I hope you enjoyed it.