Convention_vs_Guidance – an example.
A multitenant solution provider for service deployment
orchestration has a syntax for describing the stages of buildout. The sample
for this looks something like this:
---
name: SERVICE1
service_identifier: abcdefgh-ijkl-mnop-qrst-uvwxyz012345
owner: Service1_Team
buildout_stages:
newcloud.provisioning:
-
service1_newcloud_rt
newcloud.prebootstrap:
-
service1_resources
newcloud.bootstrap:
-
service1_pfdeploy
newcloud.postbootstrap:
newcloud.predeploy:
-
service1_newregion_rt
newcloud.deploy:
-
service1_newregion
newcloud.postdeploy:
-
service1_telemetry
-
send_service1_newcloud_signal
resources:
service1_newcloud_rt:
description:
service1_pfdeploy:
description:
service1_resources:
description:
service1_newregion_rt:
description:
service1_newregion:
description:
service1_telemetry:
description:
send_service1_newcloud_signal:
description:
The question is whether the stages can be mandated from
the tenants for the deployment of their services, or should this just be a
sample?
The answer is not that simple. If it were an enforcement,
it might interfere with the organization that the services might want to keep.
It is also inefficient if most of the stages are required but cannot be filled.
The only drawback is if there is no convention, there is no consistency between
service deployment artifacts. The other approach is to publish it as a guidance
which is less restrictive and more prescriptive. The drawback for this approach
is that all the benefits of publishing go away. The answer lies somewhere in
between or dependent on the case.
No comments:
Post a Comment