Tuesday, October 25, 2022

 

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