Micro Services Not Monoliths

Unlike most streaming vendor solutions rubris-io is not an Application Server or a Gateway Server that all your messages must be pushed through.

Although micro-services as a concept has become something of a bandwagon, practice tells us that small self contained applications are easier to develop, easier to test and easier to scale than large “do everything” monolithic containers.

Indeed, the last few years have seen a spate of lightweight alternatives to the large vendor containers that were dominant in design literature and consultancy recommendations. Or rather, were dominant until actual experience showed that they were really an anti-pattern in operation and efficiency.

Instead, rubris-io is designed to be simple to use and embeddable directly in your applications so they can be deployed as standalone services with minimal overhead. This allows each application to be tailored to the behaviour you want and encourages the aggregation of isolated micro-services in the Client, rather than having to pack all your messaging for different service behaviours into 1 or 2 huge servers.

With that in mind a simple AWS type deployment would look something similar to the diagram below, where each rubris-io application represents a vertical behaviour, e.g a trading app, a pricing app etc. Together they would make up the overall application that the Client sees as if it was a single large service.

This greatly simplifies the development and upgrading of the individual vertical services and allows the flexibility to size and scale each one appropriately as needed.

However, as always in life there are no complete solutions only tradeoffs. The main drawback to this type of approach is that the number of application instances tends to increase significantly and without integrating substantial automation into the build, deployment and management of the applications one tends to find that traditional human-centric support and test functions are quickly overwhelmed.