Create a "company blueprint" tutorial

[joeduffy]

All of our examples are single-project focused. For most real companies, however, they will have many projects (one per microservice, infrastructure stack, etc), and will need to stitch them together using Pulumi's deployment workflow. This includes RBAC, CI, Git branching, approvals, and the like.

We should create a tutorial encompassing this, along with an example ACMECorp, that shows a typical company setup. There are a few ways to slice and dice this, but based on user discussions, we probably ought to pick a decentralized model with many stacks first, since that's what most choose.

[praneetloke]

@cnunciato FYI. This is the issue I was referring to.

[lukehoban]

Here's my recommendation:

• Create a SAML-backed (Okta, GSuite or AAD) ACMECorp organization

• Populate it with 3+ users and a bot account

• Assign RBAC permissions to those users

• Deploy 4 stacks to it - based on https://github.com/pulumi/kubernetes-the-prod-way:

  • A base identity stack on AWS
  • A cluster and infrastructure stack on AWS EKS
  • An application running on top of these (Wordpress?)
  • Another application (TBD)

• Keep each of those stacks in it's own repo, versioned independently - presumably use GitHub.

• Hook each of the stacks up to CI/CD - perhaps Travis - though Azure DevOps or Jenkins might be more realistic - deploying using bot account.

• Connect GitHub App to each.

• Bonus 1: Deploy another copy of all 4 stacks as "staging" stack(s)

• Bonus 2: Find some way to automate commiting changes to one or more of the stacks to simulate activitiy (across multiple users)

[lukehoban]

/cc @clstokes @mehzer @joeduffy for feedback on the above as a V1 of a setup for this. We want this to serve purpose both for customer demos as well as for understanding and evaluating Pulumi features for impact/experience on real large customer use cases.

[mehzer]

I'd add to the setup to create multiple projects (e.g. 3).
-- Kubes
-- Simple simple S3
-- Thumbnailer (or something else that is 'not Kubes')

The reason for this is to ensure we capture the right UX and UI on a per project navigation and use basis. (For instance, I'd theorize our project/stack lists get 'busy' after 10-20 stacks, and we should think about higher level information aggregating per stack, per project concerns (e.g. Stack/Resources under management)