Ref Arch 2.0 vs Ref Arch 1.0

[ina-stoyanova]

1. The actual changes in the infra when we do the ref arch update is not documented anywhere. Consider the case of "vpc-app" upgrade documented https://github.com/gruntwork-io/infrastructure-live-multi-account-acme/blob/v0.0.1-20210527/_docs/_ref_arch_v1_to_v2_migration_guides/vpc-app.adoc It just says "You will notice the creation of two resources: aws_default_network_acl and aws_default_security_group. This can be safely ignored" , but no details about these two new resources. Do you have any documentation on all the infra changes between v1.0 and v2.0 for each module?
2. The documentation says, major advantages for doing upgrade are
   1. Don't have to maintain a local snapshot of the services, as we can directly refer to the service-catalog from the terragrunt.hcl file. We have several services where we create additional resources by adding our own terraform code inside these local "snap-shots of services" and these resources has direct dependency on the service that is being created using terragrunt modules. For example, while creating eks-cluster, we will create additional IAM roles that would be assumed by the k8s service-accounts. Is there anyway to manage these resources in v2.0 or do we have to create another module for those resources?
   2. All the infra upgrades can be done using a single version bump in the terragrant.hcl file : I believe we are doing the same now also, for any upgrades we are bumping the module version inside the local service folder , instead of terragrunt file.
      Am I missing something here?
3. Other than the improvements in the IAC , does v2.0 have any other benefits compared to v1 in security or reliability ?
4. Do you continue to support/maintain the v1 reference architecture code ( terraform modules) ?

[ina-stoyanova]

thanks @brikis98 for the thorough answers to this support request. I thought it was really useful content, so added it here!

Is there any documentation on all the infra changes between v1.0 and v2.0 for each module?

Yes, we document the changes in every release of every module on its releases pages. For example, the releases page for the VPC repo is at https://github.com/gruntwork-io/terraform-aws-vpc/releases. You can go through the release notes between any two releases to see what changed.

Is there anyway to manage these resources in v2.0 or do we have to create another module for those resources?

With Ref Arch 2.0, if an existing service from the Service Catalog does what you want, you don't have to create any new module yourself; you can just deploy that service directly from a terragrunt.hcl file. However, if there is extra behaviour that you want, such as your example of adding additional IAM roles to the EKS cluster, you can do so by creating your own service which either extends a Gruntwork service, or a completely new one that combines various Gruntwork modules. The docs for both of these items are here

How do you upgrade Ref Arch 1.0 and Ref Arch 2.0 to newer versions

If you are using Ref Arch 2.0, built entirely on services from the Gruntwork Service Catalog, then you are effectively maintaining a single a repo, infrastructure-live, which just has terragrunt.hcl files. When a new version of Terraform comes out, we update all the modules in the Service Catalog to work with it, release a new version, and the only thing you need to do is update the version numbers in your infrastructure-live repo. However, with Ref Arch 1.0, you have not only an infrastructure-live repo, but also an infrastructure-modules repo with thousands of lines Terraform code in it. When a new version of Terraform comes out, you have to update all that Terraform code, test it, release new versions, and only then can you update your infrastructure-live repo. So the main advantage is not having to maintain/update thousands of lines of Terraform code.

Other than the improvements in the IAC , does v2.0 have any other benefits compared to v1 in security or reliability?

There are a number of improvements discussed in the blog post: https://blog.gruntwork.io/introducing-reference-architecture-2-0-4b773bbd005a. From a security perspective, for example, Landing Zone adds a lot of features, including, for example, AWS Config, end-to-end encryption, and more. Also, Gruntwork Pipelines is a more secure way to do CI / CD. Both are built into 2.0.

Do you continue to support/maintain the v1 reference architecture code ( terraform modules) ?

All the original modules are still supported, just as before. However, we no longer maintain the Acme examples that use those modules in a 1.0 configuration. Instead, we now maintain 2.0 Acme examples: https://github.com/gruntwork-io/terraform-aws-service-catalog/tree/master/examples/for-production.

[brikis98]

Thanks @ina-stoyanova. Perhaps the first post should be the original question, exactly as written? And then the second post should be the reply? As it is now, it looks like the reply appears in both of your posts.

[ina-stoyanova]

hahahah yes, I realised that after seeing the "mark as the answer" button! Let me fix it up!

…

On Tue, 24 Aug 2021 at 11:26, Yevgeniy Brikman ***@***.***> wrote: Thanks @ina-stoyanova <https://github.com/ina-stoyanova>. Perhaps the first post should be the original question, exactly as written? And then the second post should be the reply? As it is now, it looks like the reply appears in both of your posts. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH2QP4YBX7L7P2M4FLMGVD3T6NJVBANCNFSM5CWGVX2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .