Posted on

Running Axon Server: From Local Install to Full-Featured Cluster in the Cloud Part 1

Axon Server is the flagship product of AxonIQ, and companion product to the Open Source Axon Framework. Axon Server itself is available in two editions, Standard and Enterprise, with Axon Server Standard Edition (SE) available under the AxonIQ Open Source license, while Axon Server Enterprise Edition (EE) is licensed as a commercial product with a full range of support options.

In this series, I would like to take you along installing Axon Server for several different scenarios, starting with a local installation of Axon Server Standard Edition as a “normal” application, via Docker and Docker-compose, to Kubernetes, to eventually arrive at a full cluster of Axon Server Enterprise Edition on Cloud VMs. All platform examples can be run using both editions, but I wouldn’t expect you to run a three-node EE cluster on your laptop, just as it doesn’t make sense to go for a large production microservice architecture using a single-node SE install.

Posted on

Run Axon Server on Kubernetes or Virtual Machines?

Running applications built with Axon Framework on Kubernetes is a no-brainer, but is Kubernetes a good choice for running Axon Server with the wide choice of deployment options and environments available, andwhat factors do you need to consider when deploying Axon Server?

Whether you’re developing a greenfield event-driven microservices application or you’re taking your existing monolithic application and "strangling" it into one, Axon Framework paired with Axon Server works well together to handle both scenarios.

Posted on

No Framework for Your Microservices?

Axon Framework is an open source framework frequently used for building event-driven microservices on the JVM. Its architectural concepts are CQRS (Command Query Responsibility Segregation), DDD (domain-driven design), event sourcing, and location transparency.

The choice of using a framework for application development is somewhat controversial. You might have a look at this blog by Peter Kummins, which argues against the use of frameworks in general. More specific to the field in which my organization, Axon operates, father-of-CQRS Greg Young is known for advising “don’t write a CQRS framework,” and DDD authority Mathias Verraes recommended on Twitter not to use a framework for applications that have to last multiple years. This article by Tomas Petricek makes some other interesting points, clearly distinguishing between libraries and frameworks, and advocating for the use of libraries over frameworks.

Posted on

Parameter Resolvers in Axon

Axon is an open-source Java framework for building systems in CQRS (Command Query Responsibility Segregation), DDD (Domain Driven Design), and Event Sourcing manner. Axon provides a high level of location transparency, which gives the opportunity to easily split the system into several microservices. You can download the fully open-source package here. The Axon Framework consists of message-based commands, events, and queries that are supported types of messages. For each of these messages, we can define a handler (a method or constructor) to handle it. In some cases, the message itself has enough information to be handled, but in many others, we have a dependency on other components and/or variables (message metadata such as correlation information would be a good example). Axon provides a really powerful mechanism to inject these dependencies into message handlers — Parameter Resolvers. This is the story about them. At the end of this article, you can find a cheat sheet of all resolvers provided by the Axon Framework.

Anatomy

There are two important components that support this mechanism: the  ParameterResolver and the  ParameterResolverFactory (see Figure 1).

Posted on

CQRS Replay Performance Tuning

Command Query Responsibility Segregation (CQRS) has become a popular pattern to avoid complex and, therefore, slow database queries in applications. With CQRS, queries are served from dedicated read models that are optimized for the query’s specific needs. This ensures that queries are as simple as possible and, therefore, as fast as possible. The read models need to be initialized and kept up to date with the primary storage (the command side). This is done most easily if the primary storage is event-based: the Event Sourcing (ES) concept. Axon offers a mature and popular implementation of the CQRS/ES concepts on the JVM, but several other implementations exist.

On the one hand, CQRS/ES presents a solution to a common performance problem. On the other hand, it introduces a couple of new potential performance challenges. First, the event store may not be able to deal efficiently with the number of events being stored. If the events are kept in a regular relational database table, performance will severely degrade once it grows to the point where the indices can’t be buffered in RAM. This is when built-for-purpose event stores like Axon Server can come to the rescue.