Testing Kong containers with Testcontainers
In this week's Kong Builders, Viktor Gamov, Developer Advocate at Kong, will introduce Testcontainers.org and show you how to test your Kong declarative configurations in different scenarios.
Systems | Development | Analytics | API | Testing
Modern Software Development For Today's Systems & Applications
Kong
Kong Gateway 2.7 Is Here and Ready!
Today, we are welcoming another noteworthy advancement of the Kong Gateway – the general availability of version 2.7! Both Kong Gateway and Kong Gateway OSS version 2.7 downloads are available on your favorite distribution channels. This release of the Kong Gateway includes a number of important features that serve as a foundation for addressing three key areas.
How to Use Istio Ingress Gateway
In this video, @Viktor Gamov explains how Kong's new @Istio Ingress Gateway works and demos how to use it.
Kong Gateway User Meetup | December 2021 | Hackathon winner showcase - Rate limiting plugin
In this session, we welcome our Kong Summit Hackathon winner Narendra Patel, Sr. DevOps Engineer at Egnyte, to show off his Kong Gateway rate-limiting plugin, which allows you to rate-limit not just on the number of requests, but the bandwidth consumed too! Kong’s Online User Meetups are a place to learn about technologies within the Kong open source ecosystem. This interactive forum will give you the chance to ask our engineers questions and get ramped up on information relevant to your Kong journey.
Log4J, Log4Shell and Kong
If you’ve been online at all this week, chances are that you’ve heard about the Log4Shell zero-day (CVE-2021-44228) in Log4J, a popular Java logging library. The vulnerability enables Remote Code Execution (RCE), which allows attackers to run arbitrary code on the target’s machines. I know the first question that you all have is: “Is Kong affected by Log4Shell?” Let’s start with the good news: No Kong products are affected by this Log4J vulnerability.
What Does a Service Mesh Do?
In this episode of Kongcast, I spoke with Scott Lowe, principal field engineer at Kong, about what a service mesh does and when to use it, among other common mesh-related questions. Check out the transcript and video from our conversation below, and be sure to subscribe to get email alerts for the latest new episodes.
Building Smart O11y for Kuma With Elastic Observability
This blog was co-created by Ricardo Ferreira (Elastic) and Viktor Gamov (Kong). We love our microservices, but without a proper observability (O11y) strategy, they can quickly become cold, dark places cluttered with broken or unknown features. O11y is one of those technologies deemed created by causation: the only reason it exists is that other technologies pushed for it. There wouldn’t be need for O11y if, for example, our technologies haven’t gotten so complex across the years.
Using Elastic ML to Observe Your Kuma API Observability Metrics
Observability is catching on these days as the de-facto way to provide visibility into essential aspects of systems. It would be unwise for you not to leverage it with Kuma service mesh — the place that allows your services to communicate with the rest of the world. However, many observability solutions restrict themselves to the works: simple metric collection that provides them with dashboards. Expecting users to simply sit on their chairs and look at those metrics all day long is an invitation to failure, as we know that one can only do so much when they get tired and bored.
What a Service Mesh Does With Scott Lowe | Kongcast Episode 6
In this Kongcast episode, Scott Lowe, principal field engineer at Kong, takes us back to basics by answering what a service mesh does and when to use a service mesh, among other common mesh-related questions.
Building With Insomnia as a REST API Client
As more companies invest in a cloud native infrastructure, they’re choosing to prioritize their applications as microservices—architecting them into distinct servers. Each component is responsible for one (and only one) feature. For example, you might have Server A responsible for handling billing logic, Server B for handling user interaction and Server C for handling third-party user interactions.