Automation and State
To State or not to State
State
State its purpose.
That is a state matter.
It was a messy night. Alice was filthy. She was in a state.
The router had some state.
What to do with state
Automation is a constantly changing state of affairs. It raises questions like:
a) If a service or API is idempotent, do I have to track state?
b) Should my workflows consider external state?
c) Should I normalise state?
Idempotency
Something is said to be idempotent if it gives you the same response if you call it repetitively.
I always view idempotency quite simply.
- Bob makes a terrible mistake building a NETCONF server for Alice.
- Alice punished Bob with the task of hoovering the office floor.
- Bob starts hoovering at 3pm when Alice is out of the office.
- Alice Tweets Bob mid-hoovering (because they’re millennials) with “Bob, it’s time to hoover.”.
- As Bob is idempotent, Bob carries on hoovering and ignores Alice’s Tweet.
If Bob wasn’t idempotent, he might have packed away the hoover, gotten it back out and started hoovering again (also assuming Bob was actually delivering on his punishment and hadn’t outsourced it to a cleaner).
Can you imagine the Continue reading
Cato's security services sit in the cloud, rather than an appliance.
