An infrastructure abstraction gives development teams a small, configurable interface while hiding the cloud resources, tools, and wiring required underneath. It reduces cognitive load and lets platform teams evolve implementation without forcing users to learn the platform internals. section 5.4 section 6.1.1
A useful platform abstraction should:
- Expose simple resources, such as development environments, that teams can request through a platform API. section 5.4
- Keep implementation details out of the interface while allowing controlled parameters such as environment type, infrastructure installation, or service debugging. section 6.1.1
- Preserve a consistent user experience while platform teams select different underlying compositions or cloud providers. section 5.4
A development-environment request
A platform API can represent a Conference application environment with a name, an environment type, an infrastructure switch, and a frontend debug setting: { "name": "my-dev-env", "parameters": { "type": "development", "installInfra": true, "frontend": { "debug": "true" } } } The consumer configures intent; the platform decides how to provision the environment and its supporting resources. section 6.1.1
Figure 6.2 Application development team interactions with the platform . #1 App dev teams can request as many Development Environments as they need to the platform APIs; #2 The platform has encoded how to provision all the components and tools needed for the app dev team to work; #3 The platform needs to give access to the app dev team to use the newly provisioned environment.
Shows the request-to-provisioning flow: application teams request environments, the platform encodes the required components, and users receive access to the result. section 6.1.1
