rodrigorcs

7 ms·

1.
by rodrigorcs 7mo ago
This is incredibly generous context... thank you. A few of these hit close to problems I'm thinking about. The Decider pattern you're describing (reading keys from memcache to decide behavior at runtime) is essentially what Openfu
2.
by rodrigorcs 7mo ago
I know this sounds weird, but it is in fact self-hosting first :) The reason why I only launched the cloud version of it is just so I could have a faster iteration pace in the back-end after having people actually using it reliably. Now it
3.
by rodrigorcs 7mo ago
> I don't really see what problem this solves. If you have proper timeouts and circuit breakers in your service this shouldn't really matter. Each service discovering by their own is not really the main problem to be solved wit
4.
by rodrigorcs 7mo ago
You're right, for intra-cluster calls where failures are scoped between the node itself and the infra around it, per-instance breakers are what you want. I wouldn't suggest centralizing those, and I might be wrong, but in most of
5.
by rodrigorcs 7mo ago
Great question. Openfuse has a "systems" concept for exactly this. Each system is an isolated unit within an environment with its own breaker state. So you'd have us-east/stripe and eu-west/stripe as separate breake
6.
by rodrigorcs 7mo ago
Feel free to take a look at the SDK code if you want to, it's open :) https://github.com/openfuseio/openfuse-sdk-node
7.
by rodrigorcs 7mo ago
It makes the awareness global so instances stop independently hammering a service that the rest of the fleet already knows is down. You can always override manually too and it will propagate to all servers in <15s
8.
by rodrigorcs 7mo ago
Yup, that is true for both Cloud and Self-hosted, it never blocks any executions by any external factors other than the breaker is KNOWN as open. The state sync and the hot path are 2 completely separated flows.
9.
by rodrigorcs 7mo ago
Good question, that's exactly why the trip decision isn't based on a single instance seeing a few errors. Openfuse aggregates failure metrics across the fleet before making a decision. So instance 7 seeing a brief hiccup doesn&#x2
10.
by rodrigorcs 7mo ago
Totally possible, and some teams do. You need a state store, a evaluator job, a propagation layer to push state changes to every instance, a SDK, a dashboard, alerting, audit logging, RBAC, and a fallback strategy for when the coordination
11.
by rodrigorcs 7mo ago
I agree with more of this than you might expect. On-prem: You're right, and it's on the roadmap. For teams at the scale you're describing, a hosted control plane doesn't make sense. The architecture is designed to be dep
12.
Show HN: I built a fuse box for microservices(openfuse.io)
28 points by rodrigorcs 7mo ago|23 comments
13.
by rodrigorcs 7mo ago
Really interesting idea! I've only seen stuff like that in ETL pipelines (which are a pain). This sits somehow between a python notebook and a ETL pipeline. By the way, I just shared in my company's Slack and looks like there is n
14.
by rodrigorcs 7mo ago
I've been building Openfuse ( https://openfuse.io ), a centralized circuit breaker platform. Started building it about a year ago after dealing with the same problem across multiple companies: circuit breakers scattered acros