Apicurio Registry is the upstream project for Red Hat Integration’s Service Registry component. Developers use Apicurio Registry to manage artifacts like API definitions and data structure schemas.
Continue reading Testing Apicurio Registry’s performance and scalability
The Kamelet is a concept introduced near the end of 2020 by Camel K to simplify the design of complex system integrations. If you’re familiar with the Camel ecosystem, you know that Camel offers many components for integrating existing systems. An integration’s granularity is related to its low-level components, however. With Kamelets you can reason at a higher level of abstraction than with Camel alone.
A Kamelet is a document specifying an integration flow. A Kamelet uses Camel components and enterprise integration patterns (EIPs) to describe a system’s behavior. You can reuse a Kamelet abstraction in any integration on top of a Kubernetes cluster. You can use any of Camel’s domain-specific languages (DSLs) to write a Kamelet, but the most natural choice is the YAML DSL. The YAML DSL is designed to specify input and output formats, so any integration developer knows beforehand what kind of data to expect.
A Kamelet also serves as a source or sink of events, making Kamelets the building blocks of an event-driven architecture. Later in the article, I will introduce the concept of source and sink events and how to use them in an event-driven architecture with Kamelets.
Continue reading “Design event-driven integrations with Kamelets and Camel K”
Any developer knows that when we talk about integration, we can mean many different concepts and architecture components. Integration can start with the API gateway and extend to events, data transfer, data transformation, and so on. It is easy to lose sight of what technologies are available to help you solve various business problems. Red Hat Integration‘s Q1 release introduces a new feature that targets this challenge: the Red Hat Integration Operator.
Continue reading Deploy integration components easily with the Red Hat Integration Operator
This article gives an overview of the new Red Hat Integration Debezium connectors and features included in Debezium 1.4’s general availability (GA) release. Developers now have two more options for streaming data to Apache Kafka from their datastores and a supported integration to handle data schemas.
Continue reading Db2 and Oracle connectors coming to Debezium 1.4 GA
In today’s world of serverless functions and microservices, events are everywhere. The problem is that they are described differently depending on the producer technology you use.
One of an API management platform’s core functionalities is defining and enforcing policies, business domain rate limits, and pricing rules for securing API endpoints. As an API provider, you sometimes need to make the same backend API available for different consumer segments using these terms. In this article, you will learn about using Red Hat 3scale API Management to package APIs for different consumers, including internal and external developers and strategic partners. See the end of the article for a video tutorial that guides you through using 3scale API Management to create and configure the packages that you will learn about in this article.
Continue reading Packaging APIs for consumers with Red Hat 3scale API Management
API management platforms such as Red Hat 3scale API Management provide an API gateway as a reverse proxy between API requests and responses. In this stage, most API management platforms optimize the request-response pathway and avoid introducing complex processing and delays. Such platforms provide minimal policy enforcement such as authentication, authorization, and rate-limiting. With the proliferation of API-based integrations, however, customers are demanding more fine-tuned capabilities.
Continue reading Custom policies in Red Hat 3scale API Management, Part 1: Overview
Most of the new cloud-native applications and microservices designs are based on event-driven architecture (EDA), responding to real-time information by sending and receiving information about individual events. This kind of architecture relies on asynchronous, non-blocking communication between event producers and consumers through an event streaming backbone such as Red Hat AMQ Streams running on top of Red Hat OpenShift. In scenarios where many different events are being managed, defining a governance model where each event is defined as an API is critical. That way, producers and consumers can produce and consume checked and validated events. We can use a service registry as a datastore for events defined as APIs.
From my field experience working with many clients, I’ve found the most typical architecture consists of the following components:
In this article, you will learn how to easily integrate your Spring Boot applications with Red Hat Integration Service Registry, which is based on the open source Apicurio Registry.
Continue reading “Integrating Spring Boot with Red Hat Integration Service Registry”