[erlang-questions] Erlang and Rules Engines / Production Systems

[Garrett Smith]

I've used Erlang for quite a few rules engines - but they're all
purpose built and not intended to be a generalized solution. That
said, purpose built rules engines are super simple to build Erlang.

If someone approached me with a problem like "we need an rules engine"
I'd certainly point them to the Java space. That's full of management
pleasing products that promise strategic value. Drools of course is
the established player for open source.

Before I started looking around for another job, I'd push back and ask
the powers what problem do they actually have - the one that makes
them think they need a rules engine. There's something that's real and
not abstract. Use Erlang to tackle that directly. Just hard code the
rules for the time being - it's easy to move them outside the program
as config - and when people complain that they can't edit the cryptic
Erlang term syntax, introduce a rules compile phase that takes
Markdown defined rules - or better, Yaml - and generates the Erlang
config.

When the next real problem manifests, do that again. Over time you
might start to see some patterns that you can generalize. You may run
into performance problems that drive you to use esoteric data
structures and algorithms. Or maybe you can get by with ridiculously
naive, unclever code.

I've found this approach leads to effective software that's very small
for any given problem. I really try hard to avoid the need for
something like a "rules engine" or a "business process enactment
engine'.

If a business user says, "hey this is great, but we really need to be
able edit these rules ourselves and push to production without IT
interference" - try one thing before looking for another job... assure
them that they will get this capability, but the organization will get
there incrementally rather than in one step. If they say, "thanks but
we just got back from Garter BPM Summit and we need this yesterday"
then use Drools, or iLog, or Pega. You don't want Erlang.

The promise of Erlang is production awesomeness. If you haven't put an
Erlang app into production and put it through a few maintenance
phases, it's hard to easily communicate how much better it is - in
terms of speed of implementation, service availability, and speed of
change. But part of the Tao of Erlang is directness of code - it's
harder than a lot of languages to create big layered abstractions.
There are a lot of established rules engine/BPM products laying around
and if that's what you really want, just pick something that's
established and skip Erlang for this one.

On Wed, Jul 15, 2015 at 3:13 PM, Josh Adams <josh.rubyist@REDACTED> wrote:
> Hi all,
>
> I'm in need of making a recommendation regarding a Business Rules Engine and
> am evaluating various open source and commercial projects for a customer.
> In the meantime, given the nature of this particular need, I'm realizing
> that it's possible I could build a DSL for generating an AST and pattern
> matching against it.
>
> I'm operating on the assumption that there are potentially 10s of thousands
> of rules in the system at scale, rather than hundreds or millions.  My
> personal goals are to be able to sustainably handle a decent amount of
> traffic via a webservice that can resolve all of these rules for a given
> input in around 2ms.  This is not a hard requirement, but it is the
> performance that the system needs.  10s of ms would be acceptable.  100s
> would be out of the question.
>
> I've not got anything more than tangential / play-style experience with any
> BREs.  At present I am evaluating Drools, which is Java-based and uses the
> Rete algorithm [1].  I am not yet sure whether it will meet my performance
> "requirements".
>
> On the Erlang front, I've seen at least ERESEYE[2]/sereseye[3] which are
> RETE+CLIPS and RETE-based versions.  I've not dug into them yet at all.
>
> I was curious if anyone on the list has experience with this in Erlang and
> had any pointers or real-life anecdotes regarding building such a system.
> It needn't be actually RETE-based, and in fact I would expect the newer
> algorithms to provide better performance.  Anyone have anything to share
> with someone furiously filling their mind with this stuff at present?
>
> Thanks in advance,
>
> -Josh Adams
>
> [1] Apparently actually something called RETE-OO -
> http://ieeexplore.ieee.org/xpl/login.jsp?reload=true&tp=&arnumber=5551128&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5551128
> [2]
> https://www.erlang-solutions.com/sites/default/files/trimedia/eresye_0.pdf
> [3] https://github.com/afiniate/seresye
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>