Skip to content

Create IDP best practices section and four factors conceptual doc #15479

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

thoward
Copy link
Contributor

@thoward thoward commented Jul 8, 2025

No description provided.

@pulumi-bot
Copy link
Collaborator


## Patterns

Coming soon: Common architectural patterns and design approaches for organizing your infrastructure code and workflows.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we wait to review until there are no TODOs? Or are we supposed to review the IA?

Copy link
Contributor Author

@thoward thoward Jul 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I can leave those sections out of this page until (at least some of) the patterns/blueprints are complete. The goal of this PR is to get review of the Four Factors page and publish that, with follow up being the patterns and blueprints sections in the next PRs.

@pulumi-bot
Copy link
Collaborator


This section provides proven patterns and ready-to-use blueprints that help you implement well-architected solutions with Pulumi IDP. These resources follow industry best practices and have been validated in production environments.

## Patterns
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't speak to these -- will defer to @jkodroff

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm working through this PR sequentially so IDK if this will be relevant, but if the number of suggested changes become too great, we can just reduce this to something like 3 patterns to get things out the door and moving.

@pulumi-bot
Copy link
Collaborator

@pulumi-bot
Copy link
Collaborator

@pulumi-bot
Copy link
Collaborator

@pulumi-bot
Copy link
Collaborator

Copy link
Member

@jkodroff jkodroff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the whole, there's a lot of really good content in here, but I think we need to pare down the scope of the PR in order to get this launched.

The granularity and depth of the patterns are really good IMO. I think this is gonna genuinely help people use the product without getting too detailed at a level where a CSA or similar is going to be necessary to handle all the details.

My top-level suggestions:

  • Move the ESC stuff out of scope into another PR (and we can debate whether to put here or in the ESC section of the docs out of band).
  • Compress the docs nav.

Consider a developer who needs to deploy a new web site hosted in a S3 bucket. Here's how the four factors collaborate:

- **Template**: The developer starts with a `web-site` template that scaffolds a new project with the necessary structure and dependencies.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These blank lines should be removed so that this is a single ul.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this page should be present if it's just "coming soon". Just move the patterns up a level. We can always alias them later if stuff moves.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need separate menus for Best Practices and Well-Architected. To me, they are the same concept, so we can just pick one.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the whole tho, I find this to be a very useful, first-principles kind of doc. I would put this first under Best Practices/Well-Architected (whichever we choose - the former seems to be less AWS-specific, which is likely better for our position as a cloud-agnostic tool).


This section provides proven patterns and ready-to-use blueprints that help you implement well-architected solutions with Pulumi IDP. These resources follow industry best practices and have been validated in production environments.

## Patterns
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm working through this PR sequentially so IDK if this will be relevant, but if the number of suggested changes become too great, we can just reduce this to something like 3 patterns to get things out the door and moving.


## When to use this pattern

- **Complex architectures**: When you need to combine multiple infrastructure patterns
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **Complex architectures**: When you need to combine multiple infrastructure patterns
- **Integrated architectures**: When you need to combine multiple types of infrastructure

Or something like that. "Complex" has a negative connotation.


This pattern combines Pulumi components with constrained input types and policies to control infrastructure costs. By limiting available options and enforcing cost-related policies, organizations can prevent expensive configurations while maintaining developer productivity.

## When to use this pattern
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest reducing this to a sentence since all of these points fundamentally about saving scrilla on your bill-a.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ignoring this one for now b/c I think the scope of the PR overall is too large, and we should discuss whether these belong under ESC.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ibid.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one feels like a stretch. To me this is just "using policies normally, as intended". I think a more useful use case would be something like "using policies to ensure components are used instead of raw resources" or "ensuring only supported versions of components are being used" (to force upgrade paths).

description: "Ensure all components are using minimum required versions for security",
enforcementLevel: "mandatory",
validateResource: validateResourceOfType(aws.rds.Instance, (instance, args, reportViolation) => {
const componentVersion = instance.tags?.ComponentVersion;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This indicates to me that we need some metadata for policies that specifically apply to components, or a cleaner way to implement this use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants