In this blog post we’ll help answer the age old question, “What does this service talk to and what does it say?” We’ll see how to inspect inbound and outbound REST API calls to see what calls are being made and what incoming traffic causes a reaction. This can be pretty handy when you’re taking over maintenance of an existing service, or if your code just isn’t behaving the way you expect.
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.
Whether you're transitioning away from a monolith or building a green-field app, opting for a microservice architecture brings many benefits as well as certain challenges. These challenges include namely managing the network and maintaining observability in the microservice architecture. Enter the service mesh, a valuable component of modern cloud-native applications that handles inter-service communication and offers a solution to network management and microservice architecture visibility.
The more services you have running across different clouds and Kubernetes clusters, the harder it is to ensure that you have a central place to collect service mesh observability metrics. That’s one of the reasons we created Kuma, an open source control plane for service mesh. In this tutorial, I’ll show you how to set up and leverage the Traffic Metrics and Traffic Trace policies that Kuma provides out of the box. If you haven’t already, install Kuma and connect a service.
Optoro’s platform finds returned items a new home. Here’s how its data engineering team keeps mission-critical data flowing.
