So a little background. We originally added the upstream EDA into the installer, but they kept breaking it. It seems like every other week they would add a breaking change upstream which would make the containers not start or something else not work (UI out of sync with backend). So eventually we just dropped it.
We were originally working on our own rebuilt of the upstream (the real reason for it being in the installer), but we were running into a lot of the same issues we have with Ascender. A large application with tons of dependencies, a lot of which were deprecated and need to be upgraded, and constant CVEs because of all those dependencies.
Rather than spend months and months fixing all the issues and dealing with an architecture that wasn't ideal, we decided to step back and re-envision how the product works. The decision engines, container system, and everything else were all slow and overly complicated and the design was definitely showing its age. Any change required starting and stopping containers, and things were flaky and tended to break often.
So instead, our product team started designing a new re-envisioned product from scratch with what we saw as the important aspects of any event driven system. And our engineers took their design and wrote it entirely in Go. So instead of these huge containers, for the UI you have a single go binary in an alpine container (full container is ~ 32 MBs), and then a completely distributed "listener" that can be ran in a container or as a standalone binary. The listener receives all the logs and can be located locally with your systems (no shipping logs across the pipe) and does all the processing and calling out to providers (completely autonomous if the web goes down). The whole process was simplified so that basically when a rule in your ruleset gets a match, it calls out to a provider (Ascender) to execute a job. The listener checks in to the UI, and receives new rules via a callback, so you get them near instantly and they immediately go into affect. For errors that you haven't created a rule for yet, there is a catch all logger that will log the event for review and even allow you to send it to any OpenAI API compatible LLM for analysis if you want (prompt is editable). I have mine sending to a DGX Spark, and it analyzes the error, gives me the most likely cause of the issue and writes me a rule to catch it and an Ansible playbook to either resolve the issue or diagnose it further. What it does not do (and never will) is let an AI touch the remote system. That could be disastrous.
Because the extensive amount of work that has gone into it, its part of our paid offering, Ascender Pro. We also created our Ascender Registry the same way (simple collection / container repository), and its a small 30 MB container vs the 770MB upstream. I was able to convince management to open source the Ascender Galaxy Proxy, and I am hoping in the future to convince them to do the same with the rest of the product line.
