Skip to content
Notifications
Clear all

Unpopular opinion: Anomali's UI is a 2012 relic and it slows analysts down.

3 Posts
3 Users
0 Reactions
0 Views
(@git_ops_guy)
Reputable Member
Joined: 4 months ago
Posts: 230
Topic starter   [#24559]

Just tried to demo the Anomali ThreatStream platform for our security team. The UI feels like it hasn't had a meaningful CI/CD pipeline in a decade! 😅

Every click has noticeable lag. Simple navigation, like pivoting from an indicator to related campaigns, involves multiple page reloads that break analyst flow. Compare this to a modern GitOps dashboard like Argo CD's UIβ€”real-time sync status, filter-as-you-type, single-page app responsiveness. For example, a typical analyst workflow to investigate an alert could be scripted in a modern framework to be near-instant. The time spent waiting for pages to load adds up across a team.

I wonder if their backend is monolithic? A move to a service-oriented architecture with a proper frontend CI pipeline (think GitHub Actions building React/Vue) could do wonders. Has anyone managed to improve the experience with custom integrations or are analysts just gritting their teeth?

> git commit -m 'done'


git push and pray


   
Quote
(@data_pipeline_newbie_42)
Estimable Member
Joined: 4 months ago
Posts: 137
 

Yeah the lag is real. I noticed it too when I was testing API calls - even simple GET requests took way longer than other tools.

Could it be a backend data model issue? Like maybe they're doing too many joins on huge tables for each page load. A service-oriented split might help, but I wonder if they'd need to refactor their whole data layer first.

Has anyone tried accessing everything through their API instead of the UI? Might be faster for scripted workflows.



   
ReplyQuote
(@davidl)
Estimable Member
Joined: 3 weeks ago
Posts: 100
 

The API latency you're measuring is the real smoking gun. If even simple GETs are slow, the problem isn't just a monolithic frontend. It's systemic.

Your data model hypothesis is likely correct, but I'd add that inefficient queries are often compounded by a lack of proper caching layers. A microservice split won't fix a table scan on a billion-row indicators table. They'd need aggressive read replicas and materialized views for common pivots, which is a massive data layer refactor as you said.

Scripting via the API is a workaround, but you're just moving the waiting time into your script's runtime. It doesn't solve the root cause for interactive analysis.


Benchmarks or bust


   
ReplyQuote