Allard Buijze – “For a system to be reactive, there is a great number of non-functional aspects to deal with.”

Allard Buijze is Founder and CTO of AxonIQ. Starting at the age of 6, he has developed a great passion for programming and has guided both large and small organizations in building performant and scalable applications. Now, he is on a mission to make implementations of large scale systems easier, using the concepts of Domain Driven Design, Command-Query Responsiblity Segregation and Event Driven Architectures. He created Axon Framework as an experiment initially, but when both large and organizations started using Axon as a solution to their complexity problems, AxonIQ was born.

What is your background and what sparked your interest in distributed systems?

I started programming at the age of 6, on the Commodore 64. After high-school, I decided to pursue a career in software development and got my first professional experience in several jobs while attending university. That’s where some of the gaps between theory and practice started to become apparent. In the years after, I was amazed by the sheer amount of accidental complexity in systems, especially as they evolve. On my search for better ways, I started to study and practice Domain Driven Design, and later also CQRS. In 2009, in an attempt to implement some commonly needed building blocks for CQRS, I “accidentally” created a framework that people started using in production: Axon Framework. In the years thereafter, with the growing popularity of microservices, Axon provided structure and guidance to many in the development of distributed systems.

Reactive is a new buzzword for many traditional developers. What is your prediction for its importance in application development over the next couple of years?

I think I need to separate Reactive Systems from the Reactive Programming to answer this one. Regarding Reactive Systems, there is a set of sensible commonly applicable practices that will clearly show their benefit as the systems we need to build become more complex. The importance of these principles will undoubtedly grow in the years to come. Reactive Programming is a relatively new style of programming for most of us. While there are clear benefits, I don’t see many developers reap those benefits to the largest extent possible just yet. For that, more APIs will need to consider these practices (similar to the efforts done on R2DBC) and they will need to find their place within software architecture practices.

What is the biggest challenge companies deploying Reactive systems are facing?

Conceptually, I doubt that many will disagree with the Reactive Principles. However, the devil is in the (implementation) details. For a system to be reactive, there is a great number of non-functional aspects to deal with. There isn’t a commonly accepted method, yet, for implementing these non-functional aspects. While different supportive technologies have emerged, such as Akka/Lagom, Vlingo, and Axon, many developers are still overwhelmed by how they are expected to think differently about building systems. Great progress has been made on the infrastructure level, but the practices applied in applications still have a lot of catching up to do.

What is the best solution to this challenge?

Education and standardization. More developers need to be taught how to apply these practices, supported by stories from the field. While tools and frameworks can provide guidance, they cannot replace the need for conceptual understanding of what happens “under the covers”. For this to be successful, seemingly “competing” technologies need to find their commonalities and make those explicit. That’s why I was very happy to team up with Jonas Boner and many others to write the Reactive Principles document. This is the most effective way to make the concepts more accessible to larger audiences.

What is your most ambitious professional dream that you hope to achieve one day?

Right now, we are working hard to make the concepts of CQRS and Event Sourcing more accessible to developers, by helping them overcome the “downsides” of these concepts. My dream is to provide the tools and practices that allow developers and architects to choose to apply these practices purely based on the advantages they may bring to their system, knowing that the risks and knowledge gaps are covered.

Who should attend your talk at Reactive Summit and what will they learn?

My talk is primarily focused on Architects and Developers that have, or plan to, embark on a journey of building a distributed system. Especially the event-driven kind. Using a mixture of lessons and laughs, we will explore what’s good, what’s bad, and what’s so promising about this architectural style. While looking at what’s possible in the future, we’ll focus on what’s important for the short term. “Keep your eyes on the stars and your feet on the ground”.

Leave a Reply