Jekyll2025-07-02T12:49:44+00:00http://blog.jromanmartin.io/feed.xmlRoman’s BlogMy personal blog about any kind of technical topics (integration, messaging, developing, ...). Roman Martin:tada: New article published in Red Hat Developer!2023-09-20T07:00:00+00:002023-09-20T07:00:00+00:00http://blog.jromanmartin.io/2023/09/20/new-article-rhdI am honored to announce that a new article from mine was published at Red Hat Developer community. The Automate your AMQ streams platform with Ansible describes how deploy Apache Kakfa clusters using the AMQ Streams Collection of the Ansible Middleware community.

This blog post is the result of my contributions and collaboration with this amazing community to automate the most tipical operations of an Apache Kafka cluster. The collection is under development but this post summarize the most important topics and shows an example of the most tipical deployment topology of an Apache Kafka cluster.

I would like to thank Romain Pelisse who helped me a lot in my contributions, testing my implementations, and teaching me a lot of great things about Ansible.

I hope this new article helps you when you need to automate your Apache Kafka cluster on RHEL/Fedora environments.

My full list of articles are available for your records here. As usual, comments, ideas, PRs are welcomed!

Happy coding !!! πŸ’»πŸ’ΎπŸ’Ώβ˜•

]]>Roman MartinπŸ“› Improving a GitHub Repo (II)!2023-06-20T07:00:00+00:002023-06-20T07:00:00+00:00http://blog.jromanmartin.io/2023/06/20/Improving-a-gh-repository-iiMy first post of πŸ“› Improving a GitHub Repo describes many good things to add in any GitHub repository to be more productive and professional. However, that stuff can be hard to do every time a new repository is created, and we can forget to add something great. I found a way to accelerate this process and also do not forget to add anything great: GitHub Repository templates.

GitHub template repository is the best way to replicate an standard structure, including folders, documentation, workflows, branches, and any file required to set up a new project. Using this pattern we can homogenize the structure of any repository of your organization, or also your own projects, easily and saving a lot of time. If you need to standardize your projects, or you need to create many projects on demand, definitely a template repository is your tool.

As summary, the most great benefits of using repository template I found are:

  • βŒ› Spend less time repeating code
  • 🌟 Focus on building new things
  • 🦾 Less manual configuration
  • πŸ“ Sharing boilerplate code across the code base

And, the main features of a repository template are:

  • Copy the entire repository files to a brand new repository
  • Every template has a new url endpoint called /generate
  • Share repository template through your organization or other GitHub users

My own repository template

I create mw own GitHub Template repository in here: https://github.com/rmarting/gh-repo-template including all the things described in my previous post, or new things added along the time.

My template repository includes things such as:

  • Initial content files aligned with the common patterns in any Open Source project: Contribution guide, Code of Conduct, contributors, …
  • GitHub templates to report issues or open Pull Requests.
  • Standard badges to summarize the repository.
  • Standard workflows to release versions, or to implement Continuous Integration pipelines

So, creating a new repository and setting up it takes few seconds and steps. Amazing!!!

Do you have ideas, or comments about how to improve a template repository? Looking forward to hearing you with more contributions into my template repo, or adding comments in this post.

πŸ€–πŸš© Happy creation of new projects!!! πŸ€–πŸš©

]]>Roman MartinπŸ–­ How to resize a virtual disk2023-06-16T07:00:00+00:002023-06-16T07:00:00+00:00http://blog.jromanmartin.io/2023/06/16/how-resize-virtual-disk-imageIf you work with VMs it is very common that sometimes you need more space, but your VMs were defined with an estimated size. I started to use Virtual Machine Manager to manage my VMs when I joined to Red Hat (sorry but in my previous life I usually used Oracle VM VirtualBox) and sometimes I need to resize my image files but I didn’t know how to do it.

Thanks to Oscar Arribas Arribas I learned to do it using a few virt-xxx commands. It is very possible to do it using other commands/steps/alternatives however this way is good for me.

Step 0️⃣ - Checking current VM disk size

Inside of your VM you can check the size of the each disk with the df command:

[rhmw@f38mw01 ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           977M     0  977M   0% /dev/shm
tmpfs           391M  1.3M  390M   1% /run
/dev/vda3        19G  4.7G   14G  26% /
tmpfs           977M   40K  977M   1% /tmp
/dev/vda3        19G  4.7G   14G  26% /home
/dev/vda2       974M  257M  650M  29% /boot
tmpfs           196M   56K  196M   1% /run/user/42
tmpfs           196M   40K  196M   1% /run/user/1000

Here the home has 20G allocated. I would like to extend it to 40G.

Step 1️⃣ - Creating a new disk image

Your VM must be stopped before starting to resize it using a new disk image with the desired size.

We can create a new disk using the qemu-img tool, something like this:

on 🎩 ❯ qemu-img create -f qcow2 f38mw01-resized.qcow2 40G
Formatting 'f38mw01-resized.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=42949672960 lazy_refcounts=off refcount_bits=16

Or creating the new image file by the Storage tab in the virt-manager Connection Details option (Edit -> Connection Details):

Step 2️⃣ - Renaming the old disk image

Rename the old image file as a backup file (it could be needed to use in a roll-back case):

mv f38mw01.qcow2 f38mw01.qcow2.backup

You can also describe the file systems in the old image file:

on 🎩 ❯ sudo virt-filesystems --long -h --all -a f38mw01.qcow2.backup
Name                                     Type       VFS     Label                 MBR Size Parent
/dev/sda1                                filesystem unknown -                     -   1.0M -
/dev/sda2                                filesystem ext4    -                     -   973M -
/dev/sda3                                filesystem btrfs   fedora_localhost-live -   19G  -
btrfsvol:/dev/sda3/home                  filesystem btrfs   fedora_localhost-live -   -    -
btrfsvol:/dev/sda3/root                  filesystem btrfs   fedora_localhost-live -   -    -
btrfsvol:/dev/sda3/root/var/lib/machines filesystem btrfs   fedora_localhost-live -   -    -
/dev/sda1                                partition  -       -                     -   1.0M /dev/sda
/dev/sda2                                partition  -       -                     -   1.0G /dev/sda
/dev/sda3                                partition  -       -                     -   19G  /dev/sda
/dev/sda                                 device     -       -                     -   20G  -

Step 3️⃣ - Truncating the new disk image

Truncate the old image file and resize the new image file with the new space:

on 🎩 ❯ sudo truncate -r f38mw01.qcow2.backup f38mw01-resized.qcow2
on 🎩 ❯ sudo truncate -s +20G f38mw01-resized.qcow2

Step 4️⃣ - Expanding the new disk image

Expand the new image file using as base the old image file. In this step I am expanding the physical disk mounted for the home folder.

on 🎩 ❯ sudo virt-resize --expand /dev/sda3 f38mw01.qcow2.backup f38mw01-resized.qcow2
[   0.0] Examining f38mw01.qcow2.backup
**********

Summary of changes:

virt-resize: /dev/sda1: This partition will be left alone.

virt-resize: /dev/sda2: This partition will be left alone.

virt-resize: /dev/sda3: This partition will be resized from 19.0G to 39.0G. 
 The filesystem btrfs on /dev/sda3 will be expanded using the 
β€˜btrfs-filesystem-resize’ method.

**********
[   2.6] Setting up initial partition table on f38mw01-resized.qcow2
[  13.4] Copying /dev/sda1
[  13.4] Copying /dev/sda2
 100% βŸ¦β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’βŸ§ --:--
[  15.8] Copying /dev/sda3
 100% βŸ¦β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’βŸ§ 00:00
[  48.0] Expanding /dev/sda3 using the β€˜btrfs-filesystem-resize’ method

virt-resize: Resize operation completed with no errors.  Before deleting 
the old disk, carefully check that the resized disk boots and works 
correctly.

Step 5️⃣ - Starting the VM with the new disk image

Rename the new disk image as the original one used by the VM:

on 🎩 ❯ mv f38mw01-resized.qcow2 f38mw01.qcow2

Start the VM and the check that our home has more space:

[rhmw@f38mw01 ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           977M     0  977M   0% /dev/shm
tmpfs           391M  1.3M  390M   1% /run
/dev/vda3        39G  4.7G   34G  13% /
tmpfs           977M   40K  977M   1% /tmp
/dev/vda2       974M  257M  650M  29% /boot
/dev/vda3        39G  4.7G   34G  13% /home
tmpfs           196M   56K  196M   1% /run/user/42
tmpfs           196M   40K  196M   1% /run/user/1000

The /dev/vda3 now is 34G (in the step 0, the size was 19G). Great!!!

Bonus Track πŸ’‘ - Resizing Microsoft Windows VMs

I know, I know what you are thinking πŸ€” … this stuff works because I am using a Linux OS πŸ˜‡. However, this process also works for Windows VMs.

Here an example of a Windows 10 with a hard disk of 40G to extend to 50G:

The process is exactly the same:

Create new disk image:

on 🎩 ❯ qemu-img create -f qcow2 win10-resized.qcow2 50G
Formatting 'win10-resized.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=53687091200 lazy_refcounts=off refcount_bits=16

Back the original disk image:

on 🎩 ❯ mv win10.qcow2 win10.qcow2.backup

Check the file systems of the old image:

on 🎩 ❯ sudo virt-filesystems --long -h --all -a win10.qcow2.backup 
Name       Type        VFS   Label            MBR  Size  Parent
/dev/sda1  filesystem  ntfs  System Reserved  -    579M  -
/dev/sda2  filesystem  ntfs  -                -    39G   -
/dev/sda1  partition   -     -                07   579M  /dev/sda
/dev/sda2  partition   -     -                07   39G   /dev/sda
/dev/sda   device      -     -                -    40G   -

Truncate the new disk image:

on 🎩 ❯ sudo truncate -r win10.qcow2.backup win10-resized.qcow2 
on 🎩 ❯ sudo truncate -s +10G win10-resized.qcow2

Expand the new disk image:

on 🎩 ❯ sudo virt-resize --expand /dev/sda2 win10.qcow2.backup win10-resized.qcow2 
[   0.0] Examining win10.qcow2.backup
**********

Summary of changes:

virt-resize: /dev/sda1: This partition will be left alone.

virt-resize: /dev/sda2: This partition will be resized from 39.4G to 49.4G. 
 The filesystem ntfs on /dev/sda2 will be expanded using the 
β€˜ntfsresize’ method.

**********
[   1.9] Setting up initial partition table on win10-resized.qcow2
[   2.8] Copying /dev/sda1
[   3.6] Copying /dev/sda2
 100% βŸ¦β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’β–’βŸ§ 00:00
[  55.7] Expanding /dev/sda2 using the β€˜ntfsresize’ method

virt-resize: Resize operation completed with no errors.  Before deleting 
the old disk, carefully check that the resized disk boots and works 
correctly.

Rename the new disk using the original name

on 🎩 ❯ mv win10-resized.qcow2 win10.qcow2

Start the VM and check the new disk size:

🚩 Happy resizing!!! πŸ€–

]]>Roman MartinπŸ“› Improving a GitHub Repo!2023-06-12T07:00:00+00:002023-06-12T07:00:00+00:00http://blog.jromanmartin.io/2023/06/12/Improving-a-gh-repositoryI have been using GitHub for a long time and I spent time on a daily basis reviewing repos in the Open Source space. One of the most important things , from my point of view, is to get a good overview of the repository, a good documentation, but also good highlights, such as releases, status of the project, Changelogs, Contribution Guides, emojis (why not?) … so I can get faster a good summary of the repository. This is not easy and there are many different ways to do it, but I found some of them very easy to add in any repository.

This post covers two of these mechanisms to improve any GitHub Repository:

  • πŸ“› Repository Badges
  • βœ… Changelogs and πŸ€–πŸš©automatic releasing process

πŸ“› Repository Badges

How does it look like a repo with badges? Something like this:

Nice 🫢, right?

Badges are an easy way to summarize a repo with information about topics such as building, test results, license, pipelines or workflows, versions, … This information provides quality metadata coming from many different resources. So meanwhile you are browsing, you get all this information in a single view. Incredible!

I found a simple way to integrate almost any badge in my repository … Shields.io. It is a service providing badges in different formats to integrate in GitHub readme files. This service supports a bunch of continuous integration services, package registries, distributions, app stores, social networks, code coverage services, and code analysis services (anything else? πŸ€·πŸ½β€β™€οΈ).

In short, using the web site you can customize your badge to your own requisites and 3rd party services, getting a code to add in your GitHub readme easily.

For example, the previous image is rendered using the next entries in my readme file of my Blog site repository:

![License](https://img.shields.io/github/license/rmarting/rmarting.github.io?style=plastic)
![Main Lang](https://img.shields.io/github/languages/top/rmarting/rmarting.github.io)
![Languages](https://img.shields.io/github/languages/count/rmarting/rmarting.github.io)
![Last Commit](https://img.shields.io/github/last-commit/rmarting/rmarting.github.io)

Easy βœ…, and powerful πŸ’ͺ! So, don’t forget to add your badges in your repo to help me, and others πŸ€—!

βœ… Changelogs and πŸ€–πŸš©automatic releasing process

Changelog, as a comprehensive and up-to-date file, is crucial for effective project management and collaboration. A changelog serves as a documented record of all the notable changes, enhancements, and bug fixes made to your software over time. It not only provides transparency and accountability but also facilitates communication among team members and external contributors. This file enables users and developers to easily track the evolution of the project, understand the latest features and improvements, and quickly identify any potential issues or compatibility concerns.

Getting all these benefits require a regular updating of that file, usually after releasing a new version or iteration of our software. But, how to track all the changes between versions? Who should do it? When? … It seems that it could be tedious every time if we have to do it manually … we can forget something to add, or we can forget to update it at all.

As fan of …

There is a way to automatically update the changelog file every time a new version is released. This blog post summarizes this process.

Step 1️⃣ - Create your Changelog file

Create a file, usually called CHANGELOG.md, with the following content:

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

To delve deeper into the significance of changelog files and learn about best practices for creating and maintaining them, I recommend checking out Keep a Changelog. This resource offers a comprehensive guide and industry-accepted standards for crafting informative and well-structured changelogs.

Step 2️⃣ - Use a Release workflow to publish new releases

The Release Drafter GitHub Action is an incredible GitHub action to automate a new release of the repository. The action is initially designed to draft a new release, but it is also valid to release automatically the version. In my case, I will automatically release the version as soon as a new tag is pushed.

The following release-drafter.yml file inside of the .github/workflows folder will publish a new release after a new tag is pushed into the repository. The tag must be aligned with the Semantic Versioning:

name: πŸ”– Release Drafter πŸ”–

on:
  push:
    tags:
      - v[0-9]+.[0-9]+.[0-9]+

permissions:
  contents: read
      
jobs:
  update_release_draft:
    name: Release drafter
    runs-on: ubuntu-latest
    permissions:
      # write permission is required to create a github release
      contents: write

    steps:
      - name: Update Release Draft
        uses: release-drafter/release-drafter@v5
        with:
          publish: true
          prerelease: false
        env:
          # Instead of GITHUB_TOKEN Ref: https://github.com/stefanzweifel/changelog-updater-action/discussions/30
          GITHUB_TOKEN: $

The publish: true attribute publishes the release as final, just because the prerelease attribute is marked as false.

Step 3️⃣ - Format the Release content

The content of the release will include information coming from the different pull request, issues, and commits. This information can be included automatically into the release notes using different patterns. These patterns are described in the release-drafter.yml file inside .github folder:

The following example is a full example using different categories of information to add into the release notes.

# This release drafter follows the conventions from https://keepachangelog.com

name-template: 'v$RESOLVED_VERSION'
tag-template: 'v$RESOLVED_VERSION'
template: |
  ## What Changed πŸ‘€
  
  $CHANGES

  **Full Changelog**: https://github.com/$OWNER/$REPOSITORY/compare/$PREVIOUS_TAG...v$RESOLVED_VERSION
categories:
  - title: πŸš€ Features
    labels:
      - feature
      - enhancement
  - title: πŸ› Bug Fixes
    labels:
      - fix
      - bug
  - title: ⚠️ Changes
    labels:
      - changed
  - title: ⛔️ Deprecated
    labels:
      - deprecated
  - title: πŸ—‘ Removed
    labels:
      - removed
  - title: πŸ” Security
    labels:
      - security
  - title: πŸ“„ Documentation
    labels:
      - docs
      - documentation      
  - title: 🧩 Dependency Updates
    labels:
      - deps
      - dependencies
    collapse-after: 5

change-template: '* $TITLE (#$NUMBER)'
change-title-escapes: '\<*_&' # You can add # and @ to disable mentions, and add ` to disable code blocks.
  
exclude-labels:
  - skip-changelog

Step 4️⃣ - Update Changelog file

After a new version is released, we want to update the changelog with the latest changes, as we are doing with the release notes. We can automate it using another amazing GitHub Action - Changelog Updater.

This action can be integrated into another workflow (i.e: update-changelog.yml inside of the .github/workflows folder). This workflow can be similar to:

name: πŸ“„ Update Changelog πŸ“„

on:
  release:
    types: [released]

jobs:
  update:
    name: Update Changelog
    runs-on: ubuntu-latest
    permissions:
      # Give the default GITHUB_TOKEN write permission to commit and push the 
      # updated CHANGELOG back to the repository.
      # https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/
      contents: write    

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Update Changelog
        uses: stefanzweifel/changelog-updater-action@v1
        with:
          latest-version: $
          release-notes: $

      - name: Commit updated Changelog
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          branch: main
          commit_message: 'πŸ”– Update changelog'
          file_pattern: CHANGELOG.md

So, this workflow will start when a new release is released (types: [released]), including the changes from previous release and committing the change into the main branch of our repo.

Step 5️⃣ - Linking release and update changelog workflows

There is an issue reported here about how to automatically trigger the update changelog workflow from the release workflow. The workaround to fix it requires adding a new secret (i.e: PERSONAL_ACCESS_TOKEN) into your repo:

Step 6️⃣ - Release a new version

Now, it is very simple, just follow your development workflow, using your pull-request life cycle, add the labels of your own repository, and then tag a new version when you are ready to do it.

Push it into your repo:

git tag v1.2.1 -m "Version 1.2.1"
git push origin v1.2.1

The workflows run as expected:

… a new release is created, including the notes:

… and the changelog is updated too:

This is …

πŸ€–πŸš© Happy automating releasing!!! πŸ€–πŸš©

References

This blog post is my own summary about this process, but it was based from the content and experience of others, such as:

My kudos ❀️ to all of them!!!

]]>Roman MartinπŸ“† 2022 in a nutshell!2022-12-28T07:00:00+00:002022-12-28T07:00:00+00:00http://blog.jromanmartin.io/2022/12/28/2022-summaryAnother year is ending, and what 🎊 amazing year 🎊. It is time to recap this 2022 reviewing all the things done, lessons learned, and identifying improvement areas or gaps to cover. I could say that it is basically my own personal retro in front of my Kanban.

This year was very special for me, as it was the first one working fully in my new team, the amazing EMEA Cloud-Native Adoption Practice at Red Hat. It means that I was fully immersed in an international environment, every single day. It was a huge challenge for me collaborating, working, learning, sharing with others from many different countries, regions, and cultures (and sometimes suffering the different time zones). I joined Red Hat many years ago (πŸŽ‚ 8 years from now πŸŽ‚, the longest time in the same company), but joining this team was another starting point in my career. I was very nervous 😟, sometimes stressed 😧, and always afraid 😞 about my own Impostor syndrome … but the fact is that everything went better than I expected and this journey was a BLAST 😁.

I had the chance to work with so many talented, open-minded people, and always willing to support and help me in anything. Their honest, transparent, and proactive feedback was key for helping me to improve and do my best every single day. So, I can say thank you to all of them.

Definitely, this is the team, and people where I want to be.

But, what kind of things have I done? I will try to summarize (and anonymize) the most important (for sure I am missing something 😝 …).

πŸ“ Blogging πŸ“

I like blogging, and in general writing anything to summarize my findings, engagements, or anything I am working on … most of my colleagues know me about my documents. This year was not so much productive as I wanted in my personal site, but this is list of my posts:

However, I am very proud of the publication of one of them in the Red Hat Developer:

I can say that it was the most important publication during this year, and I got great feedback from the readers.

One of the goals of my team is to help our customers and service teams to easily adopt our technology, so I helped to improve some internal resources. The most important one was providing a new CER template (a.k.a. Consulting Engagement Report) related to Red Hat AMQ Broker. This template provides the scaffold, common patterns, and structures about Messaging Services based on this product, in cloud and non-cloud environments. So, it is basically an accelerator of our services in that area.

🏒 Customers 🏒, πŸ’» Technologies πŸ’», πŸ‘« People πŸ‘«, πŸ“ˆ DevOps and Agile 🚀

This chapter was the most exciting as it basically includes my daily basics in my team. It was a very productive year with a long list of customers, engagements, technologies, and enablement, where I could help others to achieve great outcomes, building amazing outputs, and creating high-performance teams.

If I need to summarize the most important ones, here there is the list:

  • Transformation and Acceleration: Building new teams and implementing new Ways of Working based in a DevOps culture and Agile practices to transform the teams (and impacting the organizations). Delivering fast solutions, following the Agile principles and values, and shaping high-performance teams are the most challenging things I was involved with, and the most exciting ones. I love these kinds of engagements. Most of them were aligned to improve the Software Delivery Life Cycle including new technologies, processes, and skilling people to achieve them.

  • Apache Kafka migrations and architectures: I was involved with different customers to help them in Apache Kafka migrations in different scenarios (on-prem to cloud, upgrading versions, …) or designing architectures where this component is key for data streaming solutions, or microservices architectures. It was a good chance to put in real scenarios something that we wrote some time ago in the Strimzi Blog.

  • Messaging solutions or services in cloud environments based in Red Hat AMQ Broker, when Apache Kafka was not an option, using the OpenShift Operator. It was a good chance to give feedback about the product from our field scenarios and reporting more features, opening issues, or improving our Knowledge Base with more extra references, such as this article, or this another one. I love our way of collaboration with different Red Hat teams to improve our products.

  • Workshops about Event-Driven Architectures in some customers as a way to design new solutions in cloud environments. These kinds of workshops helped me to create a sample use case with many different components and demonstrate some of the benefits (and trade-offs). This workshop is based in this repository.

  • Advanced microservices architectures or patterns using Red Hat Service Mesh and Red Hat Serverless. It could be the most technological challenge this year for one customer. Designing and implementing a solution for accelerating a refactorization of a monolithic application into a microservices architecture, delegating some cross functional aspects into the features and capabilities provided by both solutions on top of OpenShift. I learned many things that for sure will help me in other similar scenarios.

  • Collaboration at Konveyor Community in some of the tools, or repos, to promote and accelerate the modernization and migration of applications to Kubernetes and Cloud-native technologies. I could help to improve the Tackle Pathfinder Knowledge Base and collaborate with the amazing team behind the TackleTest, an automated unit and UI test generation tool to verify your application. I am looking forward to collaborating more next year.

  • Facilitating our amazing DevOps Culture and Practices enablement is basically one of my favorite tasks done this year. I had the chance to run in different places (Brussels, Dubai, Frankfurt, London, and Madrid), and one virtually (but I prefer the on-site version). This enablement represents perfectly our Way of Working and an immersive life experience about DevOps and Agile in a single week. I could say many things about that, but it is better get them from the public references of some of the attendees:

  • A bunch of technologies … The full list of technologies I touched this year is so long, but mostly I was working with: Red Hat OpenShift, Red Hat OpenShift Dev Spaces, Tekton, Argo CD, ActiveMQ Artemis, Red Hat AMQ Streams (Apache Kafka), Strimzi, Keycloak, Quarkus, Apache Camel, Infinispan, Istio and Service Mesh, Serverless with Knative, …

πŸ’« Rewards, Recognitions and Achievements πŸ’«

To be rewarded and recognized by your peers is the best way to get positive feedback. Who does not like to be rewarded? This year was a good one in this area.

I am not looking to get this kind of recognition from others, however, it helps me to identify which kind of actions have more impact on my colleagues and continue them in the best way, and also to identify areas where I should work to improve them. In any case, it is a metric to measure how I can help and collaborate with others better.

One of these rewards comes from the Red Hat Giveback Program. This is an incentive program to recognize an associate who goes above-and-beyond their role-based responsibilities and makes contributions which impact Red Hat. This year I got the following rewards from this program:

It was not the only reward from my colleagues, I was awarded as Red Hat Champion for Red Hat OpenShift in the Q2 of 2022, that it was something far away from any of my expectations or plans. The Red Hat Champions program recognizes those Red Hatters who have proven their product expertise by going above and beyond to ensure the success of Red Hat products and technologies. It is a peer-nominated program, intended to reward individual Red Hatters that demonstrate Red Hat culture and values while helping to establish a secure future for Red Hat product growth. So, I was humbled to be proposed and awarded with this recognition by my colleagues. Thank you so much!!!

More than 1000 points in our Red Hat Reward Zone … another Red Hat’s platform for peer to peer recognition in different competencies to promote the Red Hat’s values and culture within our colleagues, teams, and customers. My rewards in a nutshell:

But, the best achievement this year was to beat my personal best in a Half-Marathon race. It was in Madrid and I completed the race in 1:43:56 … that was 1 minute faster than my previous PB. I am very proud of that achievement, and I am planning to break it again soon.

🎯 Next Year 🎯

I like to have great goals and outcomes to help me to improve myself everyday, but I am not setting them ahead or in stone. I am agile and pivot as I learn more and when it is appropriate πŸš€.

For the next year I am expecting to meet with more colleagues, learn more from all of them, and have fun in anything I will be involved in. My goals will appear sooner or later, but I don’t mind for now. For sure, my Kanban will have great items to execute.

For my personal life, I have a great milestone to set up a new lifestyle at the end of the Spring, but it is something that someday I will share broadly with all of you.

Thank you so much to be here, as definitely you are part of the journey of the last year, and a key stakeholder for the next year.

See you in 2023!!! πŸ’»πŸ’ΎπŸ’Ώβ˜•πŸ“–πŸƒπŸ’«πŸ’

]]>Roman Martin:tada: New Red Hat OpenShift Application Services Cheat Sheet!2022-10-28T07:00:00+00:002022-10-28T07:00:00+00:00http://blog.jromanmartin.io/2022/10/28/new-rhoas-cheat-sheetI was playing, testing, and learning for a while the Red Hat Cloud Services. These services include a managed platform and data services to reduce the operational cost and complexity of delivering cloud-native applications. And also facilitates the life of the developers πŸ˜„.

Some of these services are:

  • OpenShift Streams for Apache Kafka provides a managed service of Apache Kafka. You don’t need to deal with the complexity of the infrastructure of an Apache Kafka cluster.
  • OpenShift Service Registry provides a full managed service of an API and schema registry, key for any event-driven architecture.

So I decided to refactor my loved 😍 Kafka Clients Quarkus Edition repository to use these streaming services, running everything in my Developer Sandbox as Red Hat Developer.

The results of this learning path is this new Kafka Clients Quarkus Edition with Managed Services repository using the latest versions of the components (e.g: Quarkus, JKube) integrated easily, running locally or remotely successfully.

Red Hat OpenShift Cloud Services provides a powerful command line interface (CLI) called rhoas. This CLI is very well documented in its website, however, I decided to create my own Cheat Sheet to know all the commands and for my own references. So,

:tada: I am pleasure to announce that a new Cheat Sheet is available: :tada:

I hope this new cheat sheet helps you when you need to manage your own Managed Services provided by Red Hat.

My full list of Cheat Sheets are available for your records here. As usual, comments, ideas, PRs are welcomed!

Happy coding !!! πŸ’»πŸ’ΎπŸ’Ώβ˜•

]]>Roman Martin:tada: ActiveMQ Artemis Cheat Sheet in Red Hat Developers2022-09-03T18:00:00+00:002022-09-03T18:00:00+00:00http://blog.jromanmartin.io/2022/09/03/amq-broker-cheatsheet-in-rhd🎊 Wow! 🎊 My small ActiveMQ Artemis Cheat Sheet was promoted as an official Red Hat Developer Cheat Sheet πŸ”. Now you can find it now as Red Hat AMQ Broker Cheat Sheet.

Since I posted my original πŸ“ ActiveMQ Artemis cheat sheet, I got great feedback πŸ‘†, comments πŸ’¬, and improvements πŸ™‹ about it from many colleagues, and others ones, interested in this amazing messaging project. Google Analytics πŸ“ˆ identified it as the most visited content of this small space on the Internet 🌐. I am very proud of it 😊.

Now, this content is now hosted as another Cheat Sheet on the Red Hat Developers site. Something that I could not expect when I posted for the first time. It was only possible thanks to great colleagues such as Hugo Guerrero, and the fantastic Red Hat Developer team. Thank you so much!

Now, I hope you can find it useful to introduce you to this amazing messaging product.

Enjoy it! :sailboat:

]]>Roman Martin:rocket: Cloud Native CICD Pipelines in OpenShift2022-04-01T00:00:00+00:002022-04-01T00:00:00+00:00http://blog.jromanmartin.io/2022/04/01/cloud-native-pipelinesCloud Native CICD Pipelines in OpenShift

My first Continuous Integration and Continuous Delivery pipelines (from now CICD) were created with Hudson (I know, I know !! I am very old :older_man: on this space), and after that with Jenkins for longer time. During this long period I used it (and others similar) to build, test, package, and deploy many different kind of applications (Monolith, SOA Services, Microservices, standalone apps, …) into many different kind of platforms (Tomcat, Red Hat JBoss Enterprise Applications, WebLogic, …) and of course on containers platform such as Red Hat OpenShift.

However, in cloud environments with cloud native applications in some cases I found so much complexity not easy to deal with it. Basically these tools were defined to run on Virtual Machines, required IT operations for maintenance, conflicts between teams or projects with shared plugins or extensions, no native interoperability with Kubernetes resources, …

… and nowadays I found a new player in this scenario to improve my CICD pipelines in the new Cloud Native World, with containers, Kubernetes, and OpenShift. This player is Tekton, or Red Hat OpenShift Pipelines as the enterprise version for OpenShift.

Tekton is a cloud-native solution for building CICD systems, providing a set of building blocks, components and an extended catalog (Tekton Hub) with great resources to use, making it a complete ecosystem. It is part of the CD Foundation with a great community, very active.

As Tekton is installed as a Kubernetes Operator, providing Custom Resources Definitions to define the building blocks, it is very easy to create, and reuse them in the pipelines. As other Kubernetes or OpenShift objects, Tekton CRDs are first-citizens, so many of the processes uses to manage your OpenShift platform are valid for them. For example, as a fan of Everything as Code practice, I can define my CICD pipelines as code and store them in a Git repository.

Tekton uses the services provides by the OpenShift, so it is designed for containers, and scalability. It means that the pipelines and tasks are executed on-demand with containers, so it is easy to scale them. We, as CICD designers, don’t need to deal with the platform, or infrastructure, as OpenShift provides us the services, and Tekton the objects to design the flow of our CICD pipeline.

In that integration with OpenShift services, the building images processes are now really native and we could use any of the technologies available, such as source-to-image, buildah, kaniko, jib, … Not more needed creating a custom image for a Jenkins-agent to build our application.

The same to integrate the deployment processes of your application, as you can interact natively with the platform … but in this scenario I am more fan to move the Continuous Delivery following the GitOps approach with another amazing tool as ArgoCD (but that is another story, and other blog-post :wink:).

At last, but not least, Tekton provides a set of amazing tooling to use on your favorite IDE, command-line tool and so on, and accelerate the adoption by your side, and make your life easier:

So, let’s go through across the main components of this amazing project.

Tekton Components

Tekton provides a set of different components to design and build your pipelines:

  • Tasks
  • Pipelines
  • Workspaces
  • Triggers

There are others too, but these ones are the base.

Tasks

Tasks is a collection of Steps that you define and arrange in a specific order of execution as part of your continuous integration flow.

Tasks can have more than one step, allowing to specialize the task with more detailed steps. The steps will run in the order in which they are defined in the steps array.

A Task is available within a specific namespace, while a ClusterTask is available across the entire cluster.

A Task is executed as a Pod on your OpenShift cluster.

This is the typical Hello World Task.

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: hello-task
spec:
  steps:
    - name: say-hello
      image: registry.redhat.io/ubi7/ubi-minimal
      command: ['/bin/bash']
      args: ['-c', 'echo Hello World']

Meanwhile a Task is a definition, the execution of the task with the results and outputs is a TaskRun.

An execution of previous task should be similar to (simplified and omitted some fields):

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  generateName: hello-task-run-
  name: hello-task-run-9d8hs
  uid: f3c8d81b-3e8d-4ad5-a01b-bf9b147485f6
  creationTimestamp: '2022-03-31T16:34:41Z'
  namespace: pipelines-demo
  labels:
    app.kubernetes.io/managed-by: tekton-pipelines
    tekton.dev/task: hello-task
spec:
  taskRef:
    kind: Task
    name: hello-task
status:
  completionTime: '2022-03-31T16:34:47Z'
  conditions:
    - lastTransitionTime: '2022-03-31T16:34:47Z'
      message: All Steps have completed executing
      reason: Succeeded
      status: 'True'
      type: Succeeded
  podName: hello-task-run-9d8hs-pod-kqcjv
  startTime: '2022-03-31T16:34:41Z'
  steps:
    - container: step-say-hello
      imageID: >-
        registry.redhat.io/ubi7/ubi-minimal@sha256:700ec6f27ae8380ca1a3fcab19b5630d5af397c980628fa1a207bf9704d88eb0
      name: say-hello
      terminated:
        containerID: cri-o://346b671912a63a98b310f0f06f0bcd9d9e3fab3b24a75246aed4921863b1d146
        exitCode: 0
        finishedAt: '2022-03-31T16:34:46Z'
        reason: Completed
        startedAt: '2022-03-31T16:34:46Z'

OpenShift provides a great dashboard to browse and inspect the Tasks and TasksRun

Pipelines

Pipelines are a collection of Tasks that you define and arrange in a specific order of execution as part of your continuous integration flow. In fact, tasks should do one single thing so you can reuse them across pipelines or even within a single pipeline.

You can configure various execution conditions to fit your business needs.

This example could give you a general view of a pipeline. This pipeline should be represented as:

Each Task in a Pipeline executes as a Pod on your OpenShift cluster.

Meanwhile a Pipeline is a definition, the execution of the pipeline with the results and outputs is a PipelineRun.

OpenShift provides a great dashboard to browse and inspect the Tasks and TasksRun

Workspaces

Workspaces allow Tasks to declare parts of the filesystem that need to be provided at runtime by TaskRuns. The main use cases are:

  • Storage of inputs and/or outputs
  • Sharing data among Tasks
  • Mount points for configurations held in Secrets or ConfigMaps
  • A cache of build artifacts that speed up jobs

Workspaces are similar to Volumes except that they allow a Task author to defer to users and their TaskRuns when deciding which class of storage to use.

Triggers

Triggers are the components ready to detect and extract information from events from a variety of sources and execute Tasks or Pipelines to respond them.

Triggers are a set of different objects:

  • EventListener: listens for events at a specified port on your OpenShift cluster. Specifies one or more Triggers or TriggerTemplates.
  • Trigger: specifies what happens when the EventListener detects an event. It is defined with a TriggerTemplate, a TriggerBinding, and optionally, an Interceptor.
  • TriggerTemplate: specifies a blueprint for the resource, such as a TaskRun or PipelineRun, that you want to instantiate and/or execute when your EventListener detects an event.
  • TriggerBinding: specifies the fields in the event payload from which you want to extract data and the fields in your corresponding TriggerTemplate to populate with the extracted values. You can then use the populated fields in the TriggerTemplate to populate fields in the associated TaskRun or PipelineRun.

The most common use case of the Triggers and EventListeners is integrated with Git repositories through the use of WebHooks. A Git mechanism to get data from any change in a Git repository.

Show me the code

But, you could do more things with OpenShift Pipelines, to design you cloud native pipelines. This is a small briefing of the main characteristics and features. But if you want to play with this new toy, I created a sample GitHub repository with a demo of tasks, pipelines and triggers.

https://github.com/rmarting/ocp-pipelines-demo

From here, only your imagination, use cases and Tekton could help you to create amazing pipelines in a easy, descriptive and simple way.

And if you want to dive deeper, don’t miss to check the following references:

Happy cloud-native pipelining :smiley:!!!

]]>Roman Martin:rocket: Monorepo, GitOps, CICD and beyond2022-03-25T10:00:00+00:002022-03-25T10:00:00+00:00http://blog.jromanmartin.io/2022/03/25/monorepo-gitops-cicd-and-beyondGitOps Product Monorepo Sample

Developing cloud native products following Agile, and DevOps practices could require to use different approaches, patterns and processes to do it in a fast pace. Many of the most common patterns in this space are:

  • Product Monorepo
  • Trunk-based development
  • GitOps
  • Cloud Native Application
  • Continuous Integration, Continuous Delivery and Continuous Deployment
  • Sealed Secrets

Use all of them at the same time could be a challenge for a new team, but it is possible getting the best benefits from each of them. I have working in many different use cases and products for a long time, many times using these patterns in somehow, learning from the pitfalls, and getting the best benefits. This repo represents an opinionated manner to do it for a new product team, combining all these practices in the same place.

Hoping this approach could help in your use case. Use carefully all the assess, and land into your specif use case.

The product is the software solution created for a business scenario, adding the value and solution to achieve the goals of the business. We build software to resolve business scenarios.

❗ Soon a blog post will try to clarify many of the aspects related with this repo. Stay tunned!❗

Product Monorepo

Product Monorepo means to have everything related with a software product in one single place, shared with the product team, to implement the full Software Delivery Life cycle of the product.

One of the most important topics for a Product Monorepo is to have a clear folder structure, otherwise you could get a chaotic layout with more pains that gains.

This repo is organized as:

  • bootstrap folder includes the initial components to setup the environment, mainly tools to define the base of the rest of the solution.
  • apps folder includes the list of applications or components of the product.
  • charts folder includes the Helm Charts to accelerate the deployment of any component, tool or application related with the product.
  • argocd folder includes the items related with ArgoCD and GitOps.
  • tekton folder includes the items related with Tekton and Pipelines.
  • e2e-test folder includes the end-to-end test suites of the product.

Trunk-based Development

A Monorepo is a specific Trunk-Based Development implementation where the product team puts its source for all applications/services/libraries/frameworks into one repository and forces team members to commit together in that trunk - atomically.

The trunk branch is defined basically as productive and any change merged there is candidate to be deployed in any environment, including production. There are not any other starting point to promote changes, as everything is integrated in the trunk. Other branches are considered ephemeral, to manage short pieces of changes, with a review process (by pair programming or by a Pull Request) before to be merged into the trunk.

This method allows the team members to develop fast small chunks (many times as features flags or not), with sooner integrations cycles, reducing merge conflicts, and promoting changes to others faster.

GitOps

GitOps defines the source of truth a Git repository, where everything starts from there and defining the desired state of our product.

Cloud Native Application

Designing our product as a Cloud Native solution will bring us many benefits in cloud environments. Most of the cases a Microservice architecture following the Twelve-Factor App methodology is the right starting point. Our product will implement that methodology.

Continuous Integration, Continuous Delivery and Continuous Deployment

Any product in the new automated era must be done without the most well-known benefits of Continuous Integration, Continuous Delivery and Continuous Deployment. Otherwise you are failing from the beginning.

Sealed Secrets

GitOps means β€œif it’s not in Git, it’s NOT REAL”, so it is a challenge to store sensitive data, like credentials, in Git repositories, where many people can access?. OpenShift provides a good way to manage sensitive data in the platform, but we need to extend it with other great tools to store sensitive data in Git without any break of security.

Here Sealed Secrets arrives to help us.

Playing with our Product Monorepo

Now, it is time to play :game_die:.

This repository defines a sample product with the following applications:

  • A sample Angular application as frontend for the final users. Details here
  • A sample Quarkus application as backend to manage the business logic of our product. Details here

Product Monorepo Topology

Requirements

This repository had been developed and tested in the following environment:

  • Red Hat OpenShift Container Platform 4.10
  • Red Hat OpenShift GitOps 1.4.3 (ArgoCD)
  • Red Hat OpenShift Pipelines 1.6.2 (Tekton)
  • Sealed Secrets Helm Chart 1.16.1

Bootstrapping Red Hat OpenShift Container Platform

To prepare your OCP environment, review and follow the bootstrap instructions

If everything goes fine, your environment should look like as:

CICD Tools Deployment Topology

GitOps with ArgoCD

To prepare the GitOps scenario with ArgoCD, review and follow the instructions.

If everything goes fine, your ArgoCD should look like as:

ArgoCD Deployment Topology

CICD with Tekton Pipelines

This Product Monorepo has a set of different pipelines to cover the Software Delivery Life cycle, integrated in our GitOps approach. The pipelines are described here.

Feedback, Comments, and improvements

As this is an opinionated approach, from my field experience in real scenarios and use cases, I am always open to learn from other experiences and use cases. Feel free to comment, improve or change my mind with your great ideas. Don’t forget to review our Contribution Guide do it in many different ways (issues, pull-request, comments, …), don’t miss the chance to do it.

I also open to share this approach, techniques and tools in community, meetup or simple group of colleagues around topics such as DevOps, Agile, GitOps, Cloud Native, … If you think that I can participate, please, let me know it.

If you are here, thank you so much. :smile: :tada:

]]>Roman Martin:rocket: Lessons learned migrating Spring Boot to Quarkus2021-12-03T09:15:00+00:002021-12-03T09:15:00+00:00http://blog.jromanmartin.io/2021/12/03/lessons-learned-migrating-spring-boot-quarkusThis blog post describes a set of lessons learned from my personal experience migrating Spring Boot applications to Quarkus. The article does not cover all the topics, approaches, architectures or designs to keep in mind for an enterprise full migration project, but it includes a set of conclusions from a personal perspective.

Cloud Native Applications, Microservices Architectures, Event-Driven Architectures, Serverless, … are the most common patterns, designs and topics used by Enterprise, Start-ups, and Software Companies to design and deploy new applications in this new Cloud Era (a.k.a Kubernetes Era). To build these kinds of new applications exists a list of different technologies, frameworks and languages (Go, Node.JS, Java, …) however one of the most extended and used is Spring Boot.

Spring Boot is a well-known framework, with a large community of developers, long history and friendly for many developers. However Spring Boot has other behaviors that could not fit well in a Cloud Native environment (resources consumption, startup time, response time, development lifecycle, …).

Quarkus is the new player in the playground to design new applications under these paradigms.

Quarkus is a full-stack, Kubernetes-native Java framework made for Java Virtual Machines and native compilation. Quarkus is crafted from best-of-breed Java libraries and standards with amazingly fast boot times and incredibly low memory in container orchestration platforms like Kubernetes.

Quarkus has a clear vision based in:

  • Container First: Optimized for low memory usage and fast startup times.
  • Imperative and Reactive: Designed with this new world in mind and provides first-class support for these different paradigms.
  • Developer Joy: Designed to make happy and fun the developer’s life.
  • Community and Standards: No need to learn new technologies, designed on top of proven standards (Eclipse MicroProfile, JAX-RS, JPA, …)
  • Kube-native: Providing tools optimized for Kubernetes.

Houston, we have a problem! Quarkus versus Spring Boot? Quarkus? Spring Boot? Which one?

In many migration projects (frameworks, application servers, jdk, …) the effort to adapt the source code to the new platform was one key. Refactoring code implies a range effort between trivial to epic and it could decline the decision to go or not to go. Refactoring from Spring Boot to Quarkus could be another one.

This article describes the following migration approaches from Spring Boot to Quarkus:

  • Migrating to Quarkus Extensions for Spring Boot
  • Refactoring to Standard Libraries and Quarkus Extensions

:rotating_light::rotating_light: Disclaimer and Spoiler Alert This article is not an official migration guide. :rotating_light::rotating_light:

Any kind of migration requires analyzing different things to answer questions such as why?, who?, when?, how?, where?. These questions are not easy to analyze and describe in a single article because they involve a large number of aspects like: processes, people, management, testing, … but who does not listen to sentences such as: Java is dead now; XX framework is better for cloud containers, Java consumes a lot of resources, … Well, Quarkus changes many of those sentences.

This article only wants to focus on some aspects of how to code/refactor the source code from Spring Boot to Quarkus. It does not cover all the features or capabilities of both frameworks but it summarizes a set of lessons learned from my personal experience. Quarkus is a highly active community so some of these lessons could change in the future (maybe in a few days).

Application to migrate

This blog post is based on a Spring Boot application with the following modules or components:

  • Spring Boot 2
  • REST Endpoints based in Spring Web
  • Apache Kafka as messaging system
  • Apicurio Service Registry as API schema registry
  • Avro schemas

It is a base to start to analyze this migration, where some other common features are not included (e.g: Persistence in Databases) to reduce the scope of this migration.

The original code of this application is available here.

The original application starts in 5 seconds:

2021-12-03 09:33:56.724  INFO 1 --- [           main] com.rmarting.kafka.Application           : Started Application in 5.132 seconds (JVM running for 5.76)

Migrating to Quarkus Extensions for Spring Boot

This approach is focused on reducing the number of changes and reuse as much code as possible. This approach is available thanks to a set of Quarkus Extensions for Spring Boot, designed to provide a compatibility layer for Spring Boot. At the time of writing this article the following Quarkus Extensions for Spring are available:

  • spring-di: Compatibility layer for Spring dependency injection.
  • spring-web: Compatibility layer for Spring Web.
  • spring-boot-properties: Compatibility layer to set up your Spring Boot using @ConfigurationProperties annotations.
  • spring-security: Compatibility layer for Spring Security.
  • spring-cache: Compatibility layer for Spring Cache annotations.
  • spring-data-jpa: Compatibility layer for Spring Data JPA repositories.
  • spring-scheduled: Compatibility layer for Spring Scheduled.
  • spring-cloud-config-client: Compatibility layer to read configuration properties at runtime from the Spring Cloud Config Server.

NOTE: Some extensions are considered preview, so backward compatibility and presence in the ecosystem is not guaranteed.

The main list of changes done to migrate the application is:

  • Quarkus requires JDK 11.
  • spring-di, spring-web and spring-boot-properties extensions are basically mandatory for any Spring Boot applications. We could say that they are the base for any migration to Quarkus Spring.
  • These extensions provide the base features of Spring Boot such as: Dependency Injection, Web, Configuration.
  • Although the compatibility layer supports most of the Spring DI capabilities, some arcane features may not be supported.
  • Spring Web Annotations could be maintained exactly equals.
  • Swagger annotations must be refactored to use MicroProfile OpenAPI. This refactor basically needs to use classes from org.eclipse.microprofile.openapi.annotations package.
  • OpenAPI and Swagger capabilities are provided now by the quarkus-smallrye-openapi extension, not needed by other OpenAPI or Swagger dependencies.
  • Health checks (actuators provided by spring-boot-starter-actuator) are now provided by quarkus-smallrye-health extensions. It requires new liveness and readiness proves in your deployment in Kubernetes.
  • Integration with Kafka using the Kafka Producer and Consumer API (provided by the Kafka Clients) only requires the use of quarkus-kafka-client extension.
  • Spring Kafka has not an equivalent compatible Spring extension, however Quarkus provides quarkus-smallrye-reactive-messaging-kafka extension with a set of new annotations to consume, produce or data streaming with Apache Kafka. It means a small set of changes.

The result of this migration is available here.

This new application starts in less of 2 seconds:

Dec 03, 2021 9:51:17 AM io.quarkus.bootstrap.runner.Timing printStartupTime
INFO: kafka-clients-sb-sample 3.0.0-SNAPSHOT on JVM (powered by Quarkus 1.13.7.Final) started in 1.887s. Listening on: http://0.0.0.0:8181

Refactoring to Standard Libraries and Quarkus Extensions

This approach implies a change in the mindset of your application, aligning with standards and refactoring your code. However you will get a full-compliant Quarkus application and then you are able to use all its empowerment.

For this approach I need to map the Spring Boot features with the right Quarkus Extensions:

Spring Boot Feature Quarkus Extension
spring-di Quarkus CDI
spring-boot-starter-web JAX-RS Services
spring-boot-starter-actuator MicroProfile Health
springdoc-openapi-ui OpenAPI and Swagger UI
spring-kafka Kafka with Reactive Messaging

The main list of changes done to migrate the application is:

  • Quarkus requires JDK 11.
  • Refactor @Service, @Component, @Autowired Spring annotations to @Singleton, @ApplicationScoped, @Inject CDI annotations.
  • Refactor @Configuration, @Value Spring annotations to @ApplicationScoped, @ConfigProperty Quarkus annotations
  • Refactor Spring Web Annotations to JAX-RS Annotations. This guide includes a conversion table.
  • Swagger annotations must be refactored to use MicroProfile OpenAPI. This refactor basically needs to use classes from org.eclipse.microprofile.openapi.annotations package.
  • OpenAPI and Swagger capabilities are provided now by quarkus-smallrye-openapi extension, not needed by other OpenAPI or Swagger dependencies.
  • Health checks (actuators provided by spring-boot-starter-actuator) are now provided by quarkus-smallrye-health extension. It requires new liveness and readiness proves in your deployment in Kubernetes.
  • Integration with Kafka using the Kafka Producer and Consumer API (provided by the Kafka Clients) only requires the use of quarkus-kafka-client extension.
  • Spring Kafka has not an equivalent compatible Spring extension, however Quarkus provides quarkus-smallrye-reactive-messaging-kafka extension with a set of new annotations to consume, produce or data streaming with Apache Kafka. It means a small set of changes.

The result of this refactoring is available here.

This application starts in 1.4 seconds:

Dec 03, 2021 10:21:17 AM io.quarkus.bootstrap.runner.Timing printStartupTime
INFO: kafka-clients-sb-sample 3.0.0-SNAPSHOT on JVM (powered by Quarkus 1.13.7.Final) started in 1.387s. Listening on: http://0.0.0.0:8181

Lessons Learned

Both migration experiences could be summarized in the next lessons learned:

  • Migration to Quarkus has been feasible with less effort migration. Both approaches did not require a full investment or hard work.
  • Quarkus Extensions for Spring Boot are enough for most common modules (di, web, jpa, security, …) but maybe not cover yours (jta, web-services, complex injection references, …). Analyzing the application is mandatory to get the gap.
  • Quarkus Extensions for Spring Boot could not cover all Spring features, then a refactor to Quarkus could be needed (Health Endpoints, OpenAPI, Swagger UI, Messaging Integration). However, the effort to refactor it was not so hard.
  • Refactoring to Quarkus involves moving your code to standard libraries (that hopefully you already know like for instance JAX-RS), so the learning curve to start with Quarkus is minimal.
  • Refactor to Quarkus will give you the full-power of Quarkus and its extensions.
  • Bugs and issues could appear in both migrations. Quarkus is stable and it is growing up so fast, resolving them and adding new features. You can check it in the releases page.
  • Full Quarkus migrated application was the faster one after completing the refactoring, as you can see in the following chart. It is not a complete performance test, but it might give you an idea about the performance capabilities of Quarkus:
Implementation Startup
Spring Boot 5 seconds
Quarkus extensions for Spring 1.7 seconds :rocket:
Quarkus 1.4 seconds :rocket:
Quarkus Native 0.042 seconds :rocket::rocket:

There is a list of other components not covered (e.g: testing, JPA, Cloud integration, security, …) in this blog post because it will extend the scope and length of this article. Quarkus is a highly active community where every day new features, issues and extensions are moving so some of these lessons learned could be covered, resolved or fixed soon.

Getting starting my migration

Migrating Spring Boot to Quarkus requires an effort to identify the best approach from the current state (AS-IS) to the final state (TO-BE) . There is not a silver bullet to migrate applications but there are some tools and references that could help:

:tada: Enjoy your journey to Quarkus. :tada:

]]>Roman Martin