IrisMQ and Three-Tier Architecture

I am reminded with a saying from somebody to make things as simple as possible and to be pragmatic when it’s impossible.

The simplicity side belongs to IrisMQ. Iris clustering is simple. You just issue a cluster name, port number and RSA private key and you’re all set. There is no gossip protocol. There are no other flags to configure for developers to start building cluster-aware apps. Except for ops who might need profiling and debugging options.

As far as three-tier architecture is concerned, Iris and NSQ belong to logic tier. You develop proxies from its periphery namely the UI (user interface) tier and storage tier.

Now, what is impossible is to impose your will on the storage tier. You see, Iris and NSQ has their own clustering methodology. And worse, each relational and non-relational databases have their own too.

Redis, Cassandra, Riak, MongoDB, InfluxDB and many others have their own clustering methodology. Would they opt to use Iris way of clustering? Unfortunately, not.

It’s because Iris belongs to logic tier and so is NSQ. Once your data moves beyond that tier, there is going to be a data transformation.

This is why IrisMQ is data-agnostic. You can use proxies to bridge all the differences of the netherworld (so to speak).

Just in case you get bogged down with IT complexity, it’s just the way it is. But with IrisMQ, it is different. You embrace simplicity for developers. Heck, there is nothing simple with operations!

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