Deprecate Terraform, Add OpenTofu, Add CloudFormation, Add CDK, Add Helm #985
Conversation
These fundamentals rarely change. Whilst we can always add stuff ad-hoc and bump the date, the requirement for review should not be necessary for about two years.
|
|
||
| If your environment consists of a simple deployment artefact like an [Amazon Machine Image (AMI)][], Puppet may not be necessary, but the process for building that artefact must still be codified and version controlled. | ||
| The use of [Puppet][] at GDS is diminishing as we move more of our infrastructure to containers and higher level | ||
| services. It is mainly still in use on [GOV.UK](https://github.com/alphagov/govuk-puppet) but this will decline as more |
There was a problem hiding this comment.
GOV.UK are now off puppet, so you may delete this bit too if you like. Or leave it and I'll do a separate update
|
Are there any teams in GDS who are currently using OpenTofu? I'm wary of swapping out Terraform to OpenTofu in our guidance if we don't have the evidence to back it up, you know? |
|
My principal concerns around moving to OpenTofu would be:
Concerns about remaining with Hashicorp Terraform:
|
|
The DI ADR in question is here https://github.com/govuk-one-login/architecture/blob/main/adr/0042-use-of-sam-and-cloudformation.md and would need a bit of an update. (edit: should've actually read this properly before commenting. Basically I agree with this, it's a better balance than we have now in the GDS Way 👍 ) |
|
How would others feel about me adding some warmer words on the AWS CDK? It's what we use in the (formerly CDDO) Domains Team. It probably wouldn't have been my first choice but it does have some real things to commend it. It means we're an entirely Python household. Bootstrapping is trivial. It laughs in the face of cross-account zone delegation and other, otherwise knotty jobs. EDIT: thanks to @AP-Hunt for putting me on to this discussion. |
|
Terraform may no longer be the new kid on the block, but it is the industry standard. Concerns for me;
|
| Amazon Web Services provide two tools in the field of IaC. [CloudFormation] being more traditional YAML manifests or | ||
| [CDK] being more of an SDK library for developers to program their way into configuration. | ||
|
|
||
| Both are limited to only cover AWS infrastrcuture, and woould not be much use outside of that echosystem - for instance, |
There was a problem hiding this comment.
| Both are limited to only cover AWS infrastrcuture, and woould not be much use outside of that echosystem - for instance, | |
| Both are limited to only cover AWS infrastructure, and would not be much use outside of that ecosystem - for instance, |
| [CDK] being more of an SDK library for developers to program their way into configuration. | ||
|
|
||
| Both are limited to only cover AWS infrastrcuture, and woould not be much use outside of that echosystem - for instance, | ||
| configuring GitHub or Dynatrace would require you to invest in additional tooling such as [OpenTofu]. |
There was a problem hiding this comment.
This could be investigated for dynatrace
https://github.com/aws-ia/cloudformation-dynatrace-resource-providers
This Pull Request intends to spark some conversations among the tech community.
TODO