Essays on Infrastructure-as-code

Copyright © 2025 Ravi Rajamani.

All rights reserved. No part of this book may be used or reproduced by any means, graphic, electronic, or mechanical, including photocopying, recording, taping or by any information storage retrieval system without the written permission of the author except in the case of brief quotations embodied in critical articles and reviews.

Archway Publishing

1663 Liberty Drive

Bloomington, IN 47403

www.archwaypublishing.com

844-669-3957

Because of the dynamic nature of the Internet, any web addresses or links contained in this book may have changed since publication and may no longer be valid. The views expressed in this work are solely those of the author and do not necessarily reflect the views of the publisher, and the publisher hereby disclaims any responsibility for them.

Any people depicted in stock imagery provided by Getty Images are models, and such images are being used for illustrative purposes only.

Certain stock imagery © Getty Images.

ISBN: 978-1-6657-6846-7 (sc)

ISBN: 978-1-6657-6848-1 (hc)

ISBN: 978-1-6657-6847-4 (e)

Library of Congress Control Number: 2024924580

Archway Publishing rev. date: 01/30/2025

This book is dedicated to my teacher.

Contents

IaC Architecture

IaC Types

IaC Comparisons

IaC Automations

IaC Naming

IaC Characteristics

Resource Locking

Deadlocks

IaC Dependencies

IaC Complexity

Knowledge graphs

The Hidden Factor

IaC caveats

IaC Challenges

IaC Resolutions

IaC customizations

IaC for ML Pipelines

The case for an ML Pipeline

Workflows

Comparisons to Deis Workflow

Solution Accelerator

IaC Modernization

The refactoring of old code to new microservices

Maintainability, performance, and security

Path towards Microservices architecture

Application Migration Process

Incremental code migration strategy

Towards architecture driven modernization

Reverse engineering using models

Model-driven Software development

Rehost, Refactor, Rearchitect, Rebuild, Retire

A recommendation to businesses

Field Guide

The Application Migration scenario for serving static content – a case study

Well-architected framework

The power of infrastructure consolidation

IaC Innovations

IaC regulation and compliance

Authorization

Privilege and permissions: A case study

Troubleshooting of role assignments via IaC: a case study

Automated Cloud IaC using Copilot

Emerging Trends and Generative AI

Popularity of chatbots

Managing copilots

LLM-as-a-judge

Data Infrastructure for Generative AI

Networking: a case study

Understanding Workloads for business continuity and disaster recovery (aka BCDR)

Ownership

A note about choices between public clouds

Just-in-time access

Technical Debt in IaC

DevOps for IaC

Top-Down vs Bottoms-up

Mitigation of political and regulatory risk in cloud infrastructure

Data Engineering

Support

Figure shows the relationship between three representations of resources that must be kept in sync.

IaC Architecture

A public cloud is a tiered implementation of proprietary investments in compute, storage, and networking from well-known providers such as Microsoft, comprising an Infrastructure-as-a-service aka IaaS layer, a Platform-as-a-service aka PaaS layer next, followed by resource manager and Dev-ops tools on top. The public cloud offers capabilities to the general public in the form of services from the provider’s services portfolio that can be requested as instances called resources. It is for these resources that a certain form of manifests are recorded and saved as code and often referred to as Infrastructure-as-code or IaC for short. The capabilities of a public cloud are wide and deep targeting use cases in web and mobile, Internet of Things, Microservices, Data + analytics, Identity management, Media streaming, High Performance Compute and Cognitive computing. These services all utilize core investments in terms of compute, networking, storage and security, organized in a hierarchy of increasing scope in the form of datacenters at a physical location, usually the size of a football stadium, availability zones comprising one or more datacenters, a region such as West US or East US comprising one or more availability zones, and a global presence of individual resources spanning multiple regions. Both for the provider and the general public, IaC is a common paradigm for self-service templates to manage, capture and track changes to a resource during its lifecycle.

There is no denying that Infrastructure-as-code aka IaC can help to create and manage infrastructure with versioning, reusability, and sharing – all of which helps to provision resources quickly and consistently and manage them for their lifetime. But unlike software product code that is written for business purposes and provides a strong foundation for system architecture that weathers changing business requirements over time and often grows to become veritable platforms for ecosystems where independent vendors can join to increase the business value, IaC manifests in variations and combinations depending on environment, purpose, and scale. That said, as with all code, it encompasses complete development process and includes CI/CD platform, DevOps, and testing tools. The DevOps based approach is critical to rapid iteration and development cycles for improvements. This makes IaC spread over in a variety of forms. The more articulated the IaC the more predictable and cleaner the deployments.

The IaC architecture is almost always dominated by the choice of technology stacks. There is no universal system architecture or a single point of maintenance but a more DevOps oriented tailored approach with all the tools necessary to keep the deployments consistent and repeatable. Technology varies with cloud native forms, providers like Ansible, Terraform, and domain specific language such as Pulumi. IaC can be curated as a set of machine-readable files, descriptive models, and configuration templates. Then there are two approaches for writing it which are an imperative approach and a declarative approach. The imperative approach allows users to specify the exact steps to be taken for a change and the system does not deviate from them while a declarative approach specifies the final form, and the tool or platform involved goes through the motion of provisioning them.

Infrastructure can be made available as an online service and shared offline as code. Provisioning infrastructure can be a cloud service, and many public clouds offer it in their service portfolio. These so-called native infrastructures are great for leveraging the public cloud built-in features but more than usual, organizations build a veritable library of assets and prefer it not to be limited to any one cloud-based resources. It can even include on-premises infrastructure. No matter what choices are made and the decision process for navigating the IaC landscape, it is unquestionable that IaC reduces shadow IT within organizations, integrates directly with CI/CD platforms, version controlling infrastructure and configuration changes, standardizing infrastructure, effectively managing configuration drift and with the ability to scale up or out without increasing CapEx or OpEx.

Configuration Management is separate from infrastructure management although tools like Ansible provide hybrid solutions. True configuration management is demonstrated by software like CFEngine while infrastructure management is demonstrated by providers like Terraform and Pulumi. Businesses can mix and match any tool and use them in their CI/CD pipelines depending on their custom requirements.

As a real-world example, a developer writes application code and the configuration management related instructions that will trigger actions from the virtualization environment. When the code is delivered, configuration management and infrastructure management provide a live operational environment for testing. When the tests run and the error detection and resolution occur, the new code changes become ready for deployment to customer facing environments. Managing the state drift as changes keep propagating is one of the core management routines for Infrastructure-as-code.

IaC Types

There is a growing need for dynamic, dependable, and repeatable infrastructure as the scope of deployment expands from small footprint to cloud scale. Some of the manual approaches and management practices cannot keep up. There are two popular ways to meet these demands on the Azure public cloud which are provider-independent infrastructure-as-code aka IaC and public cloud specific resource templates. Both these approaches can provide deterministic and software-defined infrastructure, but they also have independent use cases. Specifically, there are use cases for DevSecOps and they apply to the development and operation of trustworthy infrastructure-as-a-code. The term DevSecOps stands for a framework that integrates security practices into every phase of the software development lifecycle.

One example of provider independent Infrastructure-as-code is Terraform which highlights the use case of universally extensible with provider specific templates that furnish IaC for resource types. It is a one-stop shop for any infrastructure, service, and application configuration. It can handle complex order-of-operations and composability of individual resources and encapsulated models. It is also backed by an open-source community for many providers and their modules with public documentation and examples. Public cloud providers like Microsoft also work directly with the Terraform maker on building and maintaining related providers and this partnership has gained widespread acceptance and usage. Perhaps, one of the best features is that it tracks the state of the real-world resources which makes Day-2 and onward operations easier and more powerful.

ARM templates are entirely from Microsoft that are consumed internally and externally as the de facto standard for describing resources on the Azure public cloud and come with their import and export options. This serves as a great example for public-cloud specific resource templates and throughout this book, these two types of IaC are used for explanations. There is a dedicated cloud service called the Azure Resource Manager service that expects and enforces this convention for all resources to provide effective validation, idempotency and repeatability.

Whenever there are templates, there are also Blueprints. Azure Blueprints, for example, can be leveraged to allow an engineer or architect to sketch a project’s design parameters, define a repeatable set of resources that implements and adheres to an organization’s standards, patterns, and requirements. It is a declarative way to orchestrate the deployment of various resource templates and other artifacts such as role assignments, policy assignments, ARM templates, and Resource Groups. Blueprint Objects are stored in the CosmosDB and replicated to multiple Azure regions. Since it is designed to setup the environment, it is different from resource provisioning. This package fits nicely into a CI/CD.

With Azure templates, one or more Azure resources can be described with a document, but it does not exist natively in Azure and must be stored locally or in source control. Once those resources are deployed, there is no active connection or relationship to the template.

Other IaC providers like Terraform also have features such that it tracks the state of the real-world resources which makes Day-2 and onward operations easier and more powerful and with Azure Blueprints, the relationship between what should be deployed and what was deployed is preserved. This connection supports improved tracking and auditing of deployments. It even works across several subscriptions with the same blueprint.

Typically, the choice is not between a blueprint and a resource template because one comprises the other but between an Azure Blueprint and a Terraform state. They differ in their organization methodology as top-down or bottom-up. Blueprints are great candidates for compliance and regulations while Terraform is preferred by developers for their flexibility. Blueprints manage Azure resources only while Terraform can work with various resource providers.

Once the choice is made, some challenges will be tackled next. The account with which the IaC is deployed and the secrets it must know for those deployments to occur correctly are something that works centrally and not in the hands of individual end-users. Packaging and distributing solutions for end-users is easier when these can be read from a single source of truth in the cloud, so at least the location in the cloud for the solution to read and deploy the infrastructure must be known beforehand.

The DevSecOps workflow has a double loop between various stages including create->plan->monitor->configure->Release->Package->Verify where the create, plan, verify and package stages belong to Dev or design time and the monitor, configure and release belong to operations runtime. SecOps sits at the cusp between these two halves of Dev and Ops and participates in the planning, package, and release stages.

Some of the greatest challenges of DevSecOps are firstly, cultural in that it comes from market fragmentation in terms of IaC providers and secondly, variety of wide skills required for such IaC. Others include definition of well-known code or design patterns, difficulty in replicating errors, IaC language specifics and diverse toolset, security and trustworthiness, configuration drift and changing infrastructure requirements.

IaC Comparisons

When traditionally manual approaches to creation and management of infrastructure for organizational software assets, does not scale, a way to define Infrastructure-as-Code aka IaC for short, is necessary to meet the automation demands in favor of dynamic, dependable, and repeatable infrastructure. Among the popular choices for Azure public cloud are Terraform and ARM templates and Biceps, each of which have their own language and format and are distinct from one another.

The challenges and benefits of these are discussed now. Their main differences are called out first.

Terraform is universally extendable through providers that furnish IaC for resource types. It is a one-stop shop for any infrastructure, service, and application configuration. It can handle complex order-of-operations and composability of individual resources and encapsulated models. It is also backed by an open-source community for many providers and their modules with public documentation and examples. Microsoft also works directly with the Terraform maker on building and maintaining related providers and this partnership has gained widespread acceptance and usage. Perhaps, one of the best features is that it tracks the state of the real-world resources which makes Day-2 and onward operations easier and more powerful.

ARM templates is entirely from Microsoft consumed internally and externally as the de facto standard for describing resources on Azure and with their import and export options. There is a dedicated cloud service called the Azure Resource Manager service that expects and enforces this convention for all resources to provide effective validation, idempotency and repeatability.

In principle, they may both appear similar in their purpose to describe Infrastructure-as-Code but Microsoft owning this convention means that the public cloud will not do away with this format any time soon even as features are developed in newer formats such as Bicep. Bicep provides more concise syntax and improved type safety, but they compile to ARM templates which is the de facto standard to declare and use Azure resources and supported by the unified Azure Resource Manager. Bicep is a new domain-specific language that was recently developed for authoring ARM templates by using easier syntax. Bicep is typically used for resource deployments to Azure. It is a new deployment-specific language that was recently developed. Either or both JSON and Bicep can be used to author ARM templates and while JSON is ubiquitous, Bicep can only be used with Resource Manager Templates. In fact, Bicep has tooling that converts Bicep templates into standard Json Templates for ARM Resources by a process called transpilation. This conversion happens automatically but it can also be manually invoked. Bicep is succinct so it provides a further incentive. The use