Five worst things in AWS CloudFormation

CloudFormation is one of the AWS Services, that allows you to describe your infrastructure as a template (either YAML or JSON) and easily turn this descriptive form into a real, working AWS environment. Although it leads to vast reduction of point-and-click horror of traveling through Amazon Web Services Console, the CloudFormation itself has few rough edges. Everyone who uses this service should be aware of these tricky parts.

Here is the list of five worst things in CloudFormation, based on our experience:

Exceedingly long feedback cycle – developing templates locally and then doing validation is very inconvenient due to the need of validating created template with an external API which is singularly time consuming. Moreover mentioned validation is very preliminary because actual errors are popping up when we are trying to create resources from that template, so in the run-time, which is very late in the process. In effect it only wastes developer`s time.
Very hard to bootstrap – at the beginning. CloudFormation templates are overwhelming.The reason for this is that you need to provide a lot of structure from the very first step. After establishing the couple first templates, you simply “copy and paste” to start quickly which doesn't sound very productive in a long term. It is also a “bug friendly” approach. When you are trying to unify conventions, see what is written below.
As far as CloudFormation is concerned it is hard to enforce code conventions and consistency – to put it more simply – templates are human-friendly and human-readable configurations. It may become a tangled mess and a true maintenance nightmare if you do not implement any convention. In particular, when it comes to applying changes consistently everywhere e.g. unifying namings, enforcing policies and many other. All of these require manual work, so again you are losing your time!
It is also troublesome to get standardized approach and convention – referring to issue above, it is hard to get “the one true path” in standards for writing and structuring CF templates (e.g. how big or how isolated they should be). Amazon does not propose anything for now so we have almost like free-text possibilities. What is more, developers or companies are offering their standards.
Endless repetitions – we need to repeat constantly when writing it. It is error-prone as well as hard to maintain. YAML and JSON flavors do not support any fragments or smaller templating engine, so it is difficult to reuse and work in line with DRY (don't repeat yourself) principle.

With this subjective list we want to invite you – the users of the CloudFormation and all members of the community, to share your observations and encountered difficulties with this tool. You are more than welcome to give us your feedback in our repository on GitHub (github.com/Appliscale/perun).

Knowing all the above mentioned issues with CloudFormation we are working on the brand new tool that will make working with CloudFormation way easier. Stay tuned!

Here is the list of five worst things in CloudFormation, based on our experience:

Exceedingly long feedback cycle – developing templates locally and then doing validation is very inconvenient due to the need of validating created template with an external API which is singularly time consuming. Moreover mentioned validation is very preliminary because actual errors are popping up when we are trying to create resources from that template, so in the run-time, which is very late in the process. In effect it only wastes developer`s time.
Very hard to bootstrap – at the beginning. CloudFormation templates are overwhelming.The reason for this is that you need to provide a lot of structure from the very first step. After establishing the couple first templates, you simply “copy and paste” to start quickly which doesn't sound very productive in a long term. It is also a “bug friendly” approach. When you are trying to unify conventions, see what is written below.
As far as CloudFormation is concerned it is hard to enforce code conventions and consistency – to put it more simply – templates are human-friendly and human-readable configurations. It may become a tangled mess and a true maintenance nightmare if you do not implement any convention. In particular, when it comes to applying changes consistently everywhere e.g. unifying namings, enforcing policies and many other. All of these require manual work, so again you are losing your time!
It is also troublesome to get standardized approach and convention – referring to issue above, it is hard to get “the one true path” in standards for writing and structuring CF templates (e.g. how big or how isolated they should be). Amazon does not propose anything for now so we have almost like free-text possibilities. What is more, developers or companies are offering their standards.
Endless repetitions – we need to repeat constantly when writing it. It is error-prone as well as hard to maintain. YAML and JSON flavors do not support any fragments or smaller templating engine, so it is difficult to reuse and work in line with DRY (don't repeat yourself) principle.

Knowing all the above mentioned issues with CloudFormation we are working on the brand new tool that will make working with CloudFormation way easier. Stay tuned!