API-first design is a commonly used approach where you define the interfaces for your application before providing an actual implementation. This approach gives you a lot of benefits. For example, you can test whether your API has the right structure before investing a lot of time implementing it, and you can share your ideas with other teams early to get valuable feedback. Later in the process, delays in the back-end development will not affect front-end developers dependent on your service so much, because it’s easy to create mock implementations of a service from the API definition.
Much has been written about the benefits of API-first design, so this article will instead focus on how to efficiently take an OpenAPI definition and bring it into code with Red Hat Fuse.
Continue reading “API-first design with OpenAPI and Red Hat Fuse”
We are thrilled to announce an updated release of the data streaming component of our messaging suite, Red Hat AMQ streams 1.2, which is part of Red Hat integration.
Red Hat AMQ streams, based on the Apache Kafka project, offers a distributed backbone that allows microservices and other applications to share data with extremely high throughput and extremely low latency. AMQ streams makes running and managing Apache Kafka a Kubernetes-native experience, by additionally delivering Red Hat OpenShift Operators, a simplified and automated way to deploy, manage, upgrade and configure a Kafka ecosystem installation on Kubernetes.
Continue reading “Announcing Red Hat AMQ streams 1.2 with Apache Kafka 2.2 support”
Cloud-native environment architecture can be challenging to understand. To help make sense of it for application developers and software/system architects, I will attempt to explain the various parts and how they work together. Toward this end, I find it helpful to think about the architecture in four separate layers: application software development, service scaling, application network, and container orchestration platform.
In this article, I will describe the first technology layer: application software development. I drew the following diagram to make these concepts easier to visualize.
Continue reading “Introduction to cloud-native application environment architecture”
The release of Red Hat CodeReady Studio 12 brings with it more than a name change from Red Hat Developer Studio to Red Hat CodeReady Studio, but also some updates to the tools it includes. The focus here is not on the Red Hat CodeReady Workspaces, a cloud and container development experience, but on the locally installed CodeReady Studio.
Continue reading “How to set up Red Hat CodeReady Studio 12: Integration tooling”
Apache Camel development is improving on Eclipse Che 7 compared to Che 6. On Che 6, it is limited to XML DSL and without classical XSD-based XML support. With Che 7, Camel Java DSL is available and XSD-based XML support is working nicely with the Camel XML DSL support. Please note that Che 7 is still in beta.
Continue reading “Apache Camel development on Eclipse Che 7”
The integration space is in constant change. Many open source projects and closed source technologies did not withstand the tests of time and have disappeared from the middleware stacks for good. After a decade, however, Apache Camel is still here and becoming even stronger for the next decade of integration. In this article, I’ll provide some history of Camel and then describe two changes coming to Apache Camel now (and later to Red Hat Fuse) and why they are important for developers. I call these changes subsecond deployment and subsecond startup of Camel applications.
Continue reading “Subsecond deployment and startup of Apache Camel applications”
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”
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”
This article is the second in a series of three articles about Red Hat Integration. The first article described how the new Red Hat Integration bundle allows citizen integrators to quickly provide an API through tools that make creating an API in five simple steps effortless, and we implemented a demo showing the full API lifecycle on Red Hat Integration. The demo was about providing wine labeling and ranking info via APIs.
In this article, I am going to take you further by implementing a real business transaction with Salesforce. We will create an event-driven integration solution with no code on Red Hat Integration.
The idea of this demo is to receive an order from the client web application through a gated, secured API that will then process the order and forward the needed data to the corresponding Salesforce modules. From there, Salesforce will take care of the order content.
Continue reading “Full integration to Salesforce with Red Hat Integration (Part 2)”
Nowadays, API development with proper lifecycle management often takes days if not weeks to get a simple API service up and running. One of the main reasons behind this is there are always way too many parties involved in the process. Plus there are hours of development and configuration.
First, the system analysts negotiate the API interface with the API consumer; then the developer writes the actual API to implement the interface. They then pass the API on to the DevOps team that is in charge of deploying the API. And it is not done yet; then the deployment info needs to be passed to the operations team that is in charge of setting up the API endpoints in the management system and also applying the access policies.
The speed of providing managed API services can be one of the major factors in the success of a company’s business.
This article, which is the first in a series of three articles, describes how the new Red Hat Integration bundle allows citizen integrators to quickly provide an API through tools that make creating an API in five simple steps effortless.
Continue reading “Effortless API creation with full API lifecycle using Red Hat Integration (Part 1)”