OpenCredo

CloudFormation covers all AWS features in full detail. OTOH, you end up reading and editing tons and tons of JSON that were never meant for human consumption. I don't know what goals Amazon had when they came up with CF, but if human readability was one of them, then they've failed that goal.

I've seen a lot of people start writing their own CF management systems, in Python or whatever, and end up with a lot of infrastructure defined in the logic of the homegrown management tool - like a badly written PHP page where presentation and logic are all mixed up. You see that once, you never want to go there again.

Terraform does not cover all AWS features, but the exceptions are few and tend to be lesser used features. The file format is human readable (this is subjective to some extent), and can be composed and modularized easily.

https://opencredo.com/terraform-infrastructure-design-patterns/

https://github.com/hashicorp/best-practices

https://atlas.hashicorp.com/help/intro/use-cases/multiple-environments

https://www.terraform.io/intro/getting-started/modules.html

https://www.terraform.io/docs/state/remote/index.html

I'm not a big fan of buzzwords and soundbites, but Terraform comes pretty close to fulfilling the ideal of "software-defined infrastructure" in a way that is accessible, easy to use, easy to expand, and just makes sense - in the way a good programming language just makes sense.

After implementing an ACL system with permissions inheritance for child nodes, I'm of the opinion that it's not really something that can be written by humans efficiently. Not to say that the concept is bad, just that it touches on so many things that it should probably only be attempted by way of a framework (which largely doesn't exist, at least not universally, so kudus to ladon for trying).

For anyone struggling with permissions, it might be easier to think about them in terms of which actions are available to a user at each endpoint, something along the lines of this with HATEOAS and filtering links:

https://opencredo.com/designing-rest-api-fine-grained-resources-hateoas-hal/

A few things that ACLs can potentially break:

* PUT/PATCH requests: every relationship (and every attribute if using field-level security) of every resource needs permissions checks

* Database consistency: if logic is too complex to put in triggers, then permissions table can get out of sync with roles

* Russian doll caching (and caching in general): views now vary by user based on what subviews are visible

There are so many ramifications with permissions systems that it's worth implementing them early on in your project if you know you'll need them, or approaching them from a different angle like how Firebase rules are implemented declaratively and inherited per-resource.

I'm the article author, and it's great to hear your feedback! I've published a couple of other articles that may help with the topic of microservices:

https://opencredo.com/javaone-building-a-microservice-development-ecosystem-video/

https://opencredo.com/the-seven-deadly-sins-of-microservices-redux/

I'm also looking for more suggestions of how people will want to use Hoverfly with Java projects, and so please do give me a shout via twitter @danielbryantuk if you have any ideas!