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”
Odo 2.0 introduces a configuration file named
devfile.yaml. Odo uses this configuration file to set up cloud-native projects and determine the actions required for events such as building, running, and debugging a project. If you are an Eclipse Che user,
devfile.yaml should sound familiar: Eclipse Che uses devfiles to express developer workspaces, and they have proven to be flexible to accommodate a variety of needs.
Continue reading Developing your own custom devfiles for odo 2.0
In this article, you will learn how to use Debezium with Apache Avro and Apicurio Registry to efficiently monitor change events in a MySQL database. We will set up and run a demonstration using Apache Avro rather than the default JSON converter for Debezium serialization. We will use Apache Avro with the Apicurio service registry to externalize Debezium’s event data schema and reduce the payload of captured events.
Continue reading Debezium serialization with Apache Avro and Apicurio Registry
This article introduces new storage installation options and features in the Red Hat Integration service registry. The service registry component is based on Apicurio. You can use it to store and retrieve service artifacts such as OpenAPI specifications and AsyncAPI definitions, and for schemas such as Apache Avro, JSON, and Google Protobuf. We’ve provided Red Hat Integration’s Service Registry 1.1 component as a general availability (GA) release in Red Hat Integration 2020-Q4.
Continue reading New features and storage options in Red Hat Integration Service Registry 1.1 GA
Red Hat Process Automation Manager 7.9 brings bug fixes, performance improvements, and new features for process and case management, business and decision automation, and business optimization. This article introduces you to Process Automation Manager’s out-of-the-box integration with Apache Kafka, revamped business automation management capabilities, and support for multiple decision requirements diagrams (DRDs). I will also guide you through setting up and using the new
drools-metric module for analyzing business rules performance, and I’ll briefly touch on Spring Boot integration in Process Automation Manager 7.9.
Continue reading Red Hat Process Automation Manager 7.9 brings Apache Kafka integration and more
Serverless workflows have gained renewed interest and usefulness with the rise of serverless architectures. Once seen as centralized and monolithic, they now play a key role in cloud-based event and service orchestration. Until recently, there was no vendor-neutral way to describe service orchestration, so developers were dependent on vendors and vendor implementations. We realized that we needed a common, standards-based language for describing serverless workflows.
Continue reading Orchestrate event-driven, distributed services with Serverless Workflow and Kubernetes
Red Hat OpenShift 4.6 streamlines developer onboarding in the OpenShift web console, but that’s not all. This article details improvements and new features in the topology view and introduces OpenShift’s new, form-based approach to creating horizontal pod autoscalers and Helm charts. I also touch on application monitoring improvements and the latest updates for Red Hat OpenShift Pipelines, Red Hat OpenShift Serverless, and the Kiali Operator in OpenShift 4.6.
Note: This article presents an overview of what’s new in OpenShift 4.6. See the video at the end of the article for a guide to accessing and using the new features in the OpenShift web console.
Continue reading “More for developers in the new Red Hat OpenShift 4.6 web console”