Microservices and Rules Engines – a blast from the past - Udi Dahan

Search service, price service, risk service – when you model them as services, you end up with a tangled web of dependencies between them and almost all the other services in your system – a horrible distributed monolith.

There’s a reason for that – they were never meant to be services in the first place. Join Udi for a blast from the past looking at how rules engines can fit in the missing dimension of your Microservice architectures. Things will look very, very different.

NDC Conferences

[KilgoreTroutAsf]

It's almost as if the actually interesting and challenging parts in programming and computer science in general are cross-cutting concerns that can't be tidily encapsulated according to the management ideology in fashion and the remaining is trivial boilerplate code.

[RationalWe]

This talk. clarifies the concept of Microservices.

[danielbarnes]

0:41 "I tend to take a contrary viewpoint." One of the reasons I like Udi :)

[bricol]

Good talk! Have applied these rules since 2012 and they work.

[p]

Great talk! This applies to any application development (web api, desktop app, etc). Sadly, many developers always just applies the n-tier layer architecture without understanding the domain or features required.

[alandmcleod]

This is good. This is a really good talk. Excellente!

[harsha]

When we deploy these components/assemblies together as a single deployment create a dependency in terms of release upgrades.

[mhandle]

Basically, rules engines mean here the Command design pattern on the deployment level.

[TheInsaneBrother]

So basically it's dependency inversion on a service-level.

[lasindunuwanga]

I could say "well said" for lots of things said in this video

[roodborstkalf]

Very interesting, especially the last fifteen minutes

[vuralmecbur]

Good talk, to the point and concrete.

[NotARealPerson]

Excellent on first half of the presentation, but it went all the way down after that. Putting search aside which is a very specific problem that requires very specific solution, the other two examples are also too vague. The so called rules engine pattern looks just like pipe and filter pattern to me unless I missed something here, and how it's to be implemented from microservice perspective is not mentioned and forgive my slow brain but I can't imagine how it can be implemented without a commonly understood contract which will introduce coupling again.

[NathanPrice]

I thought for years SOA was several jars that were deployed to separate jvm containers. I'm a java developer. Not until I went to my next job and they had all the service in one app or monolith. Did I realize how wrong you could write SOA. We were writing microservices in 2010

[LoiNguyen-tlsy]

Thanks for this talk. But after listening I didn't get how rule engine works with microservices

[thatpaulschofield]

Do the rules engines themselves belong to the IT/Ops service?

[brianszymanski]

Using interfaces to separate concerns is great. And maybe that will work fine for pricing or fraud scoring. But for search your approach will not scale past a few thousand objects. Even if google has spoiled us, indices exist for a reason, and searching is more than filtering.

You say that searching is as simple as implementing a filtering interface, which ignores sort order and pagination, but let's put that aside for now. Even if we treat searching as equivalent to filtering alone, with your approach how could we search across millions of products for all that have, for example a user-input color and size? Well, we have to call each of those services and ask them for all of the products matching some criteria they own. Then we have to take the intersection of their results. This means we will be copying a few million IDs around, most likely 128-bit UUIDs, potentially across the network. This will be untenable as the product space and the number of variations grows. By the time you get to ten million products and 30 services, we're talking about a gigabyte of data being copied from service to service. Even in RAM, that's a tall ask.

And what of sort order? If I want simple sort orderings (eg ORDER BY price ASC, rating DESC), we can have that logic live in the corresponding service, perhaps as an optional parameter, and make sure our merging logic preserves order. But what if I want a sort order that is more complicated, that takes some function of price and rating and other parameters, so that the customer can see a mix of cheap products and highly-rated products? That sort logic can't live in the child services, because eg the price service has no idea about ratings and vice versa. Such functionality simply cannot be done with a filtering interface alone; we need a way to see both at the same time, and convert those properties in to numeric values. So maybe the filtering interface returns the data as well, but then we're copying even more data back and forth between services. Or maybe we pass a list of venues in to some sort order scoring service or services, but again, more copying data back and forth - performance will be poor.

Maybe I'm missing something, but it seems to me like you reached a little too far here.

[daniellaidlow]

Are we ever going to see the NDC Sydney 2017 videos? There's a playlist but it's full of deleted videos....

[MuharremGorkem]

It took too long to set the context for rule engines and when it came to it, it was mentioned too generically, like any other component that uses other service's sub-components... The presentation was so good, though and that is why I avoid labeling it "click-bait" via "rule engines"...

[TheInsaneBrother]

If search is not a service, where is the code that coordinates a search and calls all dependencies?