Self-Service Delivery Requirements

[sunstonesecure-robert]

What would you like to be added?

Prioritization/questions need to be answered for developer/operator self-service capabilities. These capabilities could include (initially or over iterations):

• Priority of cluster-level visibility or only workload? eg multi-cluster provisioning?
• cluster versioning, pinning options?
• in MC option, reserve namespaces?
• multiple namespaces or namespace-per-application?
• single tenant per app or multi-tenant?
• config parameters exposed?
• identity, access (e.g. service accounts), discoverability of cluster or workloads - locked-down or configurable at self-service?
• container image build and catalog customization and versioning?
• deployment customizations?
• support tasks for CoE/hosting provider, central SRE?
• customizable log streaming to aggregation points and access?
• tracing/observability hooks customizable?
• DR/BC backups and recovery customization?
• Profile and control overrides or enhancements for compliance?

Why is this needed?

Different operators and developers will need different things and we need to be practical for the roadmap on how we deliver some initial capabilities for early adopters who will contribute back meaningful feedback. These may not be the most popular options, but represent the needs of the first operators who need to actually deploy things.

User Stories

1. Developer gets a mission requirement that is compatible with a containerized app
2. Developer reviews self-service blueprint options for deploying the app (future state: by submitting data and workload metadata that is used to match up to blueprints automagically)
3. Developer creates a request for capabilities through PR (or portal, or chat bot, or ...)
4. System provisions compute, network, storage, pipeline capabilities for developer
5. Developer receives access to cluster(s) or shell(s) or endpoint(s) or ... to deploy application
6. Developer can package application and deploy via PR
7. PR checked for all necessary policy checks
8. Developer does local dev testing that is consistent with cluster environment
9. Deployment of app
10. Developer gets test env access and validates app
11. QA gets verification env access and validates app
12. Developer promotes to prod via branch/promotion strategy and checks
13. SRE/Ops/SecOps sees new app alerts and monitoring and compliance reports