Hi Allard, tell us who you are and what lead you into microservices?
I am CTO and Founder of AxonIQ, the company behind AxonFramework. Before starting AxonIQ, I worked as a Software Architect at Trifork, where I was responsible for several projects of different sizes. During those projects, I felt that the incidental complexity was much higher than what I believed should be normal in our industry. I started exploring different ways of building software, which eventually led to AxonFramework.
Around 2014, Microservices became popular, and in its wake, so did AxonFramework. AxonFramework was increasingly used to build “Event-Driven Microservices” systems, where events were not considered merely a side-effect of things, but a first-level concept in the architecture.
I use my practical experience developing event-driven (microservices) systems to build tools to simplify the job for others. For about 2 years now, that has been my full-time job, as part of AxonIQ.
What will you be talking about at Voxxed Days Microservices?
At Voxxed Days, I will be talking about different aspects of Event-Driven microservices. What does “event-driven” even mean? There is a lot of hype around both “events” and “microservices”. In my talk, I will shed light on different ways events may be used, and some of the pitfalls each approach comes with.
Message Oriented Middleware have been around for many decades now. Are they any MOM patterns that are still relevant with Event-Driven systems ?
Absolutely! However, most middleware available today is either extreme “smart” about messages, understanding exactly how they’re structured and perform routing and transformations based on the payload, or they are “dumb pipes”, only allowing for publish-and-subscribe semantics. The latter works fine for most simple event-based scenarios.
I am convinced that “event-driven” systems benefit from not only considering events, but also “commands” and “queries”. All three message types have slightly different routing patterns and delivery expectations. Using explicit messages not only helps developer understand the system better, it allows for components to become “location transparent’; component don’t need to know where the recipients of their messages are located, making the system much more “evolvable”.
MOM should be able to better cope with those message types, without interfering too much with the actual payload. We’ve seen some of the nasty side-effects of the Enterprise Service Bus and must be careful not to repeat those. On the other hand, we shouldn’t completely ignore the good things that the ESB has brought as well. There is a valuable middle ground in-between the ESB and the MQ.
Good, see you soon then
#microservices #eventdriven #nonsense
My contact information:
Twitter: allardbz
LinkedIn: https://www.linkedin.com/in/abuijze/
GitHub: https://github.com/abuijze