ConSol is an IT consulting company. Enthusiasm for coding and hacking is what unites us. ConSol Labs is a technical playing field where we can share our Open Source involvement. We use this site to blog about our area of personal interest, from the daily business at work and from our spare time projects.
This blog will be continued on blog.consol.de.
Read great stories and news from our colleagues over there.
labs.consol.de will continue to host the OMD repository and static pages. Also
existing blog entries will stay here for archive reasons.
One of our customers is in the process of decommisioning their OpenShift v3.11 cluster. This cluster is currently still used for building customer specific base images. Over time quite a few elaborated pipeline builds (based on Jenkins) have been developed for that purpose.
The customer wanted me to migrate the existing pipeline builds on their v3.11 cluster to Tekton (aka OpenShift Pipeline) builds running on their new v4.9 cluster. This task turned out to be quite pesky. Tekton is a beast in many aspects.
The documentation of software is an everyday business of a software developer and engineer. Especially for integration scenarios a diagram on the flow of a message through the system or the whole landscape is an essential illustration. Fortunately there are standardised messaging patterns which can be used. Unfortunately, however, there is no tool which can create such visualizations out of the box directly of source code. In this article we will have a look at Apache Camel and how it is possible to get a graphical representation of an integration route. We will also discuss about debugging it, as some tools have the feature to do this.
Today software often needs to be run in cloud environments. Newly developed software, especially microservices are developed with cloud readiness in mind.
But we not only have microservices in business environments, we also have integration software. This type of software is developed and designed to connect external services to internal ones.
This article is the author’s opinion on similarities and differences between Streaming and Messaging.
The first time I was busy with the terms messaging and streaming was during my master thesis in 2016. Among other things, the thesis was about different strategies of microservices integration. During that time, the term messaging was popular. Moroever, Kafka, which is a streaming platform, was popular, too. From a high-level perspective, messaging, kafka and streaming seem to be the same thing… but I never understood, why we have these two terms which are used synonymously in many contexts: messaging and streaming. This article is my answer to that question.
Some time ago, I started a project to create a Helm based operator for an OpenShift application. I used the Operator SDK to create the Helm operator. The Operator SDK documentation describes the parameters pretty good, and it contains a simple tutorial. it does not, however, describe the complete development cycle. This article aims to describe everything from creating the operator to the point where you can upload your operator to OperatorHub.io. We start with a basic Helm Chart. With this, you can install Nginx as a StatefulSet. You can find the source code in my github repo. Before we can start with creating an operator, we need to fulfill some prerequisites.
The first version of RabbitMQ has been released in 2007. Back in these days, the goal was to provide a complete open source implementation of Advanced Message Queuing Protocol (AMQP), aiming at modern messaging needs such as high availability, high performance, scalability and security.
Nowadays, RabbitMQ is one of the most popular message brokers and can be found in several domains.
This article lights up core concepts and compares it with ActiveMQ Artemis and AWS SQS.
Last summer I watched the Red Hat master course about Kafka from Sébastien Blanc. The Kafka setup in Kubernetes presented in the course looked pretty easy. The Kafka client implementation for Java seemed to be easy as well. Furthermore, I wanted to use Kafka for a long time, so I got the idea to extend my Istio example. Each time a service is called, a message is sent to a topic. The service (implemented in Quarkus), as well as the Kafka cluster should be in an Istio Service Mesh and secured with mTLS. I found descriptions of Joel Takvorian that Kafka works with Istio, so I knew (or at least hoped) that my plan should work.
This article will describe the overall architecture of the example and which obstacles I encountered during deployment.
AWS Comprehend is a great tool when you want to extract information from textual data. As a managed service it is really easy to setup and can be used with next to no prior knowledge of machine learning. But there is one minor thing that bugs me about Comprehend: The Output.
TL;TR output.tar.gz bad, flat json file good.
See python code below for transformation.
Automatic integration tests as part of the development life cycle can save a lot of time and money. Not only when dealing with other service APIs or offering some, also if the application uses a database or other infrastructure services.
We at Consol made a lot of good experience to develop the integration tests as part of the life cycle from the beginning of a project. Therefor the Citrus framework is often a good choice to do it automated.
But there are other frameworks and libraries which can be useful. In this article, we’ll have a look at Testcontainers. By using a sample microservice, we will show how Testcontainers can be used and what chances it provides.