This is a continuation of the listing of design choices for infrastructure consolidation that fall into well-known patterns. These include the following patterns:   

11.   Securing perimeter: Some of the security concerns are about opening up ip addresses and port to the public internet. Web API requests are notorious for various kinds of exploits and proper hardening involves using a firewall to route all the requests. This pattern manifests as a central resource that has an attached firewall for all the web applications and services hosted on different hosts.  

12.   Deployment of dashboards and application insights: While technically not deemed a requirement, it is always useful to add anything that helps with the continuous monitoring of the deployed resources to the point that troubleshooting can be done by anyone merely by glancing at the dashboards. This kind of infrastructure deployment maturity is essential for large teams and infrastructure because it offloads the maintenance.

13.   Dependency chaining – Most infrastructure is deployed with their dependencies independently so there is usually not a case of dependencies blocking another deployment. That said, it might take multiple times for a pipeline to run before all the dependencies and the dependent resources are created. Sometimes this might take several deployments if the generated resource identifiers or guids must be passed in manually to other resources or their configurations. If dependencies are deployed together for the same business purpose, it might even be beneficial to use the same user managed identity for all of the associated resources.

14.   Redeployment – All dependencies and their access control identities must be in sync for the whole deployment to work together. Sometimes, this gets broken when identities change, or dependencies are replaced. Even creating one by the same name and different principal_ids can cause disruptions. It is best to remove and add back the entities by the same names so that the associations can be refreshed, and they don’t use the stale identifiers that they relied upon. Redeployment does not get captured in IaC but it is a pattern one cannot do without.

15.   Policy compliance – Almost all resource types have their best practices and recommended settings. Compliance of resources to these policies is equally important as it safeguards the resources and assures overall safety. The type of effect a policy has depends on its settings, so they might selectively apply across resource types and span different resource and infrastructure grouping. Having a common module where the policies can be enforced as a one-point maintenance is not only a good thing but also time-saving. Since the common module can be versioned, instance can still point to older versions if they must.

16.   Metadata – The state stored for an IaC is sometimes referred to as the metadata of a resource to which it must be synchronized whenever there is a drift. However, state is as scoped as the infrastructure groupings and can be somewhat disparate making it necessary to locate the state before it can be interpreted. Since state is usually comprised of json with entries each for different resources or modules as listed in the infrastructure, it is easy to view these collectively as a key-value pair where the keys are the references to the resources in the Portal and the values are their json descriptions.    

Previous articles: IaCResolutionsPart65.docx