IJYI Messaging Pipeline
Our resilient, high performance messaging pipeline is built for the cloud and built to scale. It allows developers to worry about business logic and get up and running rapidly.
In a world of cloud hosting and software as a service, integrating business and enterprise systems poses significant challenges. The days of a single vendor application or hosting stack are gone. The agility afforded by Software As a Service is now expected across systems.
Designing and building for applications for scale whilst continuously delivering value often also poses significant challenges for development. Co-ordinating the processing of messages whilst working on complex business logic means that developers often need to keep their heads in two different worlds and balance two different business needs.
We developed the IJYI Messaging Pipeline to enable our internal development team to concentrate on what mattered to our customers, delivering business value, safe in the knowledge that co-ordination and processing of messaging events is handled by the IJYI Messaging Pipeline.
Range of Cloud Transports Supported
Support for REDIS, Amazon SQS, Microsoft Azure Service Bus and Apache ActiveMQ gives huge flexibility on where your messaging platform is hosted.
Fast, Resilient, built for the cloud
The IJYI Messaging Pipeline (IMP) has been build from the ground-up for the cloud, supporting both AWS Simple Queuing Service (SQS) and Simple Notification Service (SNS), as well as Microsoft Azure Service Bus.
Used in conjunction with autoscaling services that these cloud platforms provide, this affords significant cost savings whilst allowing message handling nodes to spin up according to workload.
Minimal Development Learning Curve
IMP was created to allow our internal development team to concentrate on the business logic of an extremely complex software build, without having to worry about the underlying transport of the distributed messages they were creating.
Developers simply create message entities, and implement a simple interface to handle those messages. Due to the way these message handlers are created, this creates a strong seperation of concerns, is easier to test and much simpler to scale both up and out to handle huge numbers of messages with multiple nodes in a fast and resilient fashion.