This is fantastic. I’ve always enjoyed the cypher language that the neo4j team created for querying graph data. The connected k8s api objects seem like a great place to apply that lens.
Whether or not that is the case, surely the substance of the article more worthy of your analysis than something as intangible as the authors internal motivations? Assuming positive intent is worthwhile frame of reference that keeps my world looking a bit brighter and something I always hope other do for me.
> Any principal in your management account, by default, is able to assume the OrganizationAccountAccessRole in each and every one of the accounts created using the organizations:CreateAccount API.
This is an untrue statement. For a principal in the management account to assume OrganizationAccountAccessRole, they need to have a principal-based policy that gives sts:AssumeRole permissions for it. Otherwise, great article. We use this pattern at $DAYJOb
I think this feature lends itself well to tight feedback loops, as you said. However, after I crossed the painful divide from CloudFormation novice to... well, whatever is after that, CloudFormation rollbacks became a friend instead of an enemy. The ability to return to the last known good checkpoint is a powerful feature that is extremely useful in production systems and the pipelines that deploy them. In those scenarios, you're not experimenting and learning, but enhancing and evolving existing infrastructure.
Copilot generates CloudFormation templates based on the Copilot-specific config files. There’s a place where you can add your own additional resources in CloudFormation syntax IIRC. It also has the ability to create a CodePipeline for app deployment. That creation is also done by generating a CloudFormation template and deploying it for the user. I’m not sure why it’s not clearly documented that this is happening, but it is a selling point to me because if I want to, I can “eject” from Copilot and just maintain/enhance the CloudFormation templates.