Apache Camel K should be as lightweight as possible. Therefore, the Camel K project provides standalone Java files to describe a Camel integration. The downside to this practice is that existing IDEs cannot provide complete support out of the box. To provide a complete experience with Apache Camel K’s standalone Java files, there were three solutions:
As a result, there is no intuitive configuration. However, Red Hat’s Tooling for Apache Camel K offers a new possibility.
Continue reading “Camel K standalone Java file: Now with Java language support”
The Eclipse Che 7.6.0 release provides a new stack for Apache Camel K integration development. This release is the first iteration to give a preview of what is possible. If you like what you see, shout it out, and more will surely come.
This article details how to test this release on a local instance deployed on minikube. The difference with a hosted instance is that we avoid the prerequisites involving Camel K installation in the cluster and specific rights for the user.
Continue reading “Apache Camel K development inside Eclipse Che: Iteration 1”
The Red Hat Integration Q4 release adds many new features and capabilities with an increasing focus around cloud-native data integration. The features I’m most excited about are the introduction of the schema registry, the advancement of change data capture capabilities based on Debezium to technical preview, and data virtualization (technical preview) capabilities.
Data integration is a topic that has not received much attention from the cloud-native community so far, and we will cover it in more detail in future posts. Here, we jump straight into demonstrating the latest release of data virtualization (DV) capabilities on Red Hat OpenShift 4. This is a step-by-step visual tutorial describing how to create a simple virtual database using Red Hat Integration’s data virtualization Operator. By the end of the tutorial, you will learn:
- How to deploy the DV Operator.
- How to create a virtual database.
- How to access the virtual database.
The steps throughout this article work on any Openshift 4.x environment with operator support, even on time- and resource-constrained environments such as the Red Hat OpenShift Interactive Learning Portal.
Continue reading “First steps with the data virtualization Operator for Red Hat OpenShift”
With companies generating more and more revenue through their APIs, these APIs also have become even more critical. Quality and reliability are key goals sought by companies looking for large scale use of their APIs, and those goals are usually supported through well-crafted DevOps processes. Figures from the tech giants make us dizzy: Amazon is deploying code to production every 11.7 seconds, Netflix deploys thousands of time per day, and Fidelity saved $2.3 million per year with their new release framework. So, if you have APIs, you might want to deploy your API from a CI/CD pipeline.
Deploying your API from a CI/CD pipeline is a key activity of the “Full API Lifecycle Management.” Sitting between the “Implement” and “Secure” phases, the “Deploy” activity encompasses every process needed to bring the API from source code to the production environment. To be more specific, it covers Continuous Integration and Continuous Delivery.
Continue reading “5 principles for deploying your API from a CI/CD pipeline”
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”
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”
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)”
Microservices architecture is taking over software development discussions everywhere. More and more companies are adapting to develop microservices as the core of their new systems. However, when going beyond the “microservices 101” googled tutorial, required services communications become more and more complex. Scalable, distributed systems, container-native microservices, and serverless functions benefit from decoupled communications to access other dependent services. Asynchronous (non-blocking) direct or brokered interaction is usually referred to as messaging.
Continue reading “Announcing Kubernetes-native self-service messaging with Red Hat AMQ Online”
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)”