Red Hat OpenShift API Management is a new managed application service designed as an add-on to Red Hat OpenShift Dedicated. The service provides developers with a streamlined experience when developing and delivering microservices applications with an API-first approach.
Continue reading Installing Red Hat OpenShift API Management
Recently I wrote about decoupling infrastructure code from microservices. I found that Apache Camel and Debezium provided the middleware I needed for that project, with minimal coding on my end. After my successful experiment, I wondered if it would be possible to orchestrate two or more similarly decoupled microservices into a new service–and could I do it without writing any code at all? I decided to find out.
This article is a quick dive into orchestrating microservices without writing any code. We will use Syndesis (an open source integration platform) as our orchestration platform. Note that the examples assume that you are familiar with Debezium and Kafka.
Continue reading “Low-code microservices orchestration with Syndesis”
As an architect in the Red Hat Consulting team, I’ve helped countless customers with their integration challenges over the last six years. Recently, I had a few consulting gigs around Red Hat AMQ 7 Broker (the enterprise version of Apache ActiveMQ Artemis), where the requirements and outcomes were similar. That similarity made me think that the whole requirement identification process and can be more structured and repeatable.
This guide is intended for sharing what I learned from these few gigs in an attempt to make the AMQ Broker architecting process, the resulting deployment topologies, and the expected effort more predictable—at least for the common use cases. As such, what follows will be useful for messaging and integration consultants and architects tasked with creating a messaging architecture for Apache Artemis, and other messaging solutions in general. This article focuses on Apache Artemis. It doesn’t cover Apache Kafka, Strimzi, Apache Qpid, EnMasse, or the EAP messaging system, which are all components of our Red Hat AMQ 7 product offering.
Continue reading “Architecting messaging solutions with Apache ActiveMQ Artemis”
The release of the latest Red Hat developer suite version 12 brings with it a name change from Red Hat JBoss Developer Studio to Red Hat CodeReady Studio. The focus here is not on the Red Hat CodeReady Workspaces, a cloud and container development experience, but on the locally installed developers studio.
The new release also brings with it the questions about how to get started with the various Red Hat integration, data, and process automation product toolsets that are not installed out of the box. This series of articles showcases how to install each set of tools and explains the products they are supporting. The hope is that an easy getting started experience will help you make informed decisions about the tooling that you might want to use on your next development project.
Continue reading “How to set up Red Hat CodeReady Studio 12: Integration tooling”
In Part 7 of this series, we looked at details that determine how your integration becomes the key to transforming your customer experience. It started with laying out the process of how I’ve approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural blueprint. Let’s continue looking at more specific examples of how these blueprints solve specific integration use cases.
Continue reading “Integration blueprint example for mobile integration (part 8)”
Working with Red Hat Fuse 7 on Spring Boot is straightforward. In my field experience, I have seen many development (a.k.a. integrator) teams moving to Fuse 7 on Spring Boot for their new integration platforms on Red Hat OpenShift Container Platform (well aligned with agile integration).
Lately, however, I have also seen some teams worried about the size of the final images and the deployment pipeline. In most cases, they had developed a set of common libraries or frameworks to extend or to homogenize the final integration projects. All the cases have the same result:
- Several dependencies copied in each integration project
- Always replacing the container images with the latest fat JAR (including the same dependencies) in each build pipeline
Spring Boot is usually packaged as “fat JARS” that contain all runtime dependencies. Although this is quite convenient, because you only need a JRE and a single JAR to run the application, in a container environment such as Red Hat OpenShift, you have to build a full container image to deploy your application.
Continue reading “Optimizing Red Hat Fuse 7 Spring Boot container images”
In Part 6 of this series, we looked into details that determine how your integration becomes the key to transforming your customer experience. It started with laying out the process of how I’ve approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural blueprint.
Having completed our discussions on the blueprint details, it’s time to look at a few specific examples. This article walks you through an example integration scenario showing how expanding the previously discussed details provides blueprints for your own integration scenarios.
Continue reading “Integration blueprint example for process automation (part 7)”
Red Hat Summit 2019 is rocking Boston, MA from May 7-9 in the Boston Convention and Exhibition Center. Everything you need to know about the current state of open source enterprise-ready software can be found at this event. From customers talking about their experiences leveraging open source in their solutions, to the creators of open source technologies you’re using, and all the way down to hands-on lab experiences on these technologies.
This hands-on appeal is what this series of articles is about. Previously, we looked at the labs in the Cloud-Native App Dev track, and this time, we provide a roadmap to the “Integration and APIs” lab content.
Continue reading “Red Hat Summit 2019 Labs: Integration and APIs roadmap”
In Part 5 this series, we looked into details that determine how your integration becomes the key to transforming your customer experience.
It started with laying out the process of how I’ve approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural blueprint. Now it’s time to cover various blueprint details.
This article covers the final elements in the blueprint, storage services, which are fundamental to the generic architectural overview.
Continue reading “Integration of storage services (part 6)”
In Part 4 of this series, we looked into details that determine how your integration becomes the key to transforming your omnichannel customer experience.
It started with laying out the process of how I’ve approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural blueprint. Now it’s time to cover more blueprint details.
This article discusses the core elements in the blueprint (container platform and microservices) that are crucial to the generic architectural overview.
Continue reading “Integration of container platform essentials (Part 5)”