I’m not a huge fan of YAML in general, but I do see it being useful for situations when a structured configuration language is needed. Something for which JSON would normally be used, but where human readability and maintainability is important.
What I don’t like is seeing YAML being used as a way to define a sequence of actions. I complained about Step Functions, but just as annoying is the various CI/CD services that use YAML as the means of defining the build sequence. Encoding a sequence of actions — complete with branches, loops, callouts, and error handling — using a language geared towards configuration is clunky at best, and I’m always curious as to why vendors choose to use it when a language more fit for purpose would be nicer to work with. (This rant is going to be about YAML but using JSON in these situations is just as bad, if not worse. At least YAML has comments).
The problem is that it never remains this simple. As time goes on, and people continue to use your system, their expectations of the system begin to grow. It eventually comes to the point where the single list of actions is not enough. Now you need to consider actions that should only run when a certain condition is met, or actions that should run when another action fails.
So you extend your YAML language. You add guards to your actions which will only run when the condition is true, or start adding catch clauses to the actions to jump to another one when an error occurs. You begin defining bizarre expression languages on top of your expanded YAML representation that never look quite right, and special fields on actions with act effectively like goto’s. Eventually, you ship that, and for a while your users are happy, but not for long. They want variables, or actions that run multiple times or over a set of items, or the ability to call out to other actions in another workflow so they don’t have to copy-and-paste, and on and on. One day, you wake up and you realised that you’ve accidentally built a Turing complete programming language. The only problem is that it’s written in YAML.
So what’s the alternative? I’d argue something that resembles a proper, Algol-type programming language is a superior method of representing these workflows. There are many benefits of doing so: the logic is clear, one step follows the other as you flow down the page. There are already standard conventions for indicating branching, loops, error handling and call-outs. And there’s a lot less line noise as you’re not mixing your logic in with your data and configuration.
In any case, it doesn’t need to be this way. We shouldn’t need to encode our logic using a configuration language. We already have better facilities for doing this: called programming languages. I hope that next time a vendor wishes to build something that has a feature like this, they consider designing one instead of using something not quite fit for purpose like YAML.