Kong Enterprise provides customers with the fastest, most scalable and flexible API management solution in the market. One of Kong’s main advantages is the ability to quickly deploy and integrate with a customer’s ecosystem of already-deployed solutions for identity management and monitoring. As customers choose Kong to drive the decentralization of their applications, it’s critical to empower teams for end-to-end deployment while maintaining security and compliance.

A year ago, Harry Bagdi wrote an amazingly helpful blog post on observability for microservices. And by comparing titles, it becomes obvious that my blog post draws inspiration from his work. To be honest, that statement on drawing inspiration from Harry extends well beyond this one blog post – but enough about that magnificent man and more on why I chose to revisit his blog. When he published it, our company was doing an amazing job at one thing: API gateways.

We built Kong to handle any API at any level of scale, but running APIs at scale means storing and managing data at scale. That’s why we’ve always recommended Apache Cassandra for the biggest Kong deployments. Cassandra is powerful and proven, but it does require some skill to install and operate – which is why we’re excited to hear that Datastax is making Cassandra easy to use at any level of scale with DataStax Astra, a Database-as-a-Service built on Apache Cassandra.

We are very proud to announce some very important community updates for Kuma, with the goal of making Kuma more open and more inclusive to the broader open source ecosystem: The Kuma project now ships with open governance guidelines! This makes Kuma the only Envoy-based control plane for service mesh with an open governance policy in the CNCF landscape.

We are pleased to announce the next release of our flagship enterprise offering, Kong Enterprise 1.5! This follow-up release adds additional stability and features on top of our last major release, Kong Enterprise 1.3, which we announced at Kong Summit 2019. Kong Enterprise 1.5 key features include Kong Immunity Consumer Alerts, OIDC improvements, and Kong Developer Portal Application Registration. There are also several smaller features and stability improvements packaged here.

Kong for Kubernetes is a Kubernetes Ingress Controller based on the Kong Gateway open source project. Kong for K8s is fully Kubernetes-native and provides enhanced API management capabilities. From an architectural perspective, Kong for K8s consists of two parts: A Kubernetes controller, which manages the state of Kong for K8S ingress configuration, and the Kong Gateway, which processes and manages incoming API requests.

When protecting your online services, the weakest link is represented by the endpoints – that is, by the end-user devices running web or mobile applications or by external systems leveraging open APIs. As a matter of fact, there is a growing number of targeted attacks leveraging sophisticated techniques such as malicious web injections, mobile overlay and API abuse attacks to perform identity hijacking, account takeover, transaction tampering and payment frauds.

In his most recent blog post, Marco Palladino, our CTO and co-founder, went over the difference between API gateways and service mesh. I highly recommend reading his blog post to see how API management and service mesh are complementary patterns for different use cases, but to summarize in his words, “an API gateway and service mesh will be used simultaneously.” We maintain two open source projects that work flawlessly together to cover all the use cases you may encounter.

A modern API gateway like Kong enables organizations to achieve some use cases much more easily than traditional gateways. The reason is older, traditional gateways try to provide as many features as possible into a heavyweight monolith, while modern solutions use a best-in-breed approach. These traditional solutions not only try to be a gateway, but they also try to be a business intelligence system, a central logging hub, a monitoring tool and so much more.

Let’s admit it – web services (SOAP) are here to stay for a few more years, and maybe for a long time in some places where there is no business incentive to rebuild them. However, with a decline in new SOAP web services and most applications moving to cloud native architectures, a common query is “how can we support legacy services while moving to microservices?”