You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the greenfield development of an engineering platform there will typical be a window of time, preferably short, between when the early adopting customers need usable access to the platform but before the custom platform APIs are sufficiently mature to manage even the mvp capabilities.
10
+
In the greenfield development of an engineering platform there will typical be a window of time, definitely short, between when the early adopting customers need usable access to the platform but before the custom platform APIs are sufficiently mature to manage even the mvp capabilities.
11
11
12
12
A simple way to address this problem (and even provide a good development resources to the team building the platform APIs), is to use a basic pipeline to applpy the needed, basic configuration. For this approach to be manageable, limit the scope to:
13
13
@@ -19,7 +19,47 @@ The namespace definitions can include annotations for things like inclusion with
19
19
20
20
* The mvp of the plataform should include one or more product-defined, managed top-level domains that support ingress.
21
21
22
-
The example strategy uses two domains, twdps.io and twdps.digital. Scalable configuration for the various subdomains or path-patterns to support these product domains should be api managed just like custom ns. A good short-term stragy is to initial aupport default ingress patterns much the same was as default environments are provided.
22
+
The example strategy uses two domains, twplatformlabs.org and twplatformlabs.link. The .link top level domain is for demonstrating migration strategies. Scalable configuration for the various subdomains or path-patterns to support these product domains should be api managed just like custom ns. A good short-term stragy is to initial aupport default ingress patterns much the same was as default environments are provided.
For each, there will be a demo-preview, demo-dev and so on depending on the team and the cluster. Only demo and platform have a preview ns in the sbx cluster for demonstrating the role of the preview cluster.
53
+
54
+
## Note
55
+
56
+
This pipeline is expected to be short-lived and only used to support a small number of teams onboarded. Any scale at all will demonstrate that this is unsustainable. The value is limited to accelerating a small number of early adoptors onto the plateform to provide the necessary feedback loop for validating a minimum feature set prior to general availability. Prior to GA, the custom platform integration APIs should be deployed to perform the tasks of this static repo in a scalable and resilient architecture.
57
+
58
+
## maintainers
59
+
60
+
This is a replacement for earlier pre-release alpha team configuration.
61
+
62
+
## Deprecated
23
63
24
64
Default environment gateways:
25
65
@@ -45,16 +85,5 @@ A small list of example early-adopter customers have their configuration managed
45
85
| alpha teams | sbx-i01-aws-us-east-1 | prod-i01-aws-us-east-2 |
For each, there will be a demo-preview, demo-dev and so on depending on the team and the cluster. Only demo and twdps-core-labs-team have a preview ns in the sbx cluster for demonstrating the role of the preview cluster.
53
-
54
-
## Note
55
-
56
-
This pipeline is expected to be short-lived and only used to support a small number of teams onboarded. Any scale at all will demonstrate that this is unsustainable. The value is limited to accelerating a small number of early adoptors onto the plateform to provide the necessary feedback loop for validating a minimum feature set prior to general availability. Prior to GA, the custom platform integration APIs should be deployed to perform the tasks of this static repo in a scalable and resilient architecture.
57
-
58
-
## maintainers
59
-
60
-
This is a replacement for earlier pre-release alpha team configuration.
0 commit comments