An estate built by clicking through a console is one no one can reliably reproduce. Infrastructure as code makes the configuration a set of reviewed files, and on OCI that means Terraform with Resource Manager.
An estate built by clicking through a console is an estate no one can reliably reproduce. It works, until someone needs to build the same thing in another region, or recover from a mistake, or simply understand how the current configuration came to be, and then the absence of any record of how it was built becomes a serious problem. Infrastructure as code solves this by making the estate's configuration a set of files that define what should exist, and on OCI that means Terraform, with Resource Manager as the managed service that runs it. This article explains how the two fit together and how to use them well.
Terraform is the language and tool for describing infrastructure as code, and Resource Manager is OCI's managed service for running Terraform without you having to operate the tooling and state yourself. Together they let you define the estate in files that are reviewed, versioned and applied consistently, which transforms infrastructure from something built by hand into something engineered like software. The sections below explain the relationship and the practices that make it work, building on the foundations in OCI Landing Zone and Architecture: A Complete Guide and supporting the consistency that Security by Design on OCI depends on.
Terraform lets you describe the infrastructure you want as code, declaring the networks, compartments, instances and policies that should exist, and then makes reality match that description. The power of this is not only automation but the fact that the code becomes the source of truth, a reviewable, versioned record of exactly how the estate is configured, that can be changed deliberately through a process rather than tweaked invisibly in a console. When the code is the truth, the estate becomes reproducible, auditable and far less prone to the silent drift that manual configuration always suffers from.
| Approach | Reproducible | Reviewable | Drifts over time |
|---|---|---|---|
| Console clicking | No | No | Heavily |
| Scripts | Partly | Partly | Somewhat |
| Terraform as code | Yes | Yes | Detectable and correctable |
Running Terraform yourself means operating the tooling and, critically, managing the state file that Terraform uses to track what it has built, which is sensitive and needs to be stored and locked carefully. Resource Manager is OCI's managed service that handles this for you, running Terraform within OCI, managing the state securely, and integrating with the identity and access controls of the tenancy. Using Resource Manager means you get the benefits of infrastructure as code without taking on the operational burden of running the Terraform machinery yourself, which lowers the barrier to adopting the practice, particularly for teams new to it.
The single most important operational concept in Terraform is state, the record of what Terraform believes it has built, which it compares against your code to decide what to change. State that is lost, corrupted or accessed by two processes at once causes serious problems, which is why how state is stored and locked matters so much, and why Resource Manager's handling of it is one of its main attractions. Teams that run Terraform themselves must take state management seriously, storing it remotely, locking it during operations and protecting it, because mistakes here are among the most painful in the whole practice.
The way infrastructure as code compounds in value is through modules, reusable units of configuration that capture a pattern once and let it be used many times. A module that defines a standard network, a standard compartment structure or a complete reference architecture, as discussed in OCI Reference Architectures Walkthrough, turns a proven design into something any team can deploy consistently, and improving the module improves every deployment that uses it. Building a library of well designed modules is how an organisation turns infrastructure as code from a project by project tool into a shared asset that makes every new deployment faster and more consistent than the last.
One of the most valuable practices Terraform enables is reviewing changes before they are applied, because Terraform can show you exactly what it intends to change before it changes anything. This plan and review step is where mistakes are caught, where a change that would unexpectedly destroy something is spotted before it does, and where the team builds confidence that a change does what it claims. Treating the review of the planned change as seriously as reviewing application code is what separates infrastructure as code that genuinely reduces risk from infrastructure as code that simply automates mistakes at speed.
Even in an estate managed as code, someone will eventually make a change directly in the console, and the result is drift, a divergence between what the code says and what actually exists. Terraform can detect this by comparing the real estate against the code, which surfaces the unauthorised or forgotten changes that would otherwise accumulate silently. Building regular drift detection into the operating rhythm, and correcting drift by bringing reality back in line with the code rather than updating the code to match the drift, is what keeps the code genuinely authoritative rather than gradually becoming fiction.
It can be tempting to treat infrastructure as code as an advanced practice to adopt later, once the estate is established, but this gets the sequencing backwards, because the estate built by hand is exactly the one that is hardest to bring under code later. Adopting infrastructure as code from the start means the estate is reproducible, auditable and consistent from day one, and it is the mechanism by which the security posture in Security by Design on OCI and the patterns in the reference architectures stay applied rather than eroding. Infrastructure as code is not a nice to have layered on a mature estate, it is the discipline that makes an estate mature in the first place.
Building estates as code with Terraform and Resource Manager is the heart of our DevOps and IaC practice, and we apply it from the first day of an OCI Implementation and Migration engagement. The aim is an estate that is defined in reviewed, versioned code, reproducible across regions, free of silent drift, and able to carry its designed in security and architecture forward as it grows rather than losing them to manual change.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.