Configuration Management, Infrastructure as Code, and On-Demand Infrastructure

This session covers configuration management end to end: what it is and why organizations need it, how to manage application configuration and environment configuration, what infrastructure as code means, how server provisioning used to happen and how it happens with automation, the difference between configuration management and change management, the tools that support both, and finally on-demand infrastructure with auto scaling. The discussion moves in that order, so each piece builds on the one before: configuration needs an environment, an environment needs provisioning, provisioning needs automation, and automation is exactly what infrastructure as code delivers.

17.1 Configuration Management — What It Is and Where It Comes From

17.1.1 Definition and Origins

Configuration management is not a new idea. It started in the 1950s, introduced by the United States Department of Defense, which described it as a technical management discipline. A discipline is a process, and that is the first thing to internalize: configuration management is a process, not a tool or a single practice. Tools support it, but the process is the thing.

Think of an artifact as anything the project touches or produces that could ever need to be changed in a controlled way. The word artifacts is broad on purpose. Artifacts include the policies related to some resources, the processes, the documentation, and the tools required to implement the system of consistent performance, functionality, and attributes. So when you audit whether an organization practices configuration management, you are looking for the whole collection: policies, processes, documentation, and tools — and the relationships among them — all kept identified and changeable in a controlled way.

Why "uniquely identified"? If two files both claim to be "the production configuration" and nobody can say which is which, then an environment rebuild could pick the wrong one. Uniquely identified artifacts mean every artifact has one identity — a name, a version, a location — so the collection has no ambiguity.

17.1.2 The Four-Question Test for a Strong Strategy

How do you know whether an organization — or a project — actually has a strong configuration management strategy? The practical answer is a set of four questions. If you answer yes to all of them, you can conclude the organization or project has a great configuration management strategy.

Question 1 — Can I exactly reproduce any of my environments? If you point at the staging environment, the user acceptance testing environment, the capacity environment, or the development environment, can you rebuild it exactly? Reproducing means the version of the operating system, its patch level, the network configuration settings, the software stack needed for that project (for example, "I need Visual Studio, I need MongoDB"), the application deployed into it, and the configuration of that application. If the answer is yes, that is one mark for a strong strategy.

Question 3 — Can I easily see each of these changes? This is traceability. You should be able to trace back what changes happened, who made those changes, why they were made, and when they were made. If you have that traceability, the strategy is again justified. Traceability is what turns a configuration history from guesswork into evidence: when production breaks at 2 a.m., the first question is "what changed?" — and a strong strategy answers it from a log, not from memory.

Question 4 — Is it easy for every member of the team to get information whenever they need it? And if they have the authority to make changes, does the process actually let them make those changes easily? The process should not block authorized people. Notice the boundary this question draws: information must be easy to get, but change requires authority. The strategy fails if it is so locked down that authorized people fight the process — or so open that anyone can change anything.

If all four answers are yes, the organization or project has a great configuration management strategy.

17.1.3 Configuration Management Reaches Beyond Your Own Code

One caution before moving on: configuration management is not restricted to your own application. Sometimes your application depends on third-party tools and technology — some other application provided by an outside vendor. A strong configuration management strategy has to cover the whole project, including your own code base (which your industry maintains and develops) and the other code or applications your project depends on. That means you should ask all four questions to the third-party vendors who supply the sub-applications you rely on. It is easy to restrict your strategy to the in-house project and forget that it is dependent on someone else's application; confirming that vendors run a similar configuration management process is part of a complete strategy.

Where this matters in the real world: Configuration management has been a formal discipline since the 1950s, when the United States Department of Defense needed weapon systems whose parts, documentation, and changes could be verified consistently across contractors. The same idea powers every modern practice in this course: version control, continuous integration, deployment pipelines, and environment automation all depend on artifacts being stored, identified, and changeable in a controlled way.

17.2 Why Configuration Management Matters

17.2.1 Configuration Controls Behavior at Build, Deploy, and Run Time

Why do these configurations exist at all, and why do you need a strong strategy around them? The core reason: configuration information is used to change the behavior of your software at build time, deploy time, and run time. If you want your software to behave a certain way, you change the configuration information.

Three points in the life cycle give configuration its power:

• Build time — configuration decides what gets baked into the binaries, for example which libraries and which versions of them are compiled in.
• Deploy time — configuration decides where the deployed application points: which database, which messaging server, which external services.
• Run time — configuration decides how the running application behaves, for example which feature flags are on or off.

The same application with different configuration is, in effect, a different behaving system — which is why uncontrolled configuration changes are so dangerous.

17.2.2 Flexibility Comes at the Price of Configurability

Everybody wants flexibility. Imagine implementing an e-grocery application. If a user opens your application on a mobile phone, it should work. If the user opens it in a web browser, it should work — and not only on Firefox, also on Google Chrome. It should not be a Windows-only application; if someone accesses it from a Mac, it should work. If it is a tablet, an iPad — it should not depend on the device. The application must be flexible enough that any user can reach it from any of their devices. That is what the end customer is looking for; customers do not want to be restricted to a single solution, they want everything easily available and easily accessible.

The catch: flexibility usually comes at a cost. To achieve flexibility you need ultimate configurability. Your configuration settings have to cover all of this — a setup ready for that device, that operating system, those browsers. So strong configuration management is the mechanism that makes software flexible.

The same principle appears in the standard literature: the more flexibility you intend to offer users, the more configuration options your system must expose, and the more carefully those options must be managed and tested — because every one of them is a place where the system can be pointed at the wrong thing.

17.2.3 The Myth That Configuration Is Less Risky Than Source Code

Here is a general belief — the myth — that most people hold about configuration information: it feels somehow less risky to change than source code. It deserves a challenge, because the common assumption is backwards.

The lesson that follows: changes to configuration deserve the same discipline, review, and testing as changes to code — more, if anything.

17.2.4 Where to Inject Configuration Information

Configuration information can be injected into the application at several points. At build time you inject things like libraries and their particular versions. You can also inject during deploy time, during testing time, and during your release into the production environment, where it becomes available to the end customer.

The general advice: it is considered a bad practice to inject all the configuration information at build time or packaging time. It is always better to configure your application at deployment time — that is when you can tell it where the services it depends on live, such as the database, messaging servers, or external systems. All of that information is available at deployment time, and the application is then pointed at the right services when it starts.

The last framing point: configuration lives at two levels. An application is not an island — it needs something to be resided on, and that something is the environment. So there is configuration information related to the application and configuration information related to the environment, and you manage both.

Where this matters in the real world: Every production outage investigation begins with "what changed?" — and configuration changes are a top answer. The DevOps community's answer is the same discipline as code: version-controlled configuration, reviewed like a pull request, tested like a build, and applied automatically. Tools like Puppet, Chef, and Ansible (covered later in this session) exist largely to make configuration changes pass through controlled channels instead of being typed by hand.

17.3 Managing Application Configuration

17.3.1 The Considerations

When it comes to managing application configuration, three considerations frame everything:

The variation is real. In the development environment you have the build binaries and libraries — the stuff needed for building the software. In the deployment environment you do not need those; you need only the binaries and libraries on which the application runtime depends. In the test environment you probably need more testing tools — Selenium and similar tools. In a production-like environment you just need the user acceptance testing tools, not the other testing tools. Your configuration settings change as per the environment, as per the application, and as per the version of the application:

17.3.2 Modeling Configuration as Name–Value Tuples

The first solution for representing configuration: model each configuration setting as a name and value pair. If there is a name, there is a value: for the setting "JRE", the value might be 7 or 8; for "Tomcat", the value describes the version; and you can also carry a status such as "always running". Model them as a tuple — the name and the value of that particular configuration.

Once you have tuples, where do you store them? Three options: a database, a version control system, or a directory or registry from which you access them. The best solution is the version control system. Why? As your configuration information grows and you manage it in a database or a directory, you lose the ability to track who made what changes over time and what kind of changes happened — you lose traceability. With a version control system you get great traceability almost for free: just check in the configuration file and you have the history of your configuration over time. It is also worth keeping a list of the available configuration options for the application in the same repository where you keep your source code — though, and this is a recurring theme, your values can be kept somewhere else.

17.3.3 How Deployment Fetches Configuration

How does this work at deploy time? Your deployment environment passes the deployment environment name to your script. The script then fetches the appropriate configuration from the configuration services and makes the application available — perhaps by placing the configuration as a file on the file system.

17.3.4 When Configuration Values Change

Each configuration setting can be modeled as a tuple, so the configuration of any application is a set of tuples. A tuple's value typically depends on three things: what application it is, what version of the application it is, and what kind of environment it is — development, UAT, performance testing, staging, or production.

Given that model, when do you change the configuration information?

• Whenever you add a new environment, you should change the configurations — a new environment needs a new set of values for the applications deployed into it.
• Whenever you create a new version of the application, you need to add this new version — new versions introduce new settings and retire old ones.
• Whenever you promote a new version of the application from one environment to another, changes are likely needed — the new settings must exist in the new environment with that environment's values.
• If you are relocating your database server, you definitely need to change the database server IP address in the configuration information — every setting that references the old database must point at the new one.

These are the use cases where configuration changes typically happen.

17.3.5 Principles of Application Configuration Management

The principles come straight out of the considerations above:

• Keep the available configuration options in the same repository as your source code, but store the values somewhere else. Why store values elsewhere? Because the life cycle of code is different from the life cycle of a configuration setting. Configuration settings sometimes carry passwords, and passwords and sensitive information are really sensitive: they should be managed with a different life cycle, given access only to authorized people, and restricted from all team members. If somebody changes a password or sensitive information, it directly impacts the application. So the values never go into version control — they live in some other file or location, and your script accesses the values from that location.

• Configuration should always be performed by an automated process, using values taken from a configuration repository. Then you can always identify the configuration of every application in every environment. Because it is an automated process you can trace it and you can have logs of the configuration changes. Replication becomes easy: executing the script once and re-running it gives the same output.
• Configuration scripts should be tested the way source code is tested. Since you are writing a script, the script itself must be tested.
• Follow clear naming conventions. Just as there are good practices for writing source code, there are good practices for writing scripts; the naming convention should make the purpose of each configuration clear. A name like db.host needs no manual; a name like x does.
• Keep configuration information modular and encapsulated. Modularity matters because if you change something at one place, it should not impact other, subsequent places; modifications should stay easy to make.

Real-world: this is the pattern industry follows — configuration information kept in the same repository as the source code, sensitive values kept in a separate, access-controlled location, and automated retrieval at deploy time.

17.3.6 Testing Configuration Scripts

Testing a configuration script is not the same as testing source code; the testing happens in two parts.

Where this matters in the real world: This is the everyday reality of deployment engineers: environment-specific value files, secrets managers (which exist precisely because passwords must never sit in version control), and deployment scripts that fetch the right values by environment name. When a production incident is traced to a wrong db.host, it is almost always a failure of one of these principles — values in the wrong place, scripts not tested, or changes made by hand.

17.4 Managing Environment Configuration

17.4.1 No Application Is an Island

Every application depends on hardware, software, infrastructure, and external systems in order to work — no application is an island. It needs something to run on, and that something is the environment. Any application also depends on configuration like your port number, your messaging bus, and what kind of operating system configurations are in place. These are the facts that every application needs, so managing the environment's configuration is unavoidable.

The environment's configuration matters as much as the application's. An application that depends on a messaging bus fails if the bus is misconfigured, even though the application's own configuration is perfect. An application that needs many file descriptors fails if the operating system default limit is lower than the application needs. Both failures look like application bugs — but neither is fixable by changing the application.

17.4.2 The Problems with Environment Configuration

Managing environment-related configurations comes with a familiar set of problems:

• Large collections are hard to maintain. If the collection of configuration information is very large, maintaining and managing the environment's configuration settings becomes really difficult.
• Small changes can break everything. A small change to the environment can break the whole application or severely degrade its performance. As discussed earlier, this is riskier than changing source code.
• Diagnosis is slow and expensive. Once the environment breaks down, it is really difficult to find out why that particular thing failed. Fixing it takes an unknown amount of time and requires senior personnel — you involve your level-three experts, and you escalate the issue from level one to level two to level three before a senior person solves it.
• Manual reproduction is nearly impossible. It is extremely difficult to precisely reproduce a manually configured environment for testing purposes. It takes a long time to manually reproduce the same kind of testing environment or the same pre-production (also called mid-art production) environment.
• Environments drift apart. Without configuration, it is difficult to maintain environments, and so the behavior of different nodes drifts apart.

17.4.3 The Best Way: Automate, and Recreate Rather Than Repair

The best way to create a new environment is a fully automated process. And the key principle that follows: it should always be cheaper to create a new environment than to repair an old one. If an environment got broken, finding the problem and fixing it takes time — so why not have a process that makes creating a new environment cheaper? You can simply shut down that instance of the environment, create a new environment using the script, and perform the testing on it. That is the best way, and you achieve it with a fully automated process.

The recreate-not-repair principle has a cascade of benefits: environment creation is repeatable (same script, same result every time), predictable in time (minutes instead of days), and auditable (the script itself records what the environment contains). Repairing, by contrast, depends on whoever happens to investigate, on what they remember, and on what they changed by hand along the way.

17.4.4 What Environment Configuration Must Cover

When you capture environment configuration, the kinds of information you should be concerned about are:

• The operating systems in an environment, including their versions (minor and major), patch levels, and configuration settings.
• The extra software packages that need to be installed on each environment to support the application, including their version and configuration. For the development environment, a developer might need Notepad++ and various development-related tools and development kits — but those are not required for the testing environment. So you must record which package, which version, and which configuration settings apply per environment.
• The networking topology required for your application to work.
• The external services your application depends upon, including their versions and configurations.
• Any data or other state that should be present — for example, the production database, and what values those particular data sets should have.

Where this matters in the real world: Every cloud-based team practices recreate-don't-repair daily: when a build agent or test server misbehaves, the standard move is to terminate the instance and spin a fresh one from the image or provisioning script rather than SSH in and repair it. Organizations that keep "works of art" servers — each one lovingly hand-configured — are precisely the ones where the five problems above become daily firefighting.

17.5 Infrastructure as Code

17.5.1 What Infrastructure as Code Means

You need an environment before you can maintain its configuration. How do you create that environment — with the right operating system, the right software packages — in an automated way? That is what infrastructure as code (IaC) is.

Nobody wants to go to the command prompt and place commands every time, following a checklist — do this, do this, do this — and then keep the environment ready. Everybody is looking for a solution where you have written a script, and whenever you want the environment you just run that script (fetching it first if needed), and the environment is ready.

17.5.2 Why Infrastructure as Code Fits the DevOps Culture

Infrastructure as code is what DevOps looks like in practice. Operation teams now know how to write a script — they know the logic and the code because they write scripts for the infrastructure. Software developers, meanwhile, manage the configuration information related to the application during source code writing, so they understand the configuration part as well. The result: it is not two different teams anymore; they are collaborated teams who understand each other's pain points. The wall from earlier sessions comes down because both sides now speak code.

There is also a fundamental constraint that IaC removes. In generic software development you need an environment to implement software — even to write code, you need a development environment ready. Once your code is written, you need a testing or staging environment that mirrors your live or production environment as closely as possible. Creating that mirror image of the production environment is a fundamental constraint for every organization, and infrastructure as code is the only way that assures the exact mirror image. Once you have a staging environment equivalent to production, you can be confident that new code — the changes made to the application — will not crash with the existing code definitions, because you tested it in a production-like place. That boosts the team's confidence that the new change will work fine in production.

17.5.3 How Environments Were Created Before Infrastructure as Code

Before IaC (and before DevOps), infrastructure creation was a manual, ticket-driven chain. When the test team wanted a testing environment, they raised a ticket to the system admin team saying so-and-so environment is needed. The system admin team created and set up the environment, trying to mirror the live environment by manual steps — trying their level best to make it production-like. Once the environment was created, the ticket went to the DB admin team, which set up and created the database environment and then handed it over to the development team, because the development team would deliver the code into that environment. Then it was handed over to the testing team, which performed several operational and compliance tests. After all that succeeded — if everything was green — the code hit the production environment. Every handoff and every step was manual, the delivery teams had no control, and it consumed time. With DevOps the goal is to do this as fast as possible so you hit the market early — reducing the time to market — and that is where infrastructure as code comes in.

17.5.4 The Infrastructure as Code Workflow

Here is how the process looks with IaC. The developer writes the code and writes down the configuration dependency information for that application — a note of it. Everything is checked into a version control system. Then, for the tool that performs infrastructure as code, you write a script describing what you need: what kind of database, what appliances should be there, what kind of testing tools are required, what delivery tools need to be there, and many more resources along with their configuration values. This script is fed to the configuration management tool. The tool runs the script and creates a new virtual machine with the application, fetching that application and its configuration information from the source code version control system. Everything else mentioned in the script is done by the configuration management tool. The mirror live environment is readily available for the tester. The script is probably written by a team that is expert in writing scripts, but the tester just fetches the script and runs it — and by themselves they have the mirror live environment where the team can perform automated testing.

17.5.5 Benefits of Infrastructure as Code

The benefits of IaC, point by point:

• Reduced shadow IT. You no longer have to manually observe the process; IT activity is visible through code. When infrastructure is defined in scripts in version control, there is nowhere to hide a shadow server or an undocumented change.
• Improved customer satisfaction. You reduce the timeline, so customers get what they want sooner.
• Reduced OPEX (operating expenses).

• Reduced CapEx (capital expenditure). Capital expenditure is a long-term goal for any industry. In the same example of a hundred servers, you need not only the 10 people; you may need third-party vendors for network management, network components, and other services — capital expenditure going out to third parties. With automation, the network topologies get managed by your script, and those 10 people become skilled enough — after training — to write code and understand network topology. In the future, managing those 1000 servers may not require depending on the third-party vendor at all, so capital expenditure also gets reduced.
• Standardization. With a script, the process is standard. The manual approach was not: one person would create a folder, copy a particular application into it, and fetch the values through a file system in the production or production-like environment. It varied person to person — the folder names, the norms, the checklist documents. If a person refers to that document and performs the steps manually, there is a high chance of human mistakes: missing a step, or a spelling mistake. Infrastructure as code standardizes the rules everyone follows.
• Safer change management. Change management becomes safer because changes are made through reviewed, versioned code.

17.5.6 Risks of Infrastructure as Code

No benefit comes freely — as the saying goes, nothing can be achieved without efforts. You have to train yourself to achieve these benefits. The risks of IaC:

• No proper planning. If the organization does not plan properly before implementing infrastructure as code, you will not see fruitful results — rather, you will see a high amount of penalty for your applications and their support. Planning must consider that infrastructure as code requires a new kind of skill: hiring people with that skill set, and giving proper training so they actually use the concept correctly.
• Error replication. Even though IaC is automated, you are writing a script, and no tool writes the script for you — you write it manually. If you write something wrong in the script itself, that error replicates everywhere, in all your environments. Training matters precisely because of this. A one-line mistake in a script is no longer a one-machine mistake; it is a fleet-wide mistake.
• Configuration drift. Drift in the script itself: say you wanted JRE 7, but by mistake the script says 8. In the desired state you declared JRE 7, but the actual configuration reads JRE 8. Your configuration tool will then be in a configuration drift — it will do 7, then 8, then 7, then 8, flipping back and forth between desired and actual state.

• Accidental destruction. Because the whole environment is defined by a script, if somebody deletes a line in that script — accidentally or not — there is an accidental destruction of infrastructure as well. The next run of the script removes the resource that line described.

These are the risks, and the industry should be ready to understand them when adopting infrastructure as code.

Where this matters in the real world: IaC is the everyday language of cloud operations: Terraform and CloudFormation define cloud resources as code, while Puppet, Chef, and Ansible keep servers in their desired state. The Puppet State of DevOps reports repeatedly link infrastructure-as-code adoption with IT performance; the 2021 report quoted an infrastructure-as-code adoption score of 83.5, the statistics referenced later in this session.

17.6 Server Provisioning

17.6.1 The Traditional Provisioning Steps

Provisioning a server, at its heart, is a small number of steps. First you have to set up the hardware. Then you have to install and configure the particular application — or the prerequisite tools. For example: the setup is ready, now you need Java, so you install Java; then you need to set the system variable path, so you go and set that path — that step itself is configuration. Then you install and configure the application you want on that environment. All of these are the steps of provisioning a server. Anyone from an infrastructure background will tell you the same sequence: hardware, tooling, configuration, application.

17.6.2 The Automated Provisioning Path: DHCP, PXE, and TFTP

Now think about the automated approach to provisioning — how it used to happen even before IaC. When we say "setup the hardware", how did a new server get recognized? With the help of the Dynamic Host Configuration Protocol (DHCP): the server requests an IP address so it can be recognized in the network, and it receives a response to that particular request. Once the IP address is given, with the help of PXE — the Pre-boot Execution Environment — the server requests a boot image: which boot image it needs, by file name. Then, with TFTP — the Trivial File Transfer Protocol — the requested file of the boot image is provided to the server. The server runs that boot image and becomes up and usable as a server where you can install your application and other stuff. Once the server is ready, the admin used to download and install the particular applications and related dependent applications, and set up the configuration information on that server. That is how provisioning used to happen.

17.6.3 Provisioning as Part of Infrastructure as Code

Everything described above — installation, configuration, even the provisioning itself — can be managed with infrastructure as code. You can provision the infrastructure with the help of IaC. The benefits: you reduce the maneuvers for installation and configuration, you reduce operational cost, you reduce errors, and it is better for quality assurance. Those are the benefits one can think of for infrastructure as code, alongside the risks already discussed.

Where this matters in the real world: DHCP + PXE + TFTP is still how bare-metal data centers, HPC clusters, and on-premise fleets bootstrap machines at scale. Cloud platforms hide the chain (an EC2 instance starts from a stored image instead), but the same logic survives: identity → image selection → transfer → boot. Understanding the chain explains how an "empty" machine can join a network and become usable with zero human steps.

17.7 Configuration Management vs Change Management

17.7.1 The Classroom Debate

Are configuration management and change management the same thing? They sound close, and the confusion is common — so it is worth resolving precisely.

17.7.2 Change Management: The Approval Process

Change management carries its own process machinery. There is a change board authority that makes the decision of whether a particular change has to be implemented or not, and there are further processes for getting the change approved if it is fruitful. Even for a feature — if you are changing something in a feature — it needs a change advisory board to make the decision. So changes do not just happen; they pass through an approval body that weighs the benefit and the risk.

17.7.3 From Documents to Code: Configuration as Code

How was it traditionally? Your infrastructure was a document: you followed a checklist for creating a server, installing everything, and making sure all those commands ran successfully. Your configuration was also a document: you did configuration management manually by referring to a document that recorded, for this application, what kind of software libraries and binaries are needed, what other resources are needed, and what the versions of those resources are.

The new approach changes both. We want infrastructure as code, and we also want configuration as code — defining all the configuration of your server or any other resources as code or as a script, and checking it into version control. Now your infrastructure as code and your configuration as code are scripts maintained in the version control system. And if you remember the earlier question of what all things can be version controlled: every activity of your software development life cycle that involves code can be kept in version control — designs, documents (for example with Confluence), test scripts, source code, and configuration management code.

The documents did not disappear — they became executable. A document tells you what to do; code does it. That shift is the essence of configuration as code.

17.7.4 Tools for Configuration Management and Infrastructure as Code

What tools and technology in the market support configuration management and infrastructure as code, both? The list includes Chef, Puppet, Ansible, Terraform, CloudFormation, and many more. The discussion here focuses on Puppet, Chef, and Ansible, because those are what most people opt for. Terraform is the choice when you already use tools and technology from the same provider; otherwise Puppet, Chef, and Ansible are the most widely chosen. Ansible got very hyped when it was launched, and many industries moved from Chef to Ansible; still, Puppet and Ansible are actively competing in the market. One key distinction among these tools: agent-based versus agent-less approaches — Puppet and Chef are agent-based, whereas Ansible is agent-less. The next session digs into how Puppet works, what the components of Chef are, how Ansible works, and why Ansible received the most response in industry.

The agent-based versus agent-less distinction matters operationally: agent-based tools require a small program (the agent) installed and running on every managed machine, whereas agent-less tools need nothing installed on the target — a major simplification for environments where installing agents is hard or undesirable.

Where this matters in the real world: Change advisory boards are a formal reality in regulated industries (banking, healthcare, government), where change tickets must show approval before production touches. Meanwhile the tool ecosystem this section names is the daily toolkit of DevOps teams: configuration management tools keep servers in a desired state, and provisioning tools like Terraform and CloudFormation create cloud resources — the two families solving the two halves of the state-versus-change picture.

17.8 Managing On-Demand Infrastructure

17.8.1 The On-Demand Mindset

Do we still need to order a server and then perform server provisioning with infrastructure as code? Do we still think we need to order hardware? The answer is no — because everything is on-demand now.

The point of the analogy is a mindset shift, not a metaphor: the consumer of computing infrastructure should have the same experience as a shopper — browse, pick, order, receive — instead of the buyer of capital equipment — request, purchase order, wait for delivery. Infrastructure is the one thing that used to be treated differently from every other purchase in life, and the cloud removed that exception.

17.8.2 The Cloud Ordering Flow

On-demand infrastructure is provided by the cloud provider. You do not purchase hardware, make a purchase order, and wait for delivery. As a service consumer, you look at the cloud provider's service catalog, opt for the particular service you need, place an order, and the infrastructure is available to use. Then you perform your infrastructure as code provisioning — what kind of OS you want, what other applications you want. Once the infrastructure is ready, you deploy your application and maintain its configuration information throughout the lifecycle of the application. Cloud got this attractive because it makes life easy, and that is what everybody is looking for in the market.

17.8.3 New Topics Powered by the Cloud

The cloud gave birth to a couple of new areas people invest time in learning. DevOps for cloud platforms — how can you achieve DevOps in cloud computing — is one topic currently going on. MLOps is another: if we do software development with a DevOps culture, why can't we do machine learning development with a DevOps culture? There was already the topic of software engineering for machine learning — what kind of software engineering one should have to implement machine learning related applications. MLOps is the DevOps culture applied to machine learning development software, and for MLOps you can ask which cloud platform you have and what kind of DevOps pipeline you can think of for that platform. All these topics emerged because the cloud is used hugely in the market. Many cloud providers offer SaaS, IaaS, and PaaS — already discussed — and one more: function as a service (FaaS), also called serverless computing. Serverless or function as a service will be covered in the final session when discussing current trends and concluding the course.

The pattern to notice: each step up the stack hides more of the environment — which is why serverless architectures (from the knowledge check later in this session) count as a driving force changing the job of operations: even when the servers vanish, the configuration of your application still has to be kept in the desired state.

17.8.4 Cloud Adoption Numbers

Look at the statistics of on-demand infrastructure consumption: every domain is accessing cloud platforms. The graphs for software as a service, and the other service models, are steadily increasing. Infrastructure as a code reached 83.5 by 2021 — and the updated graph is in the Puppet report, which was shared for the DevOps topic and covers cloud as well; you can find those stats in the Puppet report.

The consumption of particular cloud providers: 41.5% of industries use Amazon Web Services; Microsoft Azure is at 29%; Google Cloud at 3% — a percentage that has increased because of the new features Google launches in its cloud platform; IBM at 2.6%; Rackspace at 2.9%. The rest, about 20.7%, use other cloud providers, including private clouds — a few organizations create their own cloud, a private cloud network, inside their industry. That is the market picture.

17.8.5 Benefits of On-Demand Infrastructure

The benefits of on-demand infrastructure:

• Cost saving. You pay for what you use rather than purchasing and maintaining hardware. Capital expense becomes operating expense, and the bill scales with actual use.
• Scalability and flexibility. Both are achieved easily with on-demand infrastructure — scalability was already touched on when discussing capacity management. Resources grow and shrink as demand changes.
• Faster time to market. You remove the time of purchasing hardware and waiting for delivery. It becomes clicking on a particular service and clicking the next button, and you have that server.

• Support for DR and high availability. Because environments are defined and reproducible, disaster recovery means spinning up again somewhere else — not rebuilding from memory.
• Focus on business growth. If you are a startup, you want to achieve business rather than spending on hardware and software. You order the infrastructure, deliver your application, start earning revenue, and then upgrade the infrastructure as your need grows.

Where this matters in the real world: On-demand infrastructure is the economic base of modern software: startups launch with rented capacity instead of data center capital, enterprises burst into the cloud for peak loads, and the same catalog ordering that spins up a VM in minutes powers disaster recovery — a whole second site can be created from scripts rather than from hardware.

17.9 Auto Scaling

17.9.1 What Auto Scaling Does

One fantastic feature of cloud providers is auto scaling. Auto scaling typically means not only increasing capacity — you can also decrease capacity by shutting down instances of your virtual machines. That scaling down offers savings on power and energy, which ultimately results in cost saving: for companies hosted on the cloud, auto scaling can mean lower bills.

17.9.2 Schedule Auto Scaling

There are two approaches. Schedule auto scaling is nothing but short-term capacity planning that is automated — here you do not need manual intervention.

17.9.3 Predictive Auto Scaling

Predictive auto scaling is long-term capacity planning. The idea is to combine recent usage. You cross-check what your recent usage is against what your historical usage was. If you see a huge difference and traffic on your application is increasing, you predict the future usage and accordingly order extra infrastructure and resources from the cloud provider. So: schedule auto scaling handles known, short-term spikes; predictive auto scaling plans for growth based on trend data.

The two approaches answer different questions. Schedule asks "when is the spike?" Predictive asks "where is usage heading?" A mature setup uses both: scheduled scaling for known events and predictive scaling for the underlying growth trend.

17.9.4 Who Offers Auto Scaling

Every cloud provider now offers auto scaling. The history:

• Amazon Web Services was the first pioneer to launch the auto scaling feature. AWS has elastic load balancing, which helps achieve auto scaling.

• Microsoft Azure — around 2013, Microsoft announced auto scaling support for its Windows Azure cloud computing platform.
• Oracle — the Oracle cloud platform allows server instances to automatically scale a cluster in or out by defining auto scaling rules.
• Google Cloud Platform — in 2015, Google announced the public beta of the auto scaling feature of its Cloud Computing Engine. It is free for use. Google Cloud is a bit complex when compared with AWS and Azure, but many of its features are freely available. If you want to learn all these features without spending any money — spending your time instead on understanding and configuring them — then Google Cloud is a good choice for getting your hands dirty with the different features of cloud providers.

Where this matters in the real world: Auto scaling is what makes "the site didn't go down during the sale" possible — e-commerce giants schedule capacity for shopping festivals, streaming services ride daily traffic curves, and startups survive viral spikes they could never have provisioned by hand. The billing insight (pay per use, not per capacity) is why auto scaling is not just an availability feature but a cost-control feature.

17.10 Knowledge Check Review

The session closed with a quick knowledge check — three questions that review the themes of the whole discussion.

17.10.1 Question 1: Ops Needs Documentation for Deployment

17.10.2 Question 2: Driving Forces Changing the Job of Operations

17.10.3 Question 3: Factors for Troubleshooting and Isolation

Recap: The knowledge check confirms the session's spine: configuration management tools (not documents) are the DevOps-friendly answer to Ops's deployment complaints; infrastructure as code and serverless architectures are the driving forces changing operations — because even serverless configurations must stay in the desired state; and troubleshooting and isolation come from the whole set: automated configuration management, strong test coverage, automated load balancing and failover, and infrastructure as code.

Exam Guidance Summary

• Fourth quiz: The three knowledge-check questions above preview it. Expect questions on configuration management tools as the DevOps-friendly answer, infrastructure as code and serverless architectures as the driving forces changing operations, and the full set of factors for troubleshooting — automated configuration management, strong test coverage, automated load balancing and failover, and infrastructure as code.
• Core definitional content to know: the definition of configuration management (1950s, United States Department of Defense, technical management discipline) and the four-question test for a strong configuration management strategy (reproduce environments exactly, make incremental changes smoothly, trace changes, and let authorized team members get information and make changes).
• Application vs environment configuration: the considerations (representation, script access, variation by environment and version), the name–value tuple model, storing options in the source repository and values elsewhere, the principles (automated process, tested scripts, naming conventions, modularity), and the two-part configuration testing approach (verify external service references and fail fast on missing dependencies; then smoke test including desired-state convergence).

• Environment configuration: the five problems of manual management (large collections hard to maintain, small changes break everything, slow diagnosis with level-three experts, near-impossible manual reproduction, node drift) and the recreate-don't-repair principle — it should always be cheaper to create a new environment than to repair an old one.
• Infrastructure as code: the definition (machine-readable definition files that generate service components, programmable infrastructure), the benefits (less shadow IT, customer satisfaction, lower OPEX and CapEx, standardization, safer change management), the risks (planning, skills and training, error replication, configuration drift, accidental destruction), and the traditional ticket-driven flow versus the modern script-driven workflow.
• Server provisioning: the traditional steps (hardware, install and configure tools like Java plus the system variable path, install and configure the application) and the automated path — DHCP for the IP address, PXE for the boot image request, TFTP for delivering the boot image.
• Change management vs configuration management: configuration management maintains the desired state of infrastructure and software; change management is the process governing changes to both configurations and applications, with a change board authority and a change advisory board approving changes.
• Tools: Puppet, Chef, and Ansible (agent-based: Puppet and Chef; agent-less: Ansible), Terraform and CloudFormation; tools are examined in the next contact session.
• On-demand infrastructure and auto scaling: cloud service catalog ordering, EC2-style instant provisioning, the two auto scaling approaches (schedule auto scaling for short-term planned spikes such as the Flipkart Big Billion Day or Amazon Great Indian Sale; predictive auto scaling for long-term capacity planning from recent and historical usage), and the provider timeline — AWS first, Azure 2013, Oracle, Google 2015.
• Schedule and dates: the comprehensive exam is on the 25th and 26th of this month. Assignments are to be uploaded by the 13th; evaluation happens around the 21st–22nd, with results by the 22nd–23rd. Plan your preparation so the assignment is done before the exam window.
• References: use the textbook mapping for this session's material, and for infrastructure as code refer to the blog on infrastructure as code, which was recommended for self-learning. The Puppet report covers DevOps and cloud statistics including the infrastructure as a code adoption numbers.

Key Industry Applications

• Real-world: configuration management as a discipline traces to the United States Department of Defense in the 1950s.
• Real-world: e-grocery applications must work across mobile, web browsers (Firefox, Chrome), operating systems (Windows, Mac), and devices (tablet, iPad) — flexibility through configurability.
• Real-world: common environment software stacks such as Visual Studio and MongoDB, and tools like Selenium for test environments and Notepad++ plus development kits for developer environments.
• Real-world: JRE and Tomcat dependency management — e-grocery 1.1 needs JRE 7 while 1.2 needs JRE 8; configuration drift shows up as a tool flipping between JRE 7 and JRE 8.
• Real-world: the bare-metal boot chain of data centers — DHCP for IP assignment, PXE for boot image selection, TFTP for boot image transfer.
• Real-world: configuration management and IaC tools — Chef, Puppet, Ansible (agent-based versus agent-less), Terraform, CloudFormation; Ansible drew many teams away from Chef, and Puppet and Ansible actively compete.
• Real-world: version control of everything in the SDLC — source code, test scripts, designs, documents (Confluence), and configuration management code.
• Real-world: SRE and DevOps are the highest-paying labels for operations people who combine infrastructure and configuration management skills with scripting and automation.
• Real-world: on-demand infrastructure from cloud providers — AWS EC2 instances spin up in moments from a service catalog; the largest consumption shares are AWS (41.5%), Microsoft Azure (29%), Google Cloud (3%), IBM (2.6%), Rackspace (2.9%), and others/private clouds (20.7%), per the Puppet report.
• Real-world: auto scaling consumers and platforms — Netflix on AWS with elastic load balancing and rolling upgrades, the Flipkart Big Billion Day and Amazon Great Indian Sale traffic spikes, AWS as the pioneer, Microsoft Azure 2013, Oracle's rule-based cluster scaling, and Google Cloud's free 2015 auto scaling beta.
• Real-world: container orchestration with Kubernetes for scaling containerized workloads, and emerging fields — DevOps for cloud platforms, MLOps, software engineering for machine learning, and serverless computing (function as a service).