Ownership:

When deployments become complex, the maintenance of their IaC calls for human resource allocations. While the are many factors that are significant to the planning of this allocation, one of the characteristics of the deployments is that there is repeated copy-and-paste involved across different deployment stamps. When a person is allowed to focus on one set of resources within a stamp in a subscription, there will be very little changes required to be made that avoid inadvertent errors made from copy and paste across subscriptions. Every resource is named with a convention and complex deployments increase the number of edits made across resources. When there is name variations introduced by the lines of business to differentiate deployment stamps and resources, even a modification of a resources across the subscription channels involves more copying than in the case when everything is self-contained within a subscription.

Another characteristic is that public cloud resource types require in-depth knowledge of how they work and some of them have sophisticated feature sets that it takes a while before a definition in the IaC for that resource type becomes the norm for deployment. It is in this regard that that cloud engineer expertise in certain resource types become a sought-after skill for many teams and a convenience for the infrastructure management team to consolidate and direct questions and support requests to the same group of individuals. Usually, two people can act as primary and secondary owners of these resource types. When the resource type is complex such as the use of analytics workspaces that come with their compute and storage ecosystem, designating pairs of individuals, if not more, can help with bringing industry and community perspectives to the team via trainings and conferences.

A third characteristic of working the public cloud deployments with IaC from the management’s point of view is the creation of active directory groups for individuals dedicated to working in owner, contributor and reader modes on deployments stamps and enabling the groups to be universal rather than global. The difference between groups created in these two modes is that one permits multi-domain environment access and changes to the membership trigger forest-wide replication which is helpful to ensure that permissions remain consistent across the forest. On-premises environments have traditionally used global groups since they are domain specific but with the migration to cloud resources, universal groups hold more appeal.

Securing access to resources via Active Directory groups also helps with the propagation of permissions and the ease of one-time registration to membership by individuals. When they leave, the access is automatically removed everywhere by the removal of membership and while this has remained true for most workplaces, it is even more pertinent when groups tend to be many for different purposes and creating well-known groups whose scope is tightly coupled to the resources they secure, help with less maintenance activities as individuals become empowered as needed to control the deployments of resources to the cloud.

 

References: 

Previous article in this series: IaCResolutionsPart156.docx