wip - starting resource-self-service

Author: em0ney

docs/solutions/03-resource-self-service/01-create-golden-paths.md

@@ -0,0 +1,105 @@
+---
+title: "Create Golden Paths"
+---
+
+# Create Golden Paths
+
+Golden paths are a foundational element of effective platform engineering They're your organization's standardized, opinionated way of doing things that developers actually want to use. Think of them as the "happy path" that guides developers toward best practices while eliminating decision fatigue and reducing cognitive load.
+
+## Why Golden Paths Matter
+
+As a platform engineer, you're constantly balancing standardization with developer productivity. Golden paths solve this by providing:
+
+- **Consistency at scale**: Every team follows the same patterns, making your platform predictable and maintainable
+- **Reduced cognitive load**: Developers don't waste time deciding between 47 different ways to create a service
+- **Built-in compliance**: Security, observability, and operational requirements are baked into the path
+- **Faster onboarding**: New developers can be productive immediately without learning tribal knowledge
+- **Reduced support burden**: Fewer "how do I..." questions and fewer production issues from misconfigurations
+
+## The Golden Path Philosophy
+
+Golden paths aren't designed to restrict choice, they're focused on making the right choice the easy choice. When you provide a clear, well-documented approach that follows your organization's standards, developers will naturally gravitate toward it because it's easier, faster and safer than figuring things out on their own.
+
+The best golden paths are:
+- **Opinionated but flexible**: Clear defaults with escape hatches for edge cases
+- **Self-service**: No tickets, no approvals, just instant gratification
+- **Well-documented**: Clear examples and troubleshooting guides
+- **Continuously improved**: Feedback loops that make the path better over time
+
+## From Chaos to Clarity
+
+Without golden paths, you get:
+- 47 different ways to create a service
+- Inconsistent security configurations
+- Missing observability instrumentation
+- Production issues from misconfigurations
+- Endless support requests
+
+With golden paths, you get:
+- A few approved patterns to do the majority of things correctly
+- Consistent, secure, observable services
+- Happy, productive developers
+- More time for platform innovation
+
+Golden paths transform your platform from a collection of tools into a cohesive developer experience that scales with your organization.
+
+## Our Opinions on Golden Paths
+
+### Scaffold New Respositories and Services
+
+There is no better opportunity to set up developers up for success, than a greenfield use case, where the developer is configuring a new repository or service. At this point, you as a platform engineer can give them all the best configuration out of the box, such that it's easier for them to ship their code with confidence from the outset.
+
+<iframe
+  width="560"
+  height="315"
+  src="https://www.youtube.com/embed/sE6XI0XDtQI"
+  title="Scaffolding with Port"
+  frameborder="0"
+  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
+  allowfullscreen
+></iframe>
+
+- [Scaffold a New Service](../../guides/all/scaffold-a-new-service)
+- [Scaffold Repo with Cookiecutter](../../guides/all/scaffold-repositories-using-cookiecutter/)
+- [Scaffold Bitbucket Repo with Cookiecutter](../../guides/all/scaffold-bitbucket-using-cookiecutter/)
+- [Deploy New Service and Infra](../../guides/all/create-eks-cluster-and-deploy-app/)
+
+### Cloud Resources
+
+#### Architectural Patterns
+
+Before diving into guides, it's important to pause and outline the two general patterns that exist for self-service actions (for Cloud Resources). With the adoption of Infrastructure as Code, many organizations maintain that the source-of-truth for their infrastructure configuration in their Git repositories, rather than in their cloud environments directly.
+
+It's important to build self-service that conforms with your organizational standards and best practices. Failing to match your ways of working will just lead to further resource sprawl and complexity for your Platform Engineering team.
+
+We'll explore 2 types of self-service below - RESTful Self-Service and Gitops-based Self-Service.
+
+##### RESTful Self-Service
+
+RESTful self-service actions directly create resources in your cloud provider or other upstream systems through their APIs. This approach is straightforward and immediate—when a developer requests a resource through Port's self-service interface, the action makes API calls to create the resource directly in the target system (like AWS, Azure, or GCP). This pattern works well for organizations that prefer direct resource creation or when you need immediate provisioning without the overhead of Git-based workflows. The trade-off is that you lose the audit trail and version control benefits that come with GitOps, but you gain simplicity and speed for teams that don't need the full GitOps workflow.
+
+- [Create an S3 Bucket via Webhook](../../guides/all/s3-using-webhook)
+
+##### GitOps-based Self-Service
+
+GitOps-based self-service actions create resources by leveraging your existing Infrastructure as Code (IaC) files and modules. Here, an existing GitOps pipeline (like ArgoCD, Flux, or Terraform Cloud) picks up the changes and provisions the resources in the target cloud environment. This approach maintains the benefits of version control, audit trails, and the ability to review changes through pull requests, while still providing developers with a streamlined self-service experience. The trade-off is that resource creation takes longer due to the GitOps pipeline cycle, but you gain better governance, compliance, and the ability to enforce organizational standards through code review processes.
+
+- [Create Cloud Resource Using IaC](../../guides/all/create-cloud-resource-using-iac)
+- [Deploy S3 Bucket CrossPlane](../../guides/all/deploy-s3-bucket-crossplane)
+
+### Create Secrets
+
+Secret leakage remains a huge issue in the industry. The fact that developers have to manually handle secrets is like a process in a nuclear plant requiring the manual handling of uranium. It's an error prone workflow, that often leads to a security incident and in worse cases, supply chain security issues and data loss.
+
+The best protection against secret leakage is the design of a secure workflow, in which secrets are securely handled and developers are unlikely to make an error.
+
+- [Create GitHub Secret](../../guides/all/create-github-secret/)
+<iframe
+  width="560"
+  height="315"
+  src="https://www.youtube.com/embed/QO45jaeAA2o"
+  title="Secure Secrets Management"
+  frameborder="0"
+  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
+  allowfullscreen
+></iframe>

docs/solutions/03-resource-self-service/02-setup-approval-workflows.md

@@ -0,0 +1,5 @@
+---
+title: "Setup Approval Workflows"
+---
+
+# Setup Approval Workflows

docs/solutions/03-resource-self-service/03-manage-track-reolve-issues.md

@@ -0,0 +1,5 @@
+---
+title: "Manage, Track and Resolve Issues"
+---
+
+# Manage, Track and Resolve Issues

docs/solutions/03-resource-self-service/04-self-service-environments.md

@@ -0,0 +1,5 @@
+---
+title: "Self-Service Environments"
+---
+
+# Self-Service Environments

docs/solutions/03-resource-self-service/_category_.json

@@ -0,0 +1,12 @@
+{
+    "label": "Resource Self-Service",
+    "collapsible": true,
+    "collapsed": true,
+    "link": {
+      "type": "generated-index",
+      "title": "Resource Self-Service"
+    },
+    "customProps": {
+      "description": "Resource Self-Service"
+    }
+  }