When we first created Kuma – which means “bear” in Japanese – we dreamed of creating a service mesh that could run across every cluster, every cloud and every application. These are all requirements that large organizations must implement to support their application teams across a wide variety of architectures and platforms: VMs, Kubernetes, AWS, GCP and so on.
Today, we are proud to announce the general availability (GA) of one of the most important releases of Kong Enterprise we’ve had to date — Kong Enterprise 2.1 is here! This release represents a fundamental shift in how customers can deploy, manage and scale Kong Enterprise across their organizations.
It’s not every day that you learn your technology helped a company achieve their highest sales in company history. But that is the story of Kong and Papa John’s. I have always loved Papa John’s for their delicious pizza made with fresh ingredients, but what I also think of is their (incredibly addictive) Special Garlic Dipping Sauce.
We are happy to announce the release of Kuma 0.7.1 with minor improvements and fixes, and a new official distribution: Helm Charts!
In support of our partnership with AWS and the AWS DevOps Competency program, we’re re-examining how some of our major customers are using Kong with AWS. To this end, let’s look at our popular case study with TUNE.
There is a great number of logging plugins for Kong, which might be enough for your needs. However, they have certain limitations: Most of them only work on HTTP/HTTPS traffic. They make sense in an API gateway scenario, with a single Kong cluster proxying traffic between consumers and services. Each log line will generally correspond to a request which is “independent” from the rest.
We are happy to announce the general availability of Kong Mesh 1.0! Kong Mesh is Kong’s first enterprise service mesh built on top of Kuma and Envoy that organizations can use to deploy a modern mesh across every application — running on both Kubernetes and VMs — and on every cloud or data-center.
Having worked with many customers and prospects at Kong, one of the main requirements we often hear is how to handle dynamic routing based on the URL and headers. In this blog post, I will cover different use cases we come across for dynamic routing and how Kong can address them. The default behavior of an API gateway is to route the incoming request to the appropriate upstream service. If you are new to Kong, a Service object represents the upstream API or Service.
We are happy to announce the general availability of Kuma 0.7! This is very big release that includes countless improvements and updates, specifically when it comes to multi-zone deployments configuration and Kubernetes deployments. We strongly suggest to upgrade to this new version while paying attention to a few breaking changes that 0.7 introduces. For a complete list of features and updates, take a look at the full changelog.
At Kong, I get a chance to discuss with various organizations their plans and projects to adopt microservices and expose them with APIs. During these discussions, I’ve started to recognize some patterns that appear with regularity – patterns that have less to do with technology than with people. Technologists and engineers like myself usually do not pay too much attention to the “softer” aspects of technology implementations.
