Hacker News Reader

Comment by gosubpl | Hacker News Reader

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 and 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 but it took quite a while for the community to verify that this code is actually correct for all cases.

View on HN

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?

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.

Erlang is doing exactly what you're saying here.

The mechanism for learning to think in state machines is message sequence charts. For each state there is usually a short list of Things That Can Go Wrong ( timeout, race condition, garble, inappropriate message ).

Ya gotta think like a clockmaker.

You are right - while there may be a simpler FSM that is equivalent to the one you have, the irreducible complexity that can arise from apparently simple rules is a feature of the problem domain. FSMs are part of the solution domain, and the best you can hope for in the solution domain is to avoid making things more complicated than they have to be. That does not rule out there being alternatives to FSMs that are easier to reason about.

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.

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.

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.

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.

it begs the question: what is the alternative?

Here is one: https://news.ycombinator.com/item?id=11418855 (intended as a reply to your question but accidentally posted to the thread)

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.

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

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/316-jepsen-etcd-and-consul ).

We are possibly one such emergent behavior in an agent based system, as are bees and fish and trees and whales. So yes. :)

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 ?

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.

> 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?

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.

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.

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

Reply on news.ycombinator.com