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.

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.

Kong’s stateless architecture and lightweight footprint allow it to be deployed in a variety of environments, with few adjustments required for deployment strategies. At Kong Summit, the Kong Cloud team described their experience with deploying a provider-agnostic, globally-available, high performance Kong installation.

Today, we’re thrilled to announce the general availability of Kong 1.0 – a scalable, fast, open source Microservice API Gateway built to manage, secure and connect hybrid and cloud-native architectures. Kong runs in front of any service and is extended through plugins including authentication, traffic control, observability and more.

In the last few years, microservices or microservice architecture has become a popular reference in IT due to its benefits and the flexibility this architectural style brings. Before we get into working with microservices and Talend, we should review the basics of microservices or a microservice architecture.