We are in the midst of an explosion of APIs and microservices. For some, the first instinct of creating an API is to get down to building one. Some level of planning will help manage the quality of APIs when working within a team. In this series of blogs, we will be sharing some guidelines on service design while working on API projects with Kong. Let us start by focusing on how to go about designing APIs that end up as entities that the Kong API Gateway runtime understands.

Today is a big day for Kuma! Kuma 1.0 is now generally available with over 70 features and improvements ready to use and deploy in production to create modern distributed service meshes for every application running on multiple clusters, clouds, including Kubernetes and VM-based workloads. Before we unpack this release, a big thank you to the community and to the users that have helped releasing this major version of Kuma with their contributions and feedback.

Today, we’re proud to announce the release of Kong Enterprise 2.2 GA! Kong Enterprise 2.2 is built on top of version 2.2 of our popular open source gateway and brings with it a slew of new features and some Enterprise-only features on top. Let’s dive in! For a long time, Kong has supported not only HTTP/HTTPS traffic with REST and gRPC APIs, but also raw TCP streams. In version 2.2, we now extend our support to include UDP-based protocols as well!

Kong is excited to participate in Amazon Web Service’s (AWS) APN TV pilot program. This series of demonstration videos from AWS partners focuses on modern application development through the practice of DevOps – a perfect fit for Kong’s service connectivity platform. Microservice architecture involves building software as suites of collaborating services.

A DMZ – Demilitarized Zone – is a military term, roughly summarized, as an area between two adversaries established as a buffer in order to reduce, or eliminate, the possibility of further conflict. In networking, the term usually refers to an area that acts as a buffer between two segregated networks. Here is a simplified visualization.

We are happy to announce release 2.2 of our flagship open source API gateway! Those were some busy three months since the release of Kong Gateway 2.1! We have pushed a number of patch releases in the 2.1 series, we’ve had our first fully-digital Kong Summit, and of course, we’ve been very busy building new features that are now shipping in Kong Gateway 2.2!

Kong Enterprise is a service connectivity platform that provides technology teams with the architectural freedom to build, operate, observe, and secure APIs and services anywhere. From Kong’s inception, we’ve been aligned with Amazon Web Services (AWS), enabling our customers to quickly and efficiently deploy Kong on their AWS accounts. As companies move from monolithic to microservice applications and beyond, Kong helps teams manage this transition.

Creating an API contract and corresponding Kong service are often just the first steps in the API development process. More often than not, the upstream services that are invoked provide a different contract to the one presented to the API consumer. This is especially the case in larger organizations where enterprise applications offer their own out-of-the-box integration contracts. Likewise, you shouldn’t expose the complexity of your upstream systems to your API consumer.

We are proud today to announce the future of service connectivity – Kong Konnect! Kong Konnect is the only full stack connectivity platform that is designed from the ground up for the cloud native era, delivered as a service. It accelerates the journey to microservices, secures and governs APIs and services, and it allows developers to rapidly design, publish and consume APIs and services. Konnect was built from the ground up with the unique needs of developers, architects and operators in mind.

About two and a half years ago, Kong first announced our Kubernetes Ingress Controller. We were stepping up to invest in the Kubernetes community by building a full-featured API gateway that operated in a Kubernetes-native way. Since then, we – as well as the rest of the broader Kubernetes ecosystem – have hit a number of additional milestones. Our Ingress Controller has run in tens of thousands of Kubernetes clusters, and we’ve continued to expand its functionality and stability.