People don’t talk enough about rules engines, but they hold a lot of promise. Even if you’re not a financial institution or an insurance company, engineers and architects should consider them whenever they find the team writing too many algorithms with too many nested if/then conditionals.
Red Hat has an open source rules engine you’ve probably heard of — Drools. Drools is solid technology but there are many ways the core execution runtime gets bundled in various other products, so that flexibility and adaptability make it appear complex at first glance. I want to propose yet another open source permutation for you to consider, but I think it’s a lightweight one.
Let’s say your rules use cases are simple and you’ve got a small, engineering-driven environment
Let’s say you’ve got just a few rules you ever need to execute. The rules, which are written in DRL, are authored and maintained by the engineers, not business people. Given this, you believe all you really need is the open source Drools execution engine. But, you’ve got a bursty environment where you can suddenly have a lot of data show up that you want the rules engine to operate on. So you don’t want to run it embedded in your other code.
For this, may I propose immutable Docker containers running the Drools execution engine and either a REST-based or JMS-based messaging microservices entry point? Something like what Mauricio Salatino proposed.
Immutability, Docker, Drools, and (maybe even) Kubernetes might simplify things for you
Sure, my proposal means you’d lose a ton of the services that the Drools and jBPM team have worked hard to produce, but you’d buy some simplicity and possibly a different kind of scalability.
The developer’s architecture would be simple. The workflow for the developer would be as easy as modifying the DRL files, unit testing, and then committing. Ideally, you’d have Jenkins or Bamboo building the code, running integration and automated acceptance testing (may I suggest Cucumber for Drools??), and then build and push the Docker image.
The runtime architecture would be simple too. The server would pull the latest Docker-based runtime. The runtime would operate on the facts it receives from the microservice entry point. The DRL would be baked right into the container. Immutability.
To those on the leading edge, this proposal won’t shock you. But I thought it was worth writing up since I didn’t see anything else like it.