Service Mesh

Metrics and traces correlation in Kiali

Metrics and traces correlation in Kiali

Metrics, traces, and logs might be the Three Pillars of Observability, as you’ve certainly already heard. This mantra helps us focus our mindset around observability, but it is not a religion. “There is so much more data that can help us have insight into our running systems,” said Frederic Branczyk at KubeCon last year.

These three kind of signals do have their specificities, but they also have common denominators that we can generalize. They could all appear on a virtual timeline and they all originate from a workload, so they are timed and sourced, which is a good start for enabling correlation. If there’s anything as important as knowing the signals that a system can emit, it’s knowing the relationships between those signals and being able to correlate one with another, even when they’re not strictly of the same nature. Ultimately, we can postulate that any sort of signal that is timed and sourced is a good candidate for correlation as well, even if we don’t have hard links between them.

Continue reading “Metrics and traces correlation in Kiali”

Share
Installing Kubeflow v0.7 on OpenShift 4.2

Installing Kubeflow v0.7 on OpenShift 4.2

As part of the Open Data Hub project, we see potential and value in the Kubeflow project, so we dedicated our efforts to enable Kubeflow on Red Hat OpenShift. We decided to use Kubeflow 0.7 as that was the latest released version at the time this work began. The work included adding new installation scripts that provide all of the necessary changes such as permissions for service accounts to run on OpenShift.

Continue reading Installing Kubeflow v0.7 on OpenShift 4.2

Share
Move your APIs into the serverless era with Camel K and Knative

Move your APIs into the serverless era with Camel K and Knative

In the past few years, developers have addressed the challenge of evolving from monolith systems to microservices architecture. These days, we hear about the adoption of serverless systems.

Like many trends in software, there’s no one clear view of how to define serverless or how this approach offers added value for our software architecture. The perfect place to start with serverless systems and discover serverless capabilities is through a use case.

Continue reading “Move your APIs into the serverless era with Camel K and Knative”

Share
DevNation Live Bengaluru: Sail into cloud — An introduction to Istio

DevNation Live Bengaluru: Sail into cloud — An introduction to Istio

Our first DevNation Live regional event was held in Bengaluru, India in July. This free technology event focused on open source innovations, with sessions presented by elite Red Hat technologists.

In this session, Kamesh Sampath provides an overview of Envoy and Istio, two open source projects that will change the way you write cloud-native Java applications on Kubernetes. We’ll show how to download and set up Istio on your local laptop, then deploy Java microservices as part of the Istio service mesh with Istio sidecar proxy.

Continue reading “DevNation Live Bengaluru: Sail into cloud — An introduction to Istio”

Share
Looking up a hash table library for caching in the 3scale Istio adapter

Looking up a hash table library for caching in the 3scale Istio adapter

You have probably already heard about the service mesh concept and one of its leading implementations, Istio. In the 3scale engineering team at Red Hat, we are working on a component to extend the functionality of Istio (and Red Hat’s distribution, Maistra) by integrating some API Management features via the 3scale platform. In this article, I’ll describe this work and some of the decisions made along the way.

Continue reading “Looking up a hash table library for caching in the 3scale Istio adapter”

Share
Manage your APIs deployed with Istio service mesh

Manage your APIs deployed with Istio service mesh

With the rise of microservices architectures, companies are looking for a way to connect, secure, control, and observe their microservices. Currently, a service mesh such as Istio is the best option to reach this goal.

  • Connect: Istio can intelligently control the flow of traffic between services, conduct a range of tests and upgrade gradually with blue/green deployments.
  • Secure: Automatically secure your services through managed authentication, authorization, and encryption of communication between services.
  • Control: Apply policies and ensure that they are enforced and that resources are fairly distributed among consumers.
  • Observe: See what’s happening with rich automatic tracing, monitoring, logging of all your services.

And, as explained in “Distributed microservices architecture: Istio, managed API gateways and, enterprise integration”, a service mesh does not relieve the need for an API management solution. A service mesh manages services and the connections between them, whereas an API management solution manages APIs and their consumers. In this article, I’ll describe how to manage APIs using the Red Hat Integration adapter for Istio.

Continue reading “Manage your APIs deployed with Istio service mesh”

Share
Distributed microservices architecture: Istio, managed API gateways and, enterprise integration

Distributed microservices architecture: Istio, managed API gateways and, enterprise integration

The rise of microservices architectures drastically changed the software development landscape. In the past few years, we have seen a shift from centralized monoliths to distributed computing that benefits from cloud infrastructure. With distributed deployments, the adoption of microservices, and system scaling to cloud levels, new problems emerged, as well as new components that tried to solve the problems.

By now, you most likely have heard that the service mesh or Istio is here to save the day. However, you might be wondering how it fits with your current enterprise integration investments and API management initiatives. That is what I discuss in this article.

Continue reading “Distributed microservices architecture: Istio, managed API gateways and, enterprise integration”

Share
Solving the challenges of debugging microservices on a container platform

Solving the challenges of debugging microservices on a container platform

Microservices have become mainstream in the enterprise. This proliferation of microservices applications generates new problems, which requires a new approach to managing problems. A microservice is a small, independently deployable, and independently scalable software service that is designed to encapsulate a specific semantic function in the larger applicationl. This article explores several approaches to deploying tools to debug microservices applications on a Kubernetes platform like Red Hat OpenShift, including OpenTracing,  Squash, Telepresence, and creating a Squash Operator in Red Hat Ansible Automation.

Continue reading “Solving the challenges of debugging microservices on a container platform”

Share
Observe what your Istio microservices mesh is doing with Kiali

Observe what your Istio microservices mesh is doing with Kiali

The Istio service mesh is a powerful tool for building a service mesh. If you don’t know about Istio yet, have a look at the Introduction to Istio series of articles or download the ebook Introducing Istio Service Mesh for Microservices.

The power of Istio comes with the cost of some complexity at configuration and runtime. To help this, the Kiali project provides observability of the mesh and the services in the mesh. Kiali visualizes the mesh with its services and workloads. It indicates the health of the mesh and shows hints about applied configuration options. You can then drill in on individual services or settings to view details.

This post describes how to use Kiali to observe what the microservices in your Istio service mesh are doing, validate the Istio configuration, and see any issues.

Continue reading “Observe what your Istio microservices mesh is doing with Kiali”

Share
Building Container-Native Node.js Applications with Red Hat OpenShift Application Runtimes and Istio

Building Container-Native Node.js Applications with Red Hat OpenShift Application Runtimes and Istio

For developers working on a Kubernetes-based application environment such as Red Hat OpenShift, there are a number things that need to be considered to fully take advantage of the significant benefits provided by these technologies, including:

  • How do I communicate with the orchestration layer to indicate the application is operating correctly and is available to receive traffic?
  • What happens if the application detects a system fault, and how does the application relay this to the orchestration layer?
  • How can I accurately trace traffic flow between my applications in order to identify potential bottlenecks?
  • What tools can I use to easily deploy my updated application as part of my standard toolchain?
  • What happens if I introduce a network fault between my services, and how do I test this scenario?

These questions are central to building container-native solutions. At Red Hat, we define container-native as applications that conform to the following key tenets:

  • DevOps automation
  • Single concern principle
  • Service discovery
  • High observability
  • Lifecycle conformance
  • Runtime confinement
  • Process disposability
  • Image immutability

This may seem like a lot of overhead on top of the core application logic. Red Hat OpenShift Application Runtimes (RHOAR) and Istio provide developers with tools to adhere to these principles with minimal overhead in terms of coding and implementation.

In this blog post, we’re specifically focusing on how RHOAR and Istio combine to provide tools for DevOps automation, lifecycle conformance, high observability, and runtime confinement.

Continue reading “Building Container-Native Node.js Applications with Red Hat OpenShift Application Runtimes and Istio”

Share