5 ms·

The biggest problem with FSMs (or generally actors, or more generally distributed systems, microservices, etc.) is that you get emergent complex global behaviou

by gosubpl 11y ago

The biggest problem with FSMs (or generally actors, or more generally distributed systems, microservices, etc.) is that you get emergent complex global behaviours from seemingly simple actor rules. There are two excellent talks on that by Torben Hoffman from Erlang solutions: http://www.infoq.com/presentations/erlang-async-protocols http://www.infoq.com/presentations/erlang-async-protocols and http://www.slideshare.net/torbenhoffmann90/2014-12ndcthinking http://www.slideshare.net/torbenhoffmann90/2014-12ndcthinkin... . Also, worth noting, Paxos pseudo-code is only 25 lines of code for all participating actors: http://nil.csail.mit.edu/6.824/2015/notes/paxos-code.html http://nil.csail.mit.edu/6.824/2015/notes/paxos-code.html but it took quite a while for the community to verify that this code is actually correct for all cases.

mwilcox 11y ago
I'd say those are features of agent-based systems as opposed to problems. But it depends on the application
- gosubpl 11y ago
  Features, yes, provided one has time to actually think of the protocol and express it in terms of some formalism (CSP, TLA+) to at least informally sketch a proof of major global properties. Or do some extensive testing (https://aphyr.com/posts/291-jepsen-zookeeper https://aphyr.com/posts/291-jepsen-zookeeper https://aphyr.com/posts/316-jepsen-etcd-and-consul https://aphyr.com/posts/316-jepsen-etcd-and-consul ).
- api 11y ago
  We are possibly one such emergent behavior in an agent based system, as are bees and fish and trees and whales. So yes. :)
lostcolony 11y ago
I've seen this in practice, but it begs the question (and it might be answered in the talks): what is the alternative? That is, I have this corpus of rules and behaviors that I can express as an FSM...is there a better way of expressing it, given that I actually need something that behaves according to them?
- marcosdumay 11y ago
  If you have more than one layer with implicit mutable state, you are up for emergent behavior. It is not limited to FSM. But FSM are just too easy, so people often use it to make implicit some state that would be explicit otherwise. In this sense, yes, they do cause emergent behavior. The alternatives are joining your state at a single layer, making sure your states are really orthogonal to each other (very hard if both do IO), or making your state explicit so that you can at least verify once you find a problem.
  - ArkyBeagle 11y ago
    So don't make state implicit. This is critical. Orthogonality is just something you do. I've found it offends some people, but it works and generally, their way doesn't. But the founding principle is "trust no one" in distributed systems.
    - marcosdumay 11y ago
      I wouldn't put it that black on white. Orthogonalising implicit state is just great for managing complex behavior. It's a very powerful tool, and it can be made foolproof on lots of cases. But if two layers do IO, you'll almost certainly want the state to be explicit.
      - ArkyBeagle 11y ago
        I don't think foolproof costs all that much, especially if it's habit. YMMV. I have a BluRay player with Java(tm). If it sits more than a day or twenty, I have to unplug it, count to ten and plug it back in. I have a TV that has seizures - loud, painful seizures ( that always test the ability of an amp connected to it to defend itself ) . Scares the crap out of the dogs. This is not necessary. This is not good.
- galangalalgol 11y ago
  As another comment below points out, any non trivial software contains FSMs but they can express it in any number of ways. Haskell trying to avoid mutable state would probably pass around a constant data structure recursively through a series of pure functions. I find explicit FSMs difficult to reason about and find pure functions operating on complicated data structures much easier to reason about. It is irrational to conclude there is one clearest representation for everyone even within a single problem space. Experiment, find the one that suits you and show understanding to those who think and learn in other ways.
arielb1 11y ago
The complicated part of Paxos is not these 25 lines of code, but all the extensions people add over them.
jonahx 11y ago
> The biggest problem with FSMs (or generally actors, or more generally distributed systems, microservices, etc.) I'm intrigued by this sentence. Can you explain how actors and microservices are a generalization of FSMs?
- theseoafs 11y ago
  I think you misread OP's sentence. Actors and micro services are not really related to FSM's. You can make services and actors which can be modeled as FSM's but they don't have to be.
  - skewart 11y ago
    I'd say it really comes down to whether your actor or microservice has any statefulness or if it's idempotent. If you have a database behind your microservice, or some kind of in-memory cache, where you ever modify values instead of just writing and reading them then there's a good chance it's an FSM. On the other hand if it's purely functional - say, it just returns a thumbnail image for any photo you give it - then it's not really an FSM. From what I've seen an awful lot of microservices out there have some amount of state (not sure about actors). I think that's why the author made the generalization.
ArkyBeagle 11y ago
But this is nothing more than a variation on the Two Generals Problem for distributed systems. Given an FSM and a set of messages, and a model of timing, it may be possible to fully test out the most interesting subset of transactions and test out many of the pathological cases. But instrumentation in anticipation of finding unanticipated pathological cases is pretty important. This is bounded by cost, just as all due diligence processes are. Well-designed instrumentation is the key. FSMs are not the problem here - with infinite bandwidth channels and perfect transmission, you wouldn't even need all that.
petra 11y ago
On the other hand, hierarchical-state-machine (like FSM, with hierarchy), are often used in embedded systems(including safety-critical systems) and are considered among the more reliable and bug-free methodologies. So maybe we shouldn't rule-out FSM's but be subtle in their use ?
- AstralStorm 10y ago
  Better still, why not use maths and convert FSM into mathematical proofs? It is automatic if the FSM is fully specified and the semi-automatic part could catch insufficient specification. (to borrow words from reply above: certain kinds of implicit state and assumptions on the platform) Something like Isabelle/HOL etc.

by gosubpl 11y ago

mwilcox 11y ago

I'd say those are features of agent-based systems as opposed to problems. But it depends on the application

gosubpl 11y ago
Features, yes, provided one has time to actually think of the protocol and express it in terms of some formalism (CSP, TLA+) to at least informally sketch a proof of major global properties. Or do some extensive testing (https://aphyr.com/posts/291-jepsen-zookeeper https://aphyr.com/posts/291-jepsen-zookeeper https://aphyr.com/posts/316-jepsen-etcd-and-consul https://aphyr.com/posts/316-jepsen-etcd-and-consul ).
api 11y ago
We are possibly one such emergent behavior in an agent based system, as are bees and fish and trees and whales. So yes. :)

lostcolony 11y ago

I've seen this in practice, but it begs the question (and it might be answered in the talks): what is the alternative? That is, I have this corpus of rules and behaviors that I can express as an FSM...is there a better way of expressing it, given that I actually need something that behaves according to them?

marcosdumay 11y ago
If you have more than one layer with implicit mutable state, you are up for emergent behavior. It is not limited to FSM. But FSM are just too easy, so people often use it to make implicit some state that would be explicit otherwise. In this sense, yes, they do cause emergent behavior. The alternatives are joining your state at a single layer, making sure your states are really orthogonal to each other (very hard if both do IO), or making your state explicit so that you can at least verify once you find a problem.
- ArkyBeagle 11y ago
  So don't make state implicit. This is critical. Orthogonality is just something you do. I've found it offends some people, but it works and generally, their way doesn't. But the founding principle is "trust no one" in distributed systems.
  - marcosdumay 11y ago
    I wouldn't put it that black on white. Orthogonalising implicit state is just great for managing complex behavior. It's a very powerful tool, and it can be made foolproof on lots of cases. But if two layers do IO, you'll almost certainly want the state to be explicit.
    - ArkyBeagle 11y ago
      I don't think foolproof costs all that much, especially if it's habit. YMMV. I have a BluRay player with Java(tm). If it sits more than a day or twenty, I have to unplug it, count to ten and plug it back in. I have a TV that has seizures - loud, painful seizures ( that always test the ability of an amp connected to it to defend itself ) . Scares the crap out of the dogs. This is not necessary. This is not good.
galangalalgol 11y ago
As another comment below points out, any non trivial software contains FSMs but they can express it in any number of ways. Haskell trying to avoid mutable state would probably pass around a constant data structure recursively through a series of pure functions. I find explicit FSMs difficult to reason about and find pure functions operating on complicated data structures much easier to reason about. It is irrational to conclude there is one clearest representation for everyone even within a single problem space. Experiment, find the one that suits you and show understanding to those who think and learn in other ways.

arielb1 11y ago

The complicated part of Paxos is not these 25 lines of code, but all the extensions people add over them.

jonahx 11y ago

> The biggest problem with FSMs (or generally actors, or more generally distributed systems, microservices, etc.) I'm intrigued by this sentence. Can you explain how actors and microservices are a generalization of FSMs?

theseoafs 11y ago
I think you misread OP's sentence. Actors and micro services are not really related to FSM's. You can make services and actors which can be modeled as FSM's but they don't have to be.
- skewart 11y ago
  I'd say it really comes down to whether your actor or microservice has any statefulness or if it's idempotent. If you have a database behind your microservice, or some kind of in-memory cache, where you ever modify values instead of just writing and reading them then there's a good chance it's an FSM. On the other hand if it's purely functional - say, it just returns a thumbnail image for any photo you give it - then it's not really an FSM. From what I've seen an awful lot of microservices out there have some amount of state (not sure about actors). I think that's why the author made the generalization.

ArkyBeagle 11y ago

But this is nothing more than a variation on the Two Generals Problem for distributed systems. Given an FSM and a set of messages, and a model of timing, it may be possible to fully test out the most interesting subset of transactions and test out many of the pathological cases. But instrumentation in anticipation of finding unanticipated pathological cases is pretty important. This is bounded by cost, just as all due diligence processes are. Well-designed instrumentation is the key. FSMs are not the problem here - with infinite bandwidth channels and perfect transmission, you wouldn't even need all that.

petra 11y ago

On the other hand, hierarchical-state-machine (like FSM, with hierarchy), are often used in embedded systems(including safety-critical systems) and are considered among the more reliable and bug-free methodologies. So maybe we shouldn't rule-out FSM's but be subtle in their use ?

AstralStorm 10y ago
Better still, why not use maths and convert FSM into mathematical proofs? It is automatic if the FSM is fully specified and the semi-automatic part could catch insufficient specification. (to borrow words from reply above: certain kinds of implicit state and assumptions on the platform) Something like Isabelle/HOL etc.