Chapter 3: Infrastructure as Code

Maya’s Friday afternoon standup in Week 1 had gone better than expected.

Sarah and Priya had demonstrated a working Python script that automated the PeopleTools patch download process. This was a task that typically consumed half a day of manual clicking through Oracle Support, checking versions, and organizing files into the correct directory structure. Their script took twelve minutes.

Jake had completed his disaster recovery test. The actual RTO? Fourteen hours and twenty-two minutes, which was better than his pessimistic estimate, but still unacceptable by modern standards. He’d documented every step, identified three configuration errors in the backup scripts, and updated the runbooks. “At least now we know,” he’d said.

Marcus had delivered a compelling one-page proposal for OpenSearch-based log aggregation, including a cost estimate ($3,200/year for hosted OpenSearch vs. $0 for self-hosted on existing infrastructure) and a clear value proposition: “Instead of SSHing into seventeen servers and grepping logs for forty minutes, we could search centralized logs in under two minutes.”

Tom had documented the development environment’s configuration, covering everything from Oracle initialization parameters to Tuxedo domain settings to web server tuning. “It was even more complicated than I thought,” he’d admitted. “No wonder new people take six months to understand our environment.”

Lisa had thoroughly tested Sarah’s patch script, found two edge cases that broke it, and worked with Sarah to fix them. “It actually works,” she’d reported, sounding surprised. “We could use this for real.”

Maya had sent her first weekly status report to Robert Harrison with actual metrics: baseline deployment time (6.5 hours average), baseline MTTR (2.3 hours), baseline environment provisioning time (18 days), baseline DR RTO (14.4 hours). All of these were terrible numbers. But now they were documented, measured, and ready for improvement.

Harrison’s response had been brief: “Good start. Show me better numbers next week.”

Now it was Monday morning of Week 2, and Maya had gathered the team for what she knew would be the hardest conversation of the twelve-week challenge.

“Week 2,” she announced, “is when we stop scripting and start engineering.”

Tom looked up from his coffee. “What’s the difference?”

Maya pulled up a slide on the conference room screen. “Scripts are how you automate a task. Infrastructure as Code is how you automate an entire system. Scripts are what got us through Week 1. IaC is what gets us to Level 3.”

She clicked to the next slide: a comparison table.

Scripts vs. Infrastructure as Code:

Scripts

• Procedural (do this, then this)

• Imperative commands

• Hard to maintain

• Environment-specific

• No version control standard

• Manual sequencing

• Hope it works

Infrastructure as Code

• Declarative (make it look like this)

• Desired state

• Self-documenting

• Portable

• Git-native

• Dependency management

• Testable and repeatable

“Here’s our goal for Weeks 2 and 3,” Maya said. “We’re going to take Tom’s 847 lines of documentation and turn it into infrastructure code that can provision a complete PeopleSoft environment, including database, application tier, web tier, and everything else, from scratch. On Google Cloud Platform.”

The room went very quiet.

Jake broke the silence. “Using what tools?”

“Terraform for infrastructure provisioning,” Maya said. “Chef for configuration management. Git for version control. Industry standard stack used by thousands of companies.”

“I don’t know Terraform,” Jake said flatly.

“None of us do,” Maya replied. “We’re going to learn.”

“Maya,” Tom said carefully, “I’ve been doing PeopleSoft infrastructure for fifteen years. I’ve written hundreds of shell scripts. Bash, PowerShell, and even some Perl back in the day. I know how to automate. Why do I need to learn a new tool?”

Here it was. This was the resistance Maya had been expecting.

She sat down across from Tom. “Tell me about your shell scripts. The ones that provision environments.”

“What about them?”

“How many do you have?”

Tom thought. “Maybe… twenty? Thirty? For different tasks.”

“And when you need to provision a new environment, you run them in sequence?”

“Right. First, the OS configuration script, then the Oracle install script, then the PeopleSoft app tier script—”

“And if one fails partway through?”

“I fix whatever broke and rerun it. Sometimes I have to clean up partial installations first.”

“And if someone else needs to run your scripts?”

Tom shifted uncomfortably. “They’d need to know the sequence. Some scripts use hard-coded paths that need to be updated across environments. And there are dependencies between scripts that aren’t obvious unless you know what you’re doing.”

“So your scripts work great,” Maya said, “if you’re the one running them, in the right order, with the right environment-specific changes, and nothing fails. How long would it take to teach someone else—say, Sarah—to provision an environment using your scripts?”

“I don’t know. A few weeks? She’d need to shadow me through a few builds.”

“And if you got hit by a bus tomorrow?”

“Please stop using that example,” Tom said.

“The point stands,” Maya replied. “Your scripts are better than nothing. They’ve served us well. But they’re not infrastructure-as-code. They’re Tom Patterson as code. And we can’t build a modern operation on tribal knowledge, no matter how well-scripted.”

Jake jumped in. “I’ve got the same thing with my Oracle automation. My scripts work because I wrote them and I know all the gotchas. But Maya’s right; they’re not transferable. When we hire someone new, it takes six months before I trust them to run a database build without me watching.”

“Exactly,” Maya said. “Infrastructure as Code solves this. With Terraform, we declare what infrastructure we want and how we want it. The Terraform code says we want these VMs with these specs, this database with these parameters, these network routes, these firewall rules. Terraform figures out how to make it happen. The code is self-documenting. It’s in Git, so we have version control and change history. It’s testable. And most importantly, it’s repeatable. Run it once, run it a thousand times, you get the same result.”

“But I don’t know how to write Terraform,” Tom repeated.

“You didn’t know how to write shell scripts fifteen years ago either,” Maya said. “You learned.”

“I was thirty then. I’m forty-five now. Learning gets harder.”

Sarah spoke up. “I’m twenty-six, and I’m learning this stuff alongside you. If you want, I can help. Terraform syntax is different from bash, but the concepts aren’t that foreign. You’re still describing what needs to happen. You’re just doing it in a different language.”

Tom looked at Sarah, then at Maya. “This is really happening? We’re throwing out fifteen years of scripts and starting over?”

“Not throwing out,” Maya corrected. “Evolving. Your scripts taught us what to automate. Now we’re making that automation maintainable, scalable, and cloud-native. By Week 3, we’ll have infrastructure code that can spin up a complete PeopleSoft environment in under two hours instead of eighteen days.”

“Two hours?” Tom’s skepticism was evident. “For a full PeopleSoft stack?”

“Two hours,” Maya confirmed. “That’s the power of IaC on cloud infrastructure. No waiting for the infrastructure team. No manual installations. No configuration drift. Just code, version control, and automation.”

Jake leaned back in his chair. “Okay, I’ll bite. Walk us through what this actually looks like. Not the code itself; just conceptually, what are we building?”

Maya smiled. She’d prepared for this.

The Architecture Conversation

Maya pulled up a diagram she’d sketched over the weekend. “Let’s talk about how we’re going to structure this. The key to good infrastructure-as-code is modularity. You start by breaking the whole system into logical, reusable pieces.”

She pointed to the diagram showing five boxes: Network, Compute, Database, Storage, and Configuration.

“We’re going to build five modules,” Maya explained. “Each one is responsible for one piece of the puzzle. The Network module handles VPCs, subnets, firewall rules, and load balancers. The Database module provisions our Oracle Cloud SQL instance with all the right parameters. Compute handles the VMs. This’ll build application servers, web servers, and process schedulers. Storage manages our file shares and backup buckets. And Configuration is where Chef comes in, actually, to set up the software.”

“Why break it up that way?” Marcus asked.

“Reusability,” Maya said. “Let’s say we get the Network module working for dev. That exact same module can be used for QA, stage, and prod. All we need to do is pass in different parameters. Same code, different inputs, different environments. That’s how we guarantee environmental parity.”

“And it’s maintainable,” Sarah added. “If we need to change how networking works, we change the Network module. We don’t have to hunt through seventeen different shell scripts trying to find where firewall rules are configured.”

“Okay,” Tom said slowly. “I can see the value in organization. But what’s the actual workflow? How does this replace what we do today?”

Maya walked to the whiteboard. “Today, when you need to build an environment, what’s the process?”

Tom recited from memory. Submit a ticket to the infrastructure team for VMs. Wait a week. Get VMs. Spend two days installing and configuring the OS. Call Jake to install Oracle, which takes him two days. Wait for Jake to finish. Install the application tier, which takes me three days if nothing breaks. Configure domains, set up web servers, which takes another two days. Testing connectivity and fixing issues takes another day. So, best case, seven to eight days of actual work spread across three weeks of calendar time.”

“And every environment is slightly different because they were built at different times by different people using slightly different procedures,” Maya said.

“Right,” Tom admitted.

“Now here’s the new workflow,” Maya said. “Someone, it really doesn’t matter who it is, goes to the infrastructure repository in Git. They navigate to the environment they want to build. They run three commands: terraform init, terraform plan, and terraform apply. Then they go get coffee for ninety minutes. When they come back, the environment is running.”

“That’s it?” Lisa asked.

“That’s it,” Maya said. “Terraform reads the infrastructure definition, figures out what needs to be created and in what order, provisions everything in GCP, then hands off to Chef to configure the software. Everything we do manually today gets encoded into the infrastructure definition. Tom’s OS configuration knowledge goes into Chef recipes. Jake’s Oracle setup expertise goes into database configuration files. My domain setup procedures become Chef cookbooks.”

“Wait,” Jake said. “You keep mentioning Chef. Why Chef specifically? I’ve heard of Puppet, Ansible, all these configuration management tools. What makes Chef the right choice?”

“Good question,” Maya said. “Chef has a few things going for it for our use case. It’s mature and battle-tested; it’s been around since 2009. It has strong enterprise support. The Ruby-based DSL is actually pretty readable once you get past the initial learning curve. And critically, it has good patterns for managing the kind of complex, stateful configuration that PeopleSoft environments need.”

“Plus,” Sarah interjected, “Chef has this concept of cookbooks and recipes that maps really well to how we think about PeopleSoft configuration. You have a cookbook for Oracle setup, a cookbook for PeopleTools installation, a cookbook for domain configuration. Each cookbook contains recipes for specific tasks. It’s very modular.”

“Isn’t the learning curve steep?” Priya asked.

“All of these tools have a learning curve,” Maya acknowledged. “But Chef’s actually not bad. The DSL reads almost like plain English; you’re declaring resources and their desired state. ‘This file should exist with these contents and these permissions.’ ‘This service should be running.’ ‘This package should be installed.’ It’s declarative, like Terraform, which means you describe what you want, not how to get there.”

Tom was taking notes. “So Terraform provisions the infrastructure, including the VMs, the database, and the network. And Chef configures the software on that infrastructure?”

“Exactly,” Maya said. “They’re complementary tools. Terraform is great at infrastructure provisioning, but not great at managing complex application configuration. Chef is great at configuration management, but it is not designed for infrastructure provisioning. Together, they cover the full stack.”

“How do they work together?” Marcus asked. “Like, mechanically?”

“Terraform provisions a VM and can run Chef automatically as part of the provisioning process,” Maya explained. “So Terraform creates your application server VM, and as part of the creation process, it installs the Chef client and runs the appropriate cookbooks. By the time Terraform finishes, you have a fully configured application server ready to join the domain.”

Jake was nodding. “Okay, I’m starting to see how this fits together. But here’s my concern: I know how to configure an Oracle database. I know every parameter, every tablespace setting, every tuning option. How do I translate that knowledge into Chef recipes?”

“That’s actually the beauty of it,” Maya said. “You don’t have to learn Chef deeply to contribute your Oracle knowledge. Sarah’s going to become our Chef expert, and she’ll learn the syntax and the patterns. Your job is to tell her what a properly configured PeopleSoft database looks like. She will need to know things like what parameters need to be set, which tablespaces need to exist, and which users need to be created with what privileges. She translates your expertise into Chef recipes. You review them to make sure they’re doing the right thing.”

“So I don’t have to become a Chef programmer?” Jake sounded relieved.

“You should learn enough to read and understand Chef recipes,” Maya said. “But you don’t need to be an expert. We’re playing to everyone’s strengths. Jake knows Oracle. Tom knows application server configuration. Priya knows the PeopleSoft domain setup. Sarah knows coding patterns and modern tooling. We combine that knowledge.”

“What about testing?” Lisa asked. “With my manual builds, I can see each step happening. How do I test infrastructure that builds automatically?”

“That’s one of the biggest advantages of IaC,” Maya said. “We build automated validation into the process. After Terraform provisions the database, we run tests—can we connect? Is the tablespace configuration correct? Are the backup jobs scheduled? After Chef configures an application server, we test—did the PeopleTools installation complete? Is the domain configured correctly? Are the processes running?”

“And if something fails?” Tom asked.

“Then the build fails, and we know exactly where it failed and why,” Maya said. “No more ‘I think it’s configured correctly.’ We have automated validation that proves it’s configured correctly. And because everything’s in code, we can test changes before we apply them to production. Want to change an Oracle parameter? Change it in the code, apply it to dev, and run your validation tests. If it works, promote the same code change to QA, then to prod. The code that builds dev is the same code that builds prod, just with different size parameters.”

“That’s environmental parity,” Sarah said. “It’s a big deal. Right now, our dev environment is kind of like prod, but not exactly. Different Oracle patches, slightly different configurations, different disk layouts. So sometimes things work in dev and break in prod. With IaC, dev and prod are identical except for scale. Same configurations, same versions, same everything. That massively reduces ‘works on my machine’ problems.”

Tom was quiet for a moment. “Okay. I’m starting to see the value. But I need you to be honest with me about something, Maya. How hard is this going to be to learn? Because I’m looking at two weeks to learn Terraform and Chef well enough to build production-grade infrastructure, and that seems… ambitious.”

Maya sat down next to him. “It’s going to be hard,” she said honestly. “The first few days, you’re going to feel lost. Terraform has its own language—HCL—and its own way of thinking about infrastructure. Chef has Ruby DSL and its own concepts. You’re going to write code that doesn’t work. You’re going to get error messages you don’t understand. You’re going to want to just write a bash script because it’s faster and you know how.”

“That’s not a great sales pitch,” Tom said.

“But here’s the thing,” Maya continued. “You’re not learning to become a Terraform expert or a Chef expert. You’re learning enough to encode your infrastructure knowledge in a maintainable way. By the end of Week 2, you won’t be an expert. But you’ll be able to read infrastructure code and understand what it’s doing. By the end of Week 3, you’ll be able to write basic modules. That’s sufficient. Expertise comes with time.”

“And we’re all learning together,” Priya added. “I don’t know this stuff either. None of us does except Sarah. So when you get stuck, you’re not the only one struggling.”

Jake raised his hand. “One more conceptual question before we dive in. Why are we doing this specifically on GCP? Why not AWS or Azure?”

“Honestly? Partly because I have more experience with GCP,” Maya admitted. “But also, GCP has really strong Oracle support now with the new Oracle Exadata at GCP offering. This provides Oracle databases with the ability to do automated backups, patching, and high availability, which is already built in. That’s huge for us. AWS has Oracle, too, and Azure has managed Oracle, so we’re not locked in. But for learning, we needed to pick one and go deep.”

“Here’s the thing though,” Sarah said. “Once we have IaC working on GCP, porting it to AWS or Azure isn’t that hard. The concepts translate. Terraform supports all the major cloud providers. Chef works the same everywhere. So we’re learning patterns that are portable.”

“The specific cloud provider matters less than you think,” Maya said. “What matters is the operational model—infrastructure as code, version-controlled configurations, automated validation, repeatable builds. That model works on any cloud. We’re just using GCP as the learning platform.”

Marcus leaned forward. “So what’s the actual plan? How are we spending the next two weeks?”

Maya pulled up the schedule she’d built. “Today and tomorrow: intensive training. We’re all going through the HashiCorp Terraform tutorials and the Chef learning resources. Not trying to become experts—just getting familiar with the concepts and syntax. Wednesday through Friday this week: hands-on experimentation. Everyone picks one piece—Jake, you’re exploring Terraform’s database provisioning. Tom, you’re looking at compute resources. Marcus, you’re diving into networking. Priya, you’re prototyping Chef cookbooks for PeopleSoft configuration.”

“What about Week 3?” Lisa asked.

“Week 3 is building for real,” Maya said. “Monday through Thursday, we’re writing the actual infrastructure code for our dev environment. Each person owns their module. We do code reviews—yes, we’re reviewing infrastructure code just as we do application code. Friday, we do the demo. We run the infrastructure build from scratch in front of each other and prove it works.”

“And if it doesn’t work?” Tom asked.

“Then we debug and fix it,” Maya said simply. “But I don’t think it will work, I know it will. Because we’re going to test as we build. Every module gets validated independently before we integrate it.”

She stood up and walked to the whiteboard. “Here’s what success looks like at the end of Week 3: We can provision a complete PeopleSoft environment from code in under two hours. We have version-controlled infrastructure that anyone on the team can deploy. We have automated validation that proves the environment is configured correctly. And we have evidence—real, demonstrable evidence—that we’re operating at a higher level than we were three weeks ago.”

“That’s a lot for two weeks,” Tom said.

“It is,” Maya agreed. “But look at what we did in Week 1. Sarah and Priya automated patch downloads. Jake validated our DR process. Marcus designed our logging strategy. Tom documented 847 lines of configuration. You all did hard things last week. This week is just a different kind of hard.”

“What if we fail?” Jake asked quietly.

“Then we learn why we failed and adjust,” Maya said. “But here’s what I know about this team: you’re all capable of way more than you think you are. Three weeks ago, how many of you would have said you could write a Python script to automate patch downloads?”

Sarah raised her hand. No one else did.

“And now Priya’s comfortable enough with Python to pair with Sarah on that script,” Maya said. “That’s growth. That’s what these twelve weeks are about—discovering that you can learn things you thought were beyond you.”

She grabbed the marker. “Okay. Let’s talk about what each person is focusing on. Jake, you’re building the database module for Terraform and the Oracle configuration cookbook for Chef. Your expertise is Oracle, and now you’re encoding that expertise in infrastructure code.”

Jake nodded slowly. “I can do that. Tell Terraform what database we need, tell Chef how to configure it.”

“Exactly. Tom, you’re on the compute module and the application tier Chef cookbooks. Everything you documented last week about how app servers should be configured—that becomes Chef recipes.”

“So I’m writing down what I normally do manually, just in Chef’s language instead of a runbook,” Tom said.

“Right. Marcus, you’re handling networking, including the VPCs, subnets, firewall rules, and load balancers. All the network configuration that’s currently scattered across different systems and tickets? That all becomes Terraform code.”

“And Priya,” Maya continued, “you’re the Chef expert for PeopleSoft-specific configuration. Domain setup, process scheduler configuration, and web server setup. You know PeopleSoft configuration better than anyone. Now you’re teaching Chef how to do it.”

“What about me?” Lisa asked.

“You’re QA and validation,” Maya said. “As each module gets built, you’re testing it. You’re writing automated tests to verify that the infrastructure is configured correctly. And you’re documenting the gotchas. We need documentation about what broke, how we fixed it, and what we learned.”

“Sarah, you’re our technical lead on this,” Maya said. “You’re learning Terraform and Chef at an expert level, and you’re helping everyone else. You’re also setting up the Git repository structure, the code review process, and the CI/CD pipeline for testing infrastructure code.”

“Wait, we’re doing code reviews on infrastructure?” Tom sounded surprised.

“Absolutely,” Maya said. “Infrastructure is code now. We review code. Jake proposes a change to the database module? It goes through a pull request. I review it, or Sarah reviews it, or you review it. We ask questions: ‘Why this parameter?’ ‘What happens if this fails?’ ‘Is this tested?’ Same discipline we’d use for application code.”

“That’s… actually going to catch mistakes,” Tom admitted. “How many times have I made a manual configuration change without a second set of eyes on it?”

“Exactly,” Maya said. “Code review isn’t about distrust. It’s about quality and knowledge sharing. When Jake submits a database module change, I learn about Oracle configuration by reviewing his code. When Tom submits an app tier change, Jake learns about application server setup. We all get smarter.”

She capped the marker. “Questions before we dive into training?”

“Yeah,” Jake said. “What happens when we hit Week 4 and we’re supposed to be building CI/CD pipelines, but we’re still struggling with IaC?”

“Then we adjust,” Maya said honestly. “The twelve-week timeline is aggressive. We’re going to hit roadblocks. But we can’t let perfect be the enemy of good. If at the end of Week 3 we can build an environment in four hours instead of two, that’s still a massive win. If our Chef cookbooks don’t cover every edge case, but they cover 80% of the configuration, that’s progress.”

“We’re not trying to be perfect,” Sarah said. “We’re trying to be better. And we’re trying to prove to Harrison that modernizing PeopleSoft is possible and valuable.”

“Exactly,” Maya said. “The goal isn’t perfection. The goal is demonstrable improvement plus a pathway to keep improving. If we can show Harrison that we’ve cut environment provisioning from 18 days to 4 hours, reduced configuration errors, and eliminated tribal knowledge dependencies, we’ve made the case.”

Tom stood up. “Alright. I’m in. But I reserve the right to complain when my Terraform code doesn’t compile or whatever the right term is.”

“Complaining is encouraged,” Maya said. “Giving up is not. Everyone clear on the plan?”

Nods around the room.

“Good. Training resources are linked in Slack. Sarah’s got office hours 2-4 PM daily if you get stuck. And remember—we’re all learning together. I’ll be going through the same Terraform tutorials you are. There are no stupid questions.”

As the team dispersed to start their training, Jake lingered behind.

“Maya,” he said quietly. “I need you to know something. I’m scared.”

Maya turned. “Scared of what?”

“That I can’t do this,” Jake said. “I’ve been an Oracle DBA for twenty-six years. I know Oracle inside and out. I know every parameter, every wait event, and every performance tuning trick. But Terraform? Chef? Infrastructure as code? I feel like I’m starting over. And I’m not twenty-five anymore. What if I can’t keep up?”

Maya sat down next to him. “Jake, do you remember Week 1? Your disaster recovery test?”

“Yeah.”

“You found three errors in backup scripts that had been running for seven years. Errors no one else would have caught because they don’t understand Oracle the way you do. That expertise doesn’t disappear just because you’re learning new tools.”

“But—”

“Infrastructure as code doesn’t replace your Oracle knowledge,” Maya continued. “It amplifies it. Right now, your expertise lives in your head and in scripts only you understand. After Week 3, your expertise will be codified, version-controlled, and teachable. You’re not starting over. You’re multiplying your impact.”

“What if I slow everyone down?”

“Then we slow down,” Maya said simply. “But I don’t think you will. You know what I think? I think you’re going to struggle for a few days, get frustrated, maybe write some Terraform code that doesn’t work. But then something’s going to click. And by Week 3, you’re going to be teaching the rest of us the right way to architect database infrastructure in code. Because you understand Oracle databases at a level none of us do.”

Jake was quiet for a moment. “You really believe that?”

“I know it,” Maya said. “I wouldn’t have put you on the database module if I didn’t think you could do it. You’re not just learning Terraform, Jake. You’re becoming the person who can bridge traditional Oracle DBA expertise with modern cloud operations. That’s a rare and valuable skill. In five years, every company will want DBAs who can do both. You’re going to be ahead of the curve.”

“Okay,” Jake said, standing up. “I’m going to go start this training. But I’m going to complain a lot.”

“That’s the spirit,” Maya said.

After Jake left, Maya sat alone in the conference room, looking at her twelve-week timeline on the whiteboard. Week 1: Assessment—complete, with green checkmarks next to each deliverable. Week 2-3: Infrastructure as Code—in progress.

Her phone buzzed. An email from Robert Harrison: “Heard you’re moving the team to new tools. Make sure this doesn’t disrupt production operations. Can’t afford incidents during the transformation.”

Maya typed back: “Understood. All IaC development is happening in isolated dev environments. Production untouched until Week 8+ and fully tested.”

She didn’t mention that “not disrupting production” would be the hardest part. They still had to maintain current operations while learning an entirely new operational model. It was like rebuilding an airplane mid-flight.

But that’s what the next ten weeks were going to be: running production on the old model while building the new model in parallel, then executing a clean cutover when the new model was proven.

No pressure.

Maya opened her laptop and navigated to the HashiCorp learning portal. If she was going to ask her team to learn this, she needed to be able to help them when they got stuck.

Two weeks. By the end of Week 3, they’d have an infrastructure that used to take eighteen days, now provisioned in hours.

And her team would have learned that they were capable of more than they thought.

One Terraform module at a time.