Why Messaging-Based Architecture?

IrisMQ Guide is now available online at GitHub.

Having exposed to event-driven programming since the early days of Delphi as well as the EventEmitter in Node.js, I have seen the horrors of callback hell and unwieldy code. So the JavaScript community came up with Promises, Generators / Yields (ES6), and Async / Await (ES7) but still, it did not entirely solve the problem of complexity in coding.

Which to me, all this complexity in programming can be boiled down into one adage:

Minimize control plane. Maximize data plane.

At the risk of oversimplification for beginners, let’s just say the control plane resides as the main function of every Go and Node.js application. But really, the control plane is all about state, control flow, coordination, control structure (sequence, loop, decision), transformation, routing and the like.

Everything else are functions that are being called regardless whether they return a value or not.

Having said that, I am particularly drawn to this event-driven programming (some say it should be message-driven programming which is essentially the same) which is rather powerful, just as the Black Rider is drawn to the One Ring.

Anyway, enough of The Lord of the Rings :-)

If you have no idea what this event-driven programming is all about, try to read jQuery’s custom event.

An event has three parts:

• event name — which serves as the interface
• trigger — the function that fires or emits the event as well as an optional payload data (control plane)
• handler — the function that handles the event (data plane which must be free of side effects)

This intricate flow of events is analogous to how our nervous system works.

More importantly, at a high-level, if you can model your business logic in a whiteboard as a graph, you may translate that graph model into code in a very intuitive manner.

That is the essence of message-based architecture.

The callback model you know in JavaScript is basically a form of publish-subscribe pattern in messaging-based literature.

There are other communication patterns (aka Scalability Protocols) which enables you to model your program according to its message flow topology. There is a Go implementation of SP simply named mangos.

And if that is not enough, you have other tools in your arsenal like a job queue which enables you to decouple your code into producer and consumer. NSQ is one great example written in Go.

If all you need is just intra-process messaging, there is a Go package named EventBus.

More recent and one prime example of usability in terms of messaging is Project Iris. It uses semantic addressing so you can model your nodes into units of cluster instead of instance-based (or IP-based) like that of mangos.

These four Go packages namely NSQ, mangos, EventBus and Iris are enough to model and reduce your system as messages that flow to and fro like electrons.

No need for Docker, Kubernetes, Mesos, OpenStack and other creatures of complexity. It’s not that I am against Docker and others. Containers, just like their old counterparts VMs, merely solve the distribution problem.

Messaging solves the producer/consumer problem regardless whether you are using containers, VMs and anything in between.

If this appeals to you as a function of usability, sign up at itmarketplace.net and see how we are bringing back the fun to computing.

It’s time we model software systems like a nervous system where the key is messaging.

Update:

• Read combining events and state machines by Martin Sustrik

Do you want to be a developer, and sustain a fun and meaningful IT Marketplace? Just click HERE.