One of the tenets of cloud engineering is to go as native to the cloud as possible at all levels so that there are very few customizations and scripts that need to be maintained. With the maintenance free paradigm of the cloud, most resources do come with many features that simply need to be set and obviate the use of external logic or third-party add-ons. Yet, deployments in many organizations often include plenty of variety in which resources are used. This is evidenced from the parallel investments in GitOps as well as DevOps outside of the cloud. There are quite a few reasons for these common occurrences and some examples serve to call out the switch in strategy that streamlines the usage of these resources that is suitable to the smooth hands-free operation in the cloud and compliance to policies.

In fact, the first call out is merely that. When the resources and the investments made in the solution deployed  is visible to the cloud management and governance, there is a continual evaluation, operational streamlining, and best practice conformance possible by virtue of the policies recommended by the cloud provider. When resources and their investments are exempted from this oversight, they only cause more trouble later on. Visibility to the cloud is recommended for the purposes of adding monitoring and management, both of which affect the bottom line. Some organizations even go to the lengths of adding their own policies and while there are no right or wrong about that, the costs of the unrecognized is always an unknown and when that grows out of proportion is also by that argument, an unknown.

Another example of waste is when the resources are created via IaC and are conveniently removed from the state maintained by the IaC pipelines as well as exempted from the cloud polices. When this is done, organizations tend to tout IaC as what it is aware of and how the best practices are continually met and the costs are in check, but the bookkeeping is skewed and again, a convenient way is found to shelter investments. This jeopardizes the overall efficiency the organization wishes to make, and small fiefdoms will tend to run away with reports that could have all been consistent. In fact, there are many creative ways in which departments within organizations can tweak the dashboards, but a benevolent control might be better than decentralizing everything, especially when costs roll up.

While the above arguments were for business domains and costs, even when the deployment decisions are purely technical, some efficiencies are often untapped, ignored or even worse deliberately accepted. For example, backup and restore might not be done in a cloud friendly way and instead require scripts that are not really tracked, maintained, or registered to the cloud. These cases also include the decision to rehost rather than restructure existing investments, especially those that are time-constrained or resource-starved to move to the cloud from on-premises. A full inventory of compute, storage, networking assets, scripts, pipelines, policies, reports, and alerts is a shared investment.

Previous articles: IaCResolutionsPart156.docx