Release blog 2024.1 – the Spring release

I don’t know about you, but I always feel good to leave winter behind and enter spring. The daylight savings makes days longer and people are getting together again outdoors, making our whole neighborhood so much livelier than the months before. Spring for me is synonymous with awakening and rejuvenation. And that’s exactly what we did with Axual.

Our Spring release marks the completion of the convergence of Axual Platform and Axual Governance architectures. With the new-and-improved architecture we have rejuvenated our whole platform in the past year. A lot of legacy and complexity was removed and installations are more of a breeze than ever before. We also worked on increased transparency through a newly introduced Axual Cloud health monitor. And given the spring cleaning that many of us will be doing, we have also made a big effort to clean up our house by making lots of small improvements and fixing (sometimes long-outstanding) bugs. More about this and other features below.

Enjoy Spring!

Upgrading to the new Axual Platform architecture

After we introduced Axual Governance in April 2023, we worked steadily on the convergence of its fresher architecture and the older Axual Platform architecture. In late 2023 the two were already merged and ready for deployment of new installations, but in 2024.1 we include all necessary upgrade documentation for existing installations.

The 2024.1 release is the first one which allows customers to upgrade their own Axual Platform installations to the new architecture. The old (instance/cluster microservice) architecture is deprecated as of this release. However, customers are not forced to upgrade right away. We will keep supporting the old architecture until the end of 2024. The 2025.1 release (expected end of March 2025) will be the first release from which the old architecture support is removed.

Of course, private installations are often heavily customized. Therefore it is not possible for us to provide concrete migration scripts or runbooks. Hence, the following guidance is provided in the documentation:

Migration Template → Upgrade runbook → Upgrade

The maintainers of your Axual Platform need to convert the provided migration template into an upgrade runbook. This can be tested out and refined on sandbox installations. Once the runbook is stable and proven, you can execute the upgrades on your TEST, UAT and PROD installations.

If things are still unclear, Axual is there to help. To discuss any questions, or in case you need reassurance on how to approach the upgrade, we advise contacting us to have a session to tailor the process to your installation.

Improved documentation for private installations

In the last quarter, we spent quite some effort in making sure (local) installations of our platform on Kubernetes and OpenShift are well documented. Documentation is offered for the following installation scenarios:

• Axual Governance only: when you want to enable Self-Service and governance on your existing Kafka cluster (OpenShift, Kubernetes).
• Axual Governance and Streaming:  when you want to give Axual Platform a spin, including Apache Kafka (Strimzi).

In addition, documentation is provided for both Kubernetes and Openshift installations.
Want to give it a try? Check it out by following the links above.

Axual Cloud Health Monitor (preview)

(Screenshot of the Health Monitor during a planned maintenance window)

Cloud customers can get access to our service health page and see the current status of the service as well as historical insights. Broker health, availability and the status of Discovery API are currently displayed, with other services  planned to be added during Q2.

Whether it’s an unplanned incident or planned maintenance, the health page will quickly help answer the question whether any issue is client-based or has a root cause in the Cloud.

Insights available on-premise

The Axual API contains a Metric API, which is served by our Metrics Exposer component. While Axual Cloud has had support for this for quite some time already, Axual Platform did not. New in this release is that the Metrics Exposer is now a standalone component, which can be installed on any Kubernetes cluster with a running Prometheus-Kube stack available. This makes our Metrics API available for on-prem and private cloud customers.

You will be able to enable the Insight feature on your Self-Service by following the configuration docs.

Distributor improvements

Axual Distributor is part of Axual Platform. It allows multiple Kafka clusters to be kept in-sync, both with messages as well as with consumer group offsets.

The newly released Axual Distributor now fully runs on Kubernetes platforms. It was rewritten to a large extent so as to better suit the underlying infrastructure and Kafka Connect paradigms. The Distributor on Kubernetes is now capable of distributing committed offsets for consumer groups from one Kafka cluster to multiple other Kafka clusters. It works as follows:

“The committed offsets on the source cluster are read, collected and produced to a topic on the target cluster by the Offset Distributor. The Offset Committer reads from the topic, and applies the consumer group offset, unless that group is already active, or if the target topic partition does not exist.”

Offset distribution is useful when migrating a consuming application from one Kafka cluster to another or in failure scenarios where a second cluster acts as a hot-standby cluster in case the primary cluster fails. Because of offset distribution, applications switching to the secondary cluster will continue consuming where they left off on the old cluster. Business continuity guaranteed.

Another new feature of the Distributor is the support for multi-level distribution. This allows three or more clusters to be synchronized without creating additional topics or partitions. Multi-level distribution allows messages and offsets to be shared across many clusters without the requirement of each cluster being able to connect to every other cluster.

Rewritten Helm Charts allow the Offset and Message Distributors to be easily configured in a multi-level configuration. They also allow the Offset Committer to be configured and deployed easily.

Several improvements and bug fixes

In the area of small, but useful changes, the following was added.

Security improvements

• It is now possible to prevent certificate reuse within a Tenant or Instance. This setting is configurable by the Tenant Admin.
• The updating of an expired SSL certificate for applications is greatly simplified.

Governance improvements

• New popups were added to give development teams direct insights into relevant endpoints for Kafka and Schema Registry for all different protocols (ie. mTLS, SASL, OAuth etcetera).
• Several catalogs were given search improvements, so you can now search by Owner Team and other useful fields.
• Tenant Admins can now export catalogs from the system for private offline use.
• A label was added to the top of the Axual UI to distinguish between multiple environments that you may be running (ie. TEST, UAT and PROD). This prevents making changes in the wrong environment due to similar UI confusion.
• In private environments, you can now use cascaded deletes for Applications and Streams, making it easier to clean up your own private resources.

Other updates

In our release notes, you will find other (smaller) updates to our product, which we are continuously improving with your feedback.  Check them out here.

Start your Kafka journey with Axual

Got excited from reading this post? Are you struggling with Kafka in an enterprise setting? We are here to help. Here are a couple of next steps you could take:

– Start a free trial

– Request a demo and talk to our experts

– View other content and customer case studies

‍