gruntwork-io
diff --git a/‎custom-dictionary.txt‎
Lines changed: 1 addition & 0 deletions b/‎custom-dictionary.txt‎
Lines changed: 1 addition & 0 deletions
diff --git a/‎docs/2.0/docs/overview/concepts/developer-self-service.md‎
Lines changed: 43 additions & 45 deletions b/‎docs/2.0/docs/overview/concepts/developer-self-service.md‎
Lines changed: 43 additions & 45 deletions
diff --git a/‎docs/2.0/docs/overview/concepts/devopsfoundations.md‎
Lines changed: 26 additions & 19 deletions b/‎docs/2.0/docs/overview/concepts/devopsfoundations.md‎
Lines changed: 26 additions & 19 deletions
@@ -44,6 +44,7 @@ mimecast
 slugified
 dlist
 DEPENDENCYID
+subfolders
 MTTR
 terrapatch
 Terrapatch
 
@@ -1,79 +1,77 @@
-# Developer Self Service
+# Developer Self-Service
 
-Developer Self-Service lets developers deploy and manage their apps and infrastructure themselves, without always needing help from the platform team.
+Developer self-service enables developers to deploy and manage their applications and infrastructure independently, without constant reliance on the platform team.
 
-Effective developer self-service then requires a set of patterns, practices, rules, constraints and governance pre-baked into the modules that engineers use to represent their infrastructure. Some teams call these modules "approved blueprints" or "blessed modules".  At Gruntwork we generally refer to this as the **Infrastructure Catalog** that lives in a repository we call `infrastructure-catalog` (previously `infrastructure-modules`).
+Effective self-service requires patterns, practices, rules, constraints, and governance to be embedded within the modules developers use to define their infrastructure. These modules are often referred to as "approved blueprints" or "blessed modules." At Gruntwork, we call this the **Infrastructure Catalog**, which resides in a repository named `infrastructure-catalog` (formerly `infrastructure-modules`).
 
-Inside the `infrastructure-catalog` we recommend following the [infrastructure-live pattern](https://docs.gruntwork.io/2.0/docs/overview/concepts/infrastructure-live#separating-modules-from-live-infrastructure) and storing catalog module code in a folder called `modules`.
+Within the `infrastructure-catalog`, we recommend following the [infrastructure-live pattern](https://docs.gruntwork.io/2.0/docs/overview/concepts/infrastructure-live#separating-modules-from-live-infrastructure) and organizing catalog module code in a folder named `modules`.
 
 ## Why self-service
 
-### Benefits to Developers
+### Benefits to developers
 
-Developers benefit by avoiding "reinventing the wheel". They're able to leverage pre-built, tested, and secure modules that have already been approved for use at your organization. Handoffs between platform and development teams are reduced resulting in faster delivery and fewer bottlenecks.
+Self-service allows developers to avoid "reinventing the wheel" by using pre-built, tested, and secure modules that are already approved for use. This reduces handoffs between platform and development teams, speeding up delivery and minimizing bottlenecks.
 
-### Benefits to Platform Teams
+### Benefits to platform teams
 
-Platform teams are able to operate effectively at scale. They retain centralized control of reusable modules, and are able to focus on standardizing testing, security, compliance, and governance. The day to day workload of assisting Developers with infrastructure code is reduced, while retaining oversight.
+Self-service enables platform teams to operate efficiently at scale. By centralizing control over reusable modules, platform teams can focus on standardizing testing, security, compliance, and governance. The workload of assisting developers with infrastructure code is reduced, while maintaining oversight and control.
 
-## Terragrunt Catalog
+## Terragrunt catalog
 
-Terragrunt has [native support](https://terragrunt.gruntwork.io/docs/features/catalog/) for an interface that allows developers to browse modules using a terminal based UI, and then [scaffold](https://terragrunt.gruntwork.io/docs/features/scaffold/) out new modules using [boilerplate](https://github.com/gruntwork-io/boilerplate). All repositories vended as part of Devops Foundations include a `catalog` configuration in the root `terragrunt.hcl` file that points to a starter `infrastructure-catalog` repository that provides examples on how to further build out the catalog.
+Terragrunt provides [native support](https://terragrunt.gruntwork.io/docs/features/catalog/) for an interface that allows developers to browse modules using a terminal-based UI and [scaffold](https://terragrunt.gruntwork.io/docs/features/scaffold/) new modules with [boilerplate](https://github.com/gruntwork-io/boilerplate). Repositories vended through DevOps Foundations include a `catalog` configuration in the root `terragrunt.hcl` file, pointing to a starter `infrastructure-catalog` repository with examples for expanding the catalog.
 
-### Using Catalog
+### Using catalog
 
-Within a DevOps Foundations repository, create a new directory to contain your new terragrunt unit, then navigate to this directory.
+In a DevOps Foundations repository, create a new directory for the new Terragrunt unit, then navigate to this directory.
 
-Running `terragrunt catalog` will open an interactive terminal UI allowing you to browse the available units from your `infrastructure-catalog`.
+Running `terragrunt catalog` opens an interactive terminal UI to browse available units in the `infrastructure-catalog`.
 
-When browsing your catalog, you can select a unit, and hit **S** to scaffold it out.
-The scaffold command does the following automatically:
+To scaffold a unit, select it and press **S**. The scaffold process automatically:
 
-- Download and template the unit into the current directory.
+- Downloads and templates the unit into the current directory.
+- Determines the module URL and latest version (tag), populating the source URL.
+- Parses the module’s input variables and generates placeholders in the `inputs = { }` block for easy configuration.
 
-- Figures out the module URL and the latest version (tag) available, and fills that into the source URL.
+After replacing the placeholders, commit the new unit and push it to a new Pull Request for [Gruntwork Pipelines](/2.0/docs/pipelines/concepts/overview) to begin planning the changes.
 
-- Parse all of the module’s input variables and generate placeholders in the inputs = { } block to make it easy to fill those variables in.
-
-Once you've replaced these placeholders, commit the new unit, and push it to a new Pull Request for [Gruntwork Pipelines](/2.0/docs/pipelines/concepts/overview) to being planning the changes.
-
-## Self-Service Best Practices
+## Self-service best practices
 
 ### Versioning
 
-Implement a consistent versioning strategy, such as [semantic versioning](https://semver.org/), for all modules in your infrastructure catalog. This allows you to:
+Adopt a consistent versioning strategy, such as [semantic versioning](https://semver.org/), for all modules in the infrastructure catalog. This approach helps:
+
+- **Track changes:** Maintain a clear history of updates and modifications.
+- **Enable rollbacks:** Revert to previous versions if issues arise.
+- **Ensure clarity:** Use semantic versioning (e.g., v1.2.3) to communicate the scope of changes (major, minor, patch).
 
-* **Track Changes:** Maintain a clear history of module updates and modifications.
-* **Enable Rollbacks:** Revert to previous versions in case of issues or errors.
-* **Ensure Clarity:** Use semantic versioning (e.g., v1.2.3) to communicate the nature of changes (major, minor, patch).
+Leverage [Gruntwork Patcher](/2.0/docs/patcher/concepts/) to roll out breaking changes efficiently while minimizing disruptions.
 
-Use [Gruntwork Patcher](/2.0/docs/patcher/concepts/) to efficiently roll out breaking changes across your infrastructure and minimize disruption.
+### Infrastructure tagging and labeling
 
-### Infrastructure Tagging and Labeling
+A centralized catalog facilitates consistent tagging and labeling across infrastructure components, enabling:
 
-A central catalog allows core teams to implement a consistent tagging and labeling strategy across all infrastructure components. This enables:
+- **Cost tracking and allocation:** Assign costs to specific teams or projects using tags.
+- **Access control:** Manage and control resource access with tags.
+- **Automation:** Automate tasks such as provisioning, termination, and reporting based on tags.
+- **Monitoring and alerting:** Group and filter resources for effective monitoring and alerting.
 
-* **Cost Tracking and Allocation:** Assign costs to specific teams or projects based on tags.
-* **Access Control:** Use tags to manage and control access to resources.
-* **Automation:** Automate tasks like provisioning, termination, and reporting based on tags.
-* **Monitoring and Alerting:** Filter and group resources for monitoring and alerting purposes.
+### Wrapper modules / services
 
+Use wrapper modules or services to simplify deployments and configurations. Wrappers can:
 
-### Wrapper Modules / Services
+- **Encapsulate best practices:** Integrate security, compliance, and operational standards into reusable modules.
+- **Reduce boilerplate:** Eliminate repetitive code for developers.
+- **Standardize deployments:** Ensure consistency and reduce errors across deployments.
+- **Abstract complexity:** Hide infrastructure complexity, allowing developers to focus on application logic.
 
-Create wrapper modules or services to simplify complex deployments and configurations. These wrappers can:
 
-* **Encapsulate Best Practices:** Bundle security, compliance, and operational best practices into reusable units.
-* **Reduce Boilerplate:** Minimize repetitive code and configuration for developers.
-* **Standardize Deployments:** Ensure consistency and reduce errors across different deployments.
-* **Abstract Complexity:** Hide the underlying complexity of infrastructure from developers, allowing them to focus on application logic.
+### Using stacks to keep developer code DRY
 
+Organize infrastructure into [stacks](https://terragrunt.gruntwork.io/docs/features/stacks/) to enhance reusability and maintainability. Terragrunt Stacks enable you to:
 
-### Using Stacks to keep developer code DRY
+- **Group related resources:** Manage interconnected units as a single entity.
+- **Reduce code duplication:** Avoid repeating code across environments or projects.
+- **Promote modularity:** Break complex infrastructure into manageable components.
+- **Simplify management:** Deploy, update, and destroy stacks with ease.
 
-Organize infrastructure into stacks to promote code reusability and maintainability. Terragrunt Stacks allow you to:
 
-* **Group Related Resources:** Manage interconnected units as a single entity.
-* **Reduce Code Duplication:** Avoid repeating the same code across different environments or projects.
-* **Promote Modularity:** Break down complex infrastructure into smaller, manageable components.
-* **Simplify Management:** Deploy, update, and destroy entire stacks with ease.
@@ -1,33 +1,40 @@
 # Overview of Devops Foundations
+ 
+**Gruntwork DevOps Foundations provides a collection of _DevOps components_ that serve as foundational building blocks for constructing best-practice infrastructure.**
 
-**Gruntwork DevOps Foundations is a collection of _DevOps components_ that you use as building blocks to assemble your own best-practice infrastructure.**
+Modern cloud infrastructure involves numerous components, spanning areas such as infrastructure pipelines, secrets management, FinOps, and application deployment. Establishing and managing each component independently requires a deep understanding of core infrastructure needs, the development of strategies to address them, the implementation of solutions, and ongoing maintenance. Gruntwork’s DevOps components addresses these challenges by offering:
 
-In a modern cloud infrastructure there are many component parts, ranging from the infrastructure pipeline to secrets management to FinOps to how you deploy apps. Setting up and managing each component requires that you understand the core infrastructure need, develop a strategy for addressing it, implement a solution, and then maintain it forever. Doing this on your own is expensive and error-prone, so Gruntwork DevOps components are designed to "pre-solve" all of these issues by including:
+- Pre-defined strategic recommendations
+- A curated collection of Infrastructure-as-Code (IaC) modules with comprehensive documentation
+- Tools that directly meet underlying infrastructure needs
+- A streamlined method for integrating components into your environment
+- Ongoing updates to ensure alignment with the latest best practices
 
-- Pre-written recommendations on strategy
-- A collection of pre-written IaC modules with extensive documentation
-- A tool that directly solves the underlying need
-- A streamlined approach to implementing the component in your environment
-- A commitment by Gruntwork to update the component to match the latest best practices
-
-When you set up a new DevOps component, you also have access to guidance from Gruntwork subject matter experts to make sure the component is applied correctly in your environment, and grows in capability as your needs evolve.
+When setting up a new DevOps component, customers also have access to guidance from Gruntwork subject matter experts. Their support ensures correct implementation within your environment and adaptability to meet evolving needs.
 
 ## Available components
 
-There are several DevOps components available today:
+Gruntwork currently offers several DevOps components:
+
+* [Infrastructure-Live](/2.0/docs/overview/concepts/infrastructure-live.md): An opinionated structure for IaC repositories that incorporates best practices for organizing OpenTofu code to maintain DRY principles at an enterprise scale.
+* [Pipelines](/2.0/docs/pipelines/concepts/overview.md): A comprehensive CI/CD pipeline for infrastructure code, including guidelines for structuring OpenTofu code and scripts to manage pipeline operations.
+* [Account Factory](/2.0/docs/accountfactory/concepts/): Automated workflows for provisioning new AWS accounts, applying compliance and security baselines, and enforcing infrastructure business rules across multiple accounts.
+* [Patcher](/2.0/docs/patcher/concepts/): Tools for identifying outdated modules in repositories, creating pull requests to update versions, and automatically refactoring code to handle breaking changes without developer intervention.
+* [Library](/2.0/docs/library/concepts/overview): A robust collection of over 300,000 lines of OpenTofu/Terraform code modules, providing foundational components such as VPCs, ECS clusters, and S3 buckets for building infrastructure.
 
-* [Infrastructure-Live](/2.0/docs/overview/concepts/infrastructure-live.md): An opinionated structure for IaC repositories that includes a set of best practices for how to structure your OpenTofu code to keep things DRY at enterprise scale.
-* [Pipelines](/2.0/docs/pipelines/concepts/overview.md): A complete CI/CD pipeline for infrastructure code, a set of best practices for how to structure your OpenTofu code, and a set of scripts for managing the pipeline.
-* [Account Factory](/2.0/docs/accountfactory/concepts/): A set of automated workflows to provision new AWS accounts and apply compliance, security and infrastructure baselines to enforce business rules across many accounts.
-* [Patcher](/2.0/docs/patcher/concepts/): Identify out of date modules across your repositories and create pull requests that both updates versions and automatically refactors code to get through breaking changes without developer intervention.
-* [Library](/2.0/docs/library/concepts/overview): Over 300,000 lines of terraform code modules that are designed to be used as building blocks for your infrastructure. From VPCs to ECS clusters to S3 buckets, the library has you covered.
 <!-- * [Catalog]  -- see DEV-628 -->
-<!-- Something about networking / transit gateway? -->
+<!-- Placeholder for networking/transit gateway details -->
 
-All DevOps components are focused on Terragrunt, OpenTofu/Terraform, GitHub and AWS. We may add support for additional technologies in the future.
+All components are designed with a focus on Terragrunt, OpenTofu/Terraform, GitHub, and AWS. Support for additional technologies may be introduced in the future.
 
 ## Building your own components
 
-The Gruntwork DevOps components implement a meaningful portion of a modern cloud infrastructure, but not 100% of it. We expect you to build on top of the Gruntwork DevOps components by adding your own solutions to build out your full infrastructure.
+Gruntwork DevOps components provide a substantial foundation for modern cloud infrastructure but are not intended to cover every possible need. Customers are encouraged to expand upon these components by integrating their own solutions to develop a comprehensive infrastructure.
+
+Each component in DevOps Foundations is purposefully designed for extensibility and customization. Recognizing that many customers are developers, Gruntwork empowers customers to create tailored solutions that address their unique requirements, rather than rely solely on pre-built components. Collaboration is a key focus, and Gruntwork actively welcomes customer feedback and contributions to continually refine and enhance its offerings.
+
+
+
+
+
 
-All of the components in DevOps Foundations are designed to be extensible and customizable. We recognize that most of our customers are developers, and we want to make sure you are empowered to easily build the solutions you need instead of relying exclusively on Gruntwork to have them pre-built in every circumstance. We encourage collaboration with our customers, and are always looking for feedback, and contributions to improve our components.