Why pick Envoy Proxy and Solo.io over Kong Gateway for modernization

As our customers have embarked on their cloud journey, either around API gateways or service mesh, many evaluated Kong Gateway as well. Kong Gateway positions itself as a “modern API Gateway” – but is it? 

As an IT architect, picking the right technology and architecture for your use case can be daunting. Wading through the vendor marketing can also trip you up. How many organizations have “deprecated” their Cloud Foundry, Mesos DC/OS or Docker Swarm implementations not long after choosing them? Kubernetes came in and so clearly dominated the space that even CIOs are talking about their “Kubernetes strategy” these days.

Envoy Proxy is the clear winner in this next-generation of API technology. Envoy Proxy is to Layer 7 networking as Kubernetes is to container orchestration.

Why Envoy Proxy?

Envoy Proxy is a powerful, extensible, proxy built on C++ and is a graduated project in the Cloud Native Computing Foundation (CNCF). This means, Envoy is not owned by any one vendor and is a big reason why we’ve seen an explosion in projects using it to power Layer 7 including projects like API gateways, service meshes, and even CNIs. 

Envoy originated at Lyft which was in the midst of building a “services oriented architecture” which we now know as “microservices”, and no existing proxies (including the current generation of proxies like HAProxy or NGINX) were sufficient for their needs. Specifically, they needed better visibility on the network (metrics collection), extensibility, and better configuration in a highly dynamic environment. As it turns out, the challenges Lyft faced are very similar to what many companies are struggling with today.

“The network should be transparent to applications. When network and application problems do occur it should be easy to determine the source of the problem.”

Envoy was purpose-built to have a dynamic configuration API (no more config files and hot-reloads with dropped connections!), fine-grained visibility into backends with Service/Endpoint Discovery, and exceptional performance and tight tail-latency since it’s based on C++. These are very important considerations for organizations using modern proxy technology in performant and highly dynamic (ie, cloud) environments.

Lastly, Envoy is supported by hundreds of companies and is also where the innovation is happening in L7 proxies. Envoy was one of the first proxies to support HTTP2/gRPC on both sides of the connection, Web Assembly (for dynamic extension), and more recently, the HTTP 3 protocol. 

Given its broad industry support, its extensibility, and known ability to scale to the largest Internet traffic demands – any modern API gateway or service connectivity infrastructure should be based on Envoy Proxy, or at least you should be asking “why not Envoy”?  

Kong Gateway’s technology foundations are severely outdated

Kong Gateway’s technology foundation is built on Lua and LuaJit through OpenResty and NGINX. This was a very common way to build API Management gateways back in the 2010 time frame (ie, OpenResty originally came out around that time). In fact other API Management vendors like Apigee and 3Scale also followed a similar approach (3Scale used OpenResty, Apigee used NGINX with a Java message processor). Basically this architecture uses NGINX to open/handle the sockets and then quickly pass off to some other engine to handle the request; in Kong Gateway’s case, this is Lua. The problem with this architecture is that there have been no new releases of LuaJit since May 2017!

This has always been a problem for OpenResty users, so they forked LuaJit and have further splintered what is left of a dying community. What we’ve consistently heard from our customers is they don’t want to use technology and architectures that were best situated for 2010 to build their modern API platforms that will likely span the next 3-5 years (at least!) when there are better alternatives. As we’ve recently heard one technology executive say “Sure, use Lua to build games on Roblox but it has no place as the foundation for a modern API platform. We recognize Envoy Proxy as the best technology for that”.

The unification of North/South and East/West traffic

At Solo.io we’ve talked a lot about the convergence of the so-called “North/South” and “East/West” direction of traffic. Our customers and users want a simplified and modern take on managing service-to-service communication and APIs. Policies like API quota usage, zero-trust use cases involving sophisticated security (OPA, mTLS, authorization policies, etc) must be applied consistently and regardless of where traffic originates – whether “north/south” or “east/west”. 

Previous architectures recommended funneling all traffic through a centralized API Management system and a bunch of expensive load balancers. Newer approaches may involve using a service mesh. The problem is significant complexity is introduced when you have multiple ways of managing overlapping security, usage, and telemetry policies (like a completely separate API management platform, a service mesh, developers doing their own thing, etc).  Kong Gateway has a REST API specifically for north/south use cases and a completely different API (and implementation) for east-west with service mesh.

• Solo – unified API strategy for north/south and east/west traffic
• Kong – separate API strategy for north/south vs. east/west traffic

Our customers may need either API gateway technology or service mesh and sometimes both. Whether they are solving north/south or east/west challenges, our customers tell us they want a consistent implementation using Envoy Proxy. 

The likely deprecation of Kong Gateway (Lua implementation)?

The market and open-source communities speak loud and clear. Just like Pivotal and Mesosphere were forced to deprecate and change their technology underpinnings, it’s only a matter of time before the Kong Gateway team feels the same market pressures regarding Envoy. Kong (as a company) has begun investing in Envoy (via their Kuma product) so maybe the question is more “when” will they rebase Kong Gateway to Envoy? Or when will they deprecate it in favor of some new gateway they build on top of Kuma?

Our customers have gone through this determination themselves and decided they don’t want to be left holding the bag on a soon-to-be deprecated product. Going against the direction of the industry can be very costly, very time-consuming and very painful. 

Choose an Envoy-based platform for modern API connectivity

At Solo.io, we are pushing the boundaries on innovation and what modern API management and service connectivity look like. Very early on (February 2017) we adopted Envoy Proxy for our products. Since then we have worked with the largest and most critical deployments of Envoy around the world with enterprise organizations to modernize their API and connectivity infrastructure. Service mesh is a very important piece to the modern API management (what we call “application networking”) story as well as unifying the lower layers with eBPF and supporting higher-layers with GraphQL. Envoy underpins all of this and Solo.io helps organizations successfully get there. If you are interested in working on Envoy and some of the most exciting/boundary pushing deployments of this technology, we are hiring for almost every position at Solo.io!