Starting your first PoC with an event-driven approach and Axon

Introduction

Are you planning to get your first hands-on experience with a more event-driven approach to software development? Are you considering using Axon? Then this blog is meant to help you. 

The Axon project started over 15 years ago to enable developers to be able to build software better and faster. This vision allows us to be able to do cool stuff and have fun doing it. 

Over the past 15 years, I have seen a lot of companies that used our technology for the first time AND used the architectural patterns of DDD, CQRS and/or event sourcing for the first time. Those companies were typically starting with a small proof of concept (PoC). This can be quite a challenge.  If everything is new, it is hard to do it right the first time. 

In this blog, I want to share my experiences to help you do a successful PoC and have fun while doing it. I generally see two main pitfalls, namely:

1. Event-modeling
2. Event-driven infrastructure

This blog will focus on event-driven infrastructure and not on event-modeling. However, you can find a lot of information about the modeling part on our website for instance the CQRS/ES Playbook is a good starting point.  If this is your first time using events, my advice for you is make sure you have someone on your team that has done it before. If you don’t have internal experience with event-modeling, I would urge you to consider hiring an external consultant that can be an event-driven coach and brainstorm with you. 

Event-driven infrastructure

There are two infrastructure components needed to build event-driven applications: an event store and a routing system for your events, commands, and queries.

An event store is a database with very specific functionality, namely to store, retrieve, and replay events. In a way, it is a database management system (DBMS) with very specialized functionality. It does only three things: stores events, allows you to query for certain events, and retrieves large amounts of events when you do a replay. 

A routing system is needed when you are using a microservice architecture. The system will take care of routing events, commands, and queries between different components of your application. Please note that it is not just about routing events; commands and queries need to be routed too.

If you use Axon Server in your PoC you will have an out-of-the-box system that is both an event store and a routing system. Within minutes you are up and running, and your Axon Framework application can store/retrieve events and route events, commands, and queries.

Build it yourself or use Axon Server?

The alternative is to build your own event store and routing system. This is certainly possible, and before we created Axon Server in 2017 that is exactly what we did all the time. So it is an option to build it yourself using, for instance, a relational database in combination with an event streaming solution. It is tempting to do this as it is a cool project for some developers since it is a complex engineering challenge and by far not easy to do. But, believe me, we know how difficult it is to build a distributed event-driven infrastructure that ensures all events are stored and all nodes are eventually consistent. We have a team of great developers working on this every day. 

So you could build the event-driven infrastructure components yourself or you could use Axon Server.

A compelling argument to build it yourself is to avoid a vendor lock-in. Axon Server has two flavors. There is the standard functionality, which is great to use in a PoC, and there is the enterprise functionality, which requires a subscription. Enterprise functionality includes fault tolerance by using multiple nodes to store the events, and typically, you need this in a production environment. In the past, I have often seen that the software architecture had to be adjusted because of the licensing policies of vendors and I hated that. Hence, I understand why it is tempting only to use Axon Framework, which is completely open source and requires no subscription or license, and skip Axon Server. However, keep the following in mind:

1. It is easy to underestimate the complexity of building your own event-driven infrastructure and thus the amount of work involved. The devil is always in the details. There are many details when you start storing events, replaying events, routing commands to distributed nodes, and keeping them in sync using some kind of quorum calculation method.
2. It is not just about routing events. Off-the-shelf routing systems can route events just fine, but it is also about routing commands and queries, and doing that is not standard functionality. Hence, you will need to develop this yourself.
3. This is not something a junior developer can do. This is a job for your most talented developers with a solid knowledge of the infrastructure components that will be used. You will need great DevOps developers who are a bit more Dev than Ops.

Before deciding to build it yourself, you should ask yourself a few questions: 

1. Do you really want to build infrastructure for an event-driven architecture yourself? Are you in the business of building solutions for your customers/users, or are you in the business of building infrastructure?
2. Do you need it at the beginning of the project or could you start with out-of-the-box functionality (Axon Server) and later replace it with your own event store and routing system?
3. Do you have the knowledge and skills in your team to build it yourselves? If so, do you want these top developers to focus on infrastructure or on building functionality that will impress the users? Users do not care about infrastructure, but they care about functionality that helps them, and rightfully so.

The most compelling argument to use Axon Server is that it works, will lower the complexity of your PoC significantly, and will boost your development speed and you can always replace it later with your own solution. I know I am biased, but I think it is a mistake to start a PoC with a focus on building infrastructure. The pitfall I have seen too often is the infrastructure requires much more effort than estimated and you are not able to deliver the functionality that users are expecting. Quickly the users will lose interest in yet another IT hobby project and your PoC will fail.

Conclusion

In your shoes, I would always start by using Axon Server Standard Functionality which is free to use. If you need enterprise functionality in your PoC, you can use the 30-day free trial to check it out. Using Axon Server will allow you to focus on building the functionality and impress your users. 

After the successful completion of the PoC and getting the green light from the business to proceed with the project, you can still build your own event-driven infrastructure. Replacing Axon Server with your own infrastructural components is nothing more than changing a configuration file. Building the infrastructure at the beginning, the middle, or the end of your project does not change the amount of work that needs to be done. There are no penalties to be paid if you start with Axon Server.