The power of infrastructure consolidation:

Infrastructure deployed to the public clouds is often characterized by shared-nothing deployments that are dedicated to different workloads. With the convenience of repeatable and automated deployments via Infrastructure-as-Code aka IaC, it becomes easy to spin up as many resources as necessary to separate the usages. This is advantageous in many ways. For example, deployments can evolve differently and have different lifetimes and growth spurts. Ownership can be handed off to independent teams. Access control can be set up differently. Different workloads can require different tunings which might manifest as resource-level settings and configurations.  The deployments can scale independently. It is also possible to bill them to different accounts or at least tag them differently. State may be captured in the tags and labels differently between the resources of the same type in those deployments. The explosion in the number of resources is not a concern for automation that repeats the same steps for each. Workloads can be studied more effectively, and they do not share the same fate. Troubleshooting and maintenance become easier and cheaper. It is even possible to establish a control set for baseline.

But consolidation has its own merits. For example, web applications deployed to independent application services can be hosted on the same application service plan when they do not have widely varying requirements. A single app service plan requires only one subnet for virtual network integration to guarantee that all outbound traffic goes via the virtual network. This is especially helpful to ensure a robust private plane connectivity between storage and compute resources that these web applications might need. Cost savings come from avoiding higher sku app service plans as well as those from associated resources such as subnets and networking appliances. It provides another level of differentiation between infrastructure and workload perspectives albeit at the resource level instead of the resource group level. While simultaneously deployed resources and their dependencies are easy to interpret from the written IaC for deployments, the savings have a ripple effect in other non-functional aspects such as logging and monitoring. With a reduction in maintenance, consolidation also lowers costs for skills, training, and dedication. Consolidation as a strategy is even a prerequisite to creating service tiers so that quality-of-service aka QoS can be better articulated. The resource pooling and workload classification to pools is an established pattern for improving resource utilization in any infrastructure whether it is on-premises and at cloud scale.

Even the savviest cloud account owners are wary of ballooning costs over time for resources and there are many features available natively from the cloud to address some of these concerns, but no cloud can truly understand the resource utilization or refactoring possible without some involvement from these owners. Case in point is the use of specific resource types and monitoring practices to set up feedback-loop cycles. Both AWS and Azure offer resource types such as X-Rays and Application Insights to analyze and debug distributed applications which collects data about the requests that the application serves and provides tools to view, filter, and gain insights into that data. Yet owners seldom take advantage of setting up monitoring and dashboards for all their assets. Infrastructure providers aka IaC deployers are left to fill the gap but they have one advantage that others don’t. They can do this for entire resource groups and deployments that are not limited to specific web applications or resource types. Even if the dashboard they create and maintain to study the infrastructure usage patterns become private, they will be empowered to advise the account owners on tactical consolidations. They are not limited to making inferences from cost management dashboards and utilization dashboards and patterns can also help them to validate their choice of SKUs, reservations, and other assertions.  They are not strangers to alerts and notifications and resource-level chores, but they could benefit from creative ways to setup deployment scope feedback cycles.