With Kong 1.0 users are now able to control TCP (Transport Control Protocol) traffic. Learn about how we added TCP support, and how you can try it out. TCP traffic powers email, file transfer, ssh, and many other common types of traffic that can’t be handled by a layer 7 proxy. Our expansion to layer 4 will enable you to connect even more of your services using Kong.

API Fortress is a continuous testing platform for APIs. We’ve been a friend to Kong since the beginning. In this guest blog post, we explain how our company uses Kong to facilitate the process of virtualizing APIs.

Four months ago, we declared that API Management is dead and announced our vision for a service control platform. Today, we’re taking a critical step towards fulfilling that vision with the launch of artificial intelligence and machine learning additions to the Kong Enterprise platform – Kong Brain and Kong Immunity.

Kong is very easy to get up and running: start an instance, configure a service, configure a route pointing to the service, and off it goes routing requests, applying any plugins you enable along the way. But Kong can do a lot more than connecting clients to services via routes.

Kubernetes is fundamentally changing container orchestration; is your stack ready to support it at scale? Watch the talk recording to learn how Kong’s Kubernetes Ingress Controller can power-drive your APIs and microservices on top of the Kubernetes platform. Hear Kong engineers walk through the process of setting up the Ingress controller and review its various features.

In a previous post, we explained how the team at Kong thinks of the term “service mesh.” In this post, we’ll start digging into the workings of Kong deployed as a mesh. We’ll talk about a hypothetical example of the smallest possible deployment of a mesh, with two services talking to each other via two Kong instances – one local to each service.

The service mesh deployment architecture is quickly gaining popularity in the industry. In the strategy, remote procedure calls (RPCs) from one service to another inside of your infrastructure pass through two proxies, one co-located with the originating service, and one at the destination. The local proxy is able to perform a load-balancing role and make decisions about which remote service instance to communicate with, while the remote proxy is able to vet incoming traffic.

Jason Walker shares how Cargill is using Kong to transform legacy architecture with a “Cloud first, but not always” approach. Hear why Cargill chose Kong for their API gateway as part of their internal API platform, Capricorn, allowing Jason’s small team to stay nimble while they administer decentralized deployments. In this talk from Kong Summit 2018, Jason shares how Kong routes traffic in Cargill’s Kubernetes cluster.

In our last blog post in this series, we discussed our journey designing a metrics pipeline for Kong Cloud to ensure the reliability of our SaaS offering. We discussed how we re-architected our production data pipeline using OpenResty to send metrics to Prometheus and saw huge performance gains. We are now able to monitor high traffic volumes in our system using much less compute power, lowering our costs.

During the Kong Summit in September Dennis Kelly, Senior DevOps engineer, explained how Kong became a core service—and an integral part of the architecture—across brands at Zillow Group. Starting out with a single use case for Kong Community Edition, Zillow advanced to proxying production workloads at scale with Enterprise Edition, automating deployments with Terraform. Kong’s power and flexibility fueled its explosive adoption at Zillow.