Software architectures are full of opinions. They are usually the result of one person’s bias towards a specific technology, or a specific approach to developing software. Sometimes software architectures are the result of reading something in a book or seeing something in a video and believing that it’s the answer to the world’s problems. In this post, I’ll share my opinion, and my desired architecture for my own softare.
Being the lead developer on the Neuron ESB product for the last 3-and-a-half years, I’ve definitely learned a lot about modern enterprise architectures. Before working on Neuron as a consultant, I definitely built some very complex monolithic systems. I never really thought about message queuing or aynchronous tasks. Everything was implemented to happen right away. All work happened within the lifetime of a single request on the server.
So after my experience (or during, as that experience is still ongoing), I’ve definitely become more appreciative of messsage-based architectures. In these architectures, you make use of a queuing system and queuing patterns to distribute work across multiple components. Message-based architectures are also very useful for just sending event notifications between different systems. But my favorite aspect of message-based architectures is how they open up a system to better handle extension and evolution over time. Different pieces of the solution can be changed and removed or added just by connecting to the message bus. New events can be created. New work can be composed with existing work. Basically, good things can happen.
If I were ever to leave Neuron ESB to work on another product or project, or when I develop my own applications moving forward, I am definitely going to include a message bus in them. With microservices finally catching on and systems becoming much more distributed in the Amazon and Azure clouds, a message bus is necessary for building scalable and efficient applications.