We use the DLQ and OpenTelemetry functionality in Axon 4 framework, will this require the paid for version in Axon 5 framework?
What about the upcasting functionality, we are using this extensively at the moment, will this continue to function in Axon Framework 5, without a license?
To follow up on this comment “We’re providing access to Axoniq platform in different plans, with pricing models suited for companies of all sizes. Including free access for smaller companies. If Axon Framework has provided value to you and your team, I am sure there is a plan that reflects that value properly.”
What is a classed as a small organisation? We are a relatively small software company but we provide our software to multiple large organisations that run this on premise, does this make a difference? We do not use Axon Server.
Who is the best person to reach out to and discuss the pricing models with? And who is best to talk to about specific functionality in Axon Framework 5.
Hi @Yambay, I can give you some concrete answers, and I’ll do so part by part.
The SequencedDeadLetterQueue already moved to what’s now called Axoniq Framework. This will require an active subscription. Subscriptions come in several forms, as described on the pricing page.
The Open Telemetry integration has not yet been ported to the Axon Framework 5 APIs. The adjustments will be part of Axoniq Framework, though. And, as such, will require a license.
Upcasting logic will be introduced in Axon Framework 5.2.0. As such, that’s not released yet. What’s very important to know here, is that Axon Framework 5 deals entirely different with message conversion.
AF no longer builds based on the FQCN of your messages. Instead, we derive a so-called MessageType, which is a combination of a local name, namespace, and version. Without specifying anything, the MessageTypeis the FQCN, taking the class name as the local name, the package name as the namespace, and defaulting the version to 0.0.1.
For more internal details, I’d refer to this page of our Reference Guide concerning the MessageType , how this is resolved, and how you can influence this. This setup will allow users to fully decouple their concrete classes from the messages they actually send and store.
Furthermore, a Message Handler now only needs to define the MessageType it is interested in, not the concrete type. Hence, you can do something like this in AF5:
Thus, you can define the concrete event types uniquely per application, thus decoupling the commands/events/queries from being a forced dependency between your instances.
However, you can go a step further with this:
@EventHandler(eventName = “namespace.localname”) public void on(JsonNode myEvent) { // do upcasting here, then event handling logic… }
Due to the decoupling and AF’s Converter integration, if you specify the name of the event you care about, the first parameter will become that event. Depending on the type you specify, AF will convert it to that type. This opens up an entirely new avenue to anybody using Axon Framework - you can upcast specifically for a given Aggregaten, Entity, Event Handlers, etc.
Although not fully described yet, as we’l work on this in 5.2.0 (intended for end of Q2 2026), the Reference Guide already has a small header about this here.
It’s due to this new design, that we will be inclined to do a full rewrite of the old upcaster API.
Hence, any upcasters you have, Andrew, will require work already I am afraid. We will, as we have for other parts, provide a migration guide on this.
Now, that’s a lot of background that is, in my opinion, important to have. As it may steer the choices you make.
Going back to your question, if upcasters will continue to function without a license. Strictly speaking, no, because the APIs will simply have to change drastically. So, regardless of whether you have a license yes/no, the hold solution needs to be adapted to the new one.
I’ve just drafted the options you have today to deal with old versions of messages. That’s open source, without a subscription, and will stay that way. We will look into means to ease the process for larger scoped organizations. Adding things like integrated testing, and more means to do component-specific upcasting. That functionality will first be introduced in Axoniq Framework, thus requiring a license.
The pricing currently has four tiers, being the following, as per our pricing page:
Individual - For developers evaluating our event sourcing solutions. Non-production use only.
Team - For organizations under 20 employees or $10M in ARR*.
Small Business - For organizations under 40 employees or $30M.
Enterprise - For regulated industries with mission-critical, zero-downtime workloads.
So, a small organization in this case is 40 employees or $30M.
On face value, my answer here would be yes, that makes a difference. You may be small, but it’s your client using the software. But, I am not the person making the financial decisions for our customers. So, I would strongly advise to validate my response with somebody on our sales team. This brings me to the second to last question:
I’d go through the contact page for this, @Yambay. That’ll ensure you’ll be put in contact with the right people depending on your specific scenario.
That’s the Axon Framework team, of which I am a part. Hence the feedback I am giving.
Know that we’re working on a more extensive breakdown on what’s Axon Framework and what’s Axoniq Framework, which will be included into the Reference Guide, for full transparency.
Furthermore, the Reference Guide will soon mark sections that are Axoniq Framework with a specific logo, to clarify those require a subscription.
—
Hoping this gives you the feedback you require, Andrew! If you, or anybody else, has more questions, be sure to reach out.
I completely understand the need to find a more sustainable model to support framework development, however by making OpenTelemetry a paid feature I think you effectively killed what remains of the open and free Axon framework.
OpenTelemetry is a core feature when dealing with ANY microservice development. Development, support and debugging without OT is almost impossible in a distributed system (unless we count hobby level projects).