Hacker News Reader

Comment by hacker_9 | Hacker News Reader

"This document describes a JSON-based language used to describe state machines declaratively. The state machines thus defined may be executed by software. In this document, the software is referred to as “the interpreter”."

Oh no.

View on HN

Everything old is new again.

So, now that it is happening to me, am I allowed to apologize to the numerous old-coders that tried to tell me this when I was coming up?

If you've seen this before, I'd love to know what came next last time. How did this evolve and what were the issues with it?

Tooling. IDEs and special languages to generate the files for the state transitions, and the body of the lambdas themselves. (reading this kind of made me want to go write a little haskell dsl)

If they're a little undisciplined, they'll probably add stuff to implement counting and comparison directly, to put a hard limit on loops.

I'd also guess an addition of a couple special tasks, perhaps append to log in s3 bucket and continue, that perhaps come with a discount.

There are about 3 million old flowchart tools out there, any feature you see tacked on is a candidate.

Tangentially, other organizations will be inspired by this, and implement their own language in json, but this time they'll do it "the right way" then you'll get a working group to try to reconcile all the competing standards.

Or maybe not. kind of what happened with XML though.

edit

ah, here you go. https://www.w3.org/TR/scxml/ that stuff.

Yes you must :-)

It would be fun to implement Zork with this system.

You are in a twisty little maze of [standards], all alike.

In explaining the choice of JSON as the description language for state machines Tim Bray briefly said, "I couldn't find a good reason not to express it as JSON and in this day and age, you need a good reason for it to not be JSON."

He also mentioned that because it was a formally specified syntax, you could, should you choose to, build other more convenient syntaxes that reduce to it. It won't surprise me to see that happen fairly quickly.

He should talk with the Cloud Formation team about their reasons for supporting(it's a full shift in reality) YAML.

Fun Fact: json is a subset of yaml.

Last one to implement x86 on this is a rotten egg.

Everything at Amazon is like this. You should try to use cloud formation.

As verbose as cloud formation is, I really like it. You can represent the entire state of your architecture in a single JSON file: VPCs, EC2 instances, Elasicache clusters, security groups, IAM roles, everything. Updates to the cloud formation template are atomic and can be rolled back, saves you the trouble of writing a long runbook to install your system, and your template can be kept in version control.

You want to talk weirdly over-engineered, check out SWF

SWF is awesome, but it can feel very abstract for most use-cases. In light of this, one of my good colleagues wrote a library called Super Simple Worfklow. It provides the level of simplicity that one would have expected from SWF to begin with. We opened sourced it at my company, check it out[1]. We use this library for production services.

(Full disclosure: I work at Bazaarvoice, and my colleague does, too!)

[1]: https://github.com/bazaarvoice/super-simple-workflow

The user interface of SWF looks like it is the most neglected thing in AWS. Faar too much whitespace and crappy layout makes navigating it a real PITA.

The Step Functions UI on the other hand is really rather intuitive.

They really need to improve the SWF UI

BTW, the Step Functions product that interprets this uses the SWF bsck-end.

Nice! SWF is sadly an under-utilized service outside of Amazon - great to see more accessible abstractions being built on top of it. We wrote a simple abstraction around SWF to make is easier to work with:

https://github.com/swift-nav/wolf

Excited about the potential of using lambda functions with SWF - we have workflows with predominantly idle workers that would greatly benefit from it!

We break our cloud formation stacks up and reference the outputs of those stacks in consuming stacks. You have a VPC, IAM, IAM policy, security group, network acl, and then your application stacks. So, if you have an application that references a security group from it's respective stack and you want to change those rules, you just update the resource in the security group stack and the application stack never needs to get updated. (edit: by separating stacks I mean that they live in different templates, not just different stacks in one file)

I don't quite see the advantage. If you update a stack it will only do the minimal required changes. So if you have an EC2 instance and a security group defined in one stack and you update the security group the EC2 instance won't be affected, it's not like it would be shut down and an identical one would be spun up.

What does breaking it up like that give you?

Late reply, but mainly shared resources like security groups (like a specific security group for NTP or HTTP/S), IAM roles, DB's, Kinesis streams, etc. The other reason being the limit on template length. You can't spec out a 3-tier VPC with network ACLs and security groups in a single template.

So JSON has officially Jumped The Shark (like XML)

Seems like a decent way to glue AWS Lambda functions together?

Why: "oh no"?

Why?

Reply on news.ycombinator.com