IaC Explorer

The IaC Explorer in Firefly is a feature that allows you to dive deep into your Infrastructure-as-Code stacks (especially Terraform state files) and understand their composition. It provides a structured view of your IaC content, helping you navigate through Terraform stacks, modules, and resources in a visual way. This is extremely useful for platform engineers and DevOps practitioners to analyze how infrastructure is defined in code and to identify any issues or improvements.

Navigating IaC Stacks

When you open the IaC Explorer page, you'll see a list of your integrated IaC stacks (for example, each Terraform .tfstate file that Firefly has ingested from your environment). Each stack represents a deployed infrastructure state. By selecting a stack, the Explorer will display its contents in an organized manner. Typically, the view will show the root module of the Terraform stack and any child modules that are being used.

Expand Modules: In the Explorer interface, you can expand the hierarchy. For instance, the root of the stack might have several module calls (Terraform modules invoked by your configuration). You can click the "+" or expansion arrow next to a module call to drill down. This will show you the resources and sub-modules inside that module. The Explorer essentially lets you traverse the module tree of your Terraform configuration. If you are not using modules in a particular stack, then expanding the root will simply list all resources defined in that root module.

Resource Details: As you navigate, each resource within a module can be inspected. The Explorer might display each resource's name, type, and properties. For example, you might see a resource aws_instance.my_vm along with key attributes. This context helps you understand how a specific resource is defined in code without manually reading the raw .tfstate or Terraform code. You can quickly pinpoint where a resource lives in the module structure.

This navigation is especially helpful if you have large Terraform states with multiple modules. Rather than combing through JSON state files or code repositories, the IaC Explorer gives you a bird's-eye view of the stack's structure and lets you zero in on components of interest.

Modules and Providers Overview

One of the key benefits of the IaC Explorer is identifying which Terraform modules and providers are used in each stack. At a glance, Firefly will show you all module calls within the stack (with their names as defined in Terraform) and the source/version of each module. For example, if your Terraform stack uses the official AWS VPC module, the Explorer will list something like module.vpc (source = terraform-aws-modules/vpc/aws, version = 3.5.0).

In addition, the Explorer indicates which providers are in use. Providers are the plugins (like AWS, Azure, Google, etc.) that Terraform uses to manage resources. Within the Explorer, you might see a summary of providers for the stack (e.g., "Providers: AWS 4.50.0, Null 3.1.0" etc., depending on what the state contains). For each resource, it may also show the provider it's associated with (for instance, an AWS resource uses the AWS provider). This makes it easy to verify that the correct provider versions are being used, and to spot if multiple cloud providers are referenced in a single stack.

By examining module usage, you can identify outdated modules or providers quickly. The Explorer highlights the module names and their versions as they exist in your IaC. If a module is a custom in-house module, you'll see its path; if it's from the Terraform Registry or open source, you'll see that source reference. This context is valuable for governance – you can ensure that teams are using approved module versions and the right provider versions across all stacks.

Blast Radius Indicators (Outdated Modules)

Firefly's IaC Explorer includes a Blast Radius feature that flags Terraform stacks using older or potentially problematic module versions. The "blast radius" refers to how far-reaching a change might be (Terraform Module Blast Radius: Methods for Resilient IaC in Platform Engineering). If Firefly detects that a stack is using a module version that is significantly behind the latest (or has known major changes), it may flag this in the UI. For example, an indicator or warning icon might appear next to a module that's outdated. When you see a flagged module, it suggests that updating that module could have a large impact (a large blast radius) on your infrastructure – meaning you should approach updates carefully.

The Blast Radius feature helps you quickly answer questions like: "Are any of my Terraform modules dangerously out-of-date?" or "Which stacks might experience widespread changes if I update a module version?". Firefly might color-code these statuses or provide a tooltip explaining the finding (e.g., "Module X is 2 major versions behind – updating it might introduce many changes."). This allows you to prioritize module upgrades and assess risk. It's essentially Firefly's way of doing a module version drift check: if version drift is detected (a kind of drift within IaC code itself), you get alerted.

To use this, navigate through your modules in the Explorer and look for any "outdated" or "at-risk" labels. You can then plan to refactor or update those modules. In practice, you might decide to test those module updates in a sandbox, given the blast radius Firefly identified. This feature turns what could be a surprise (lots of changes from a module update) into a known quantity that you can manage proactively.

Troubleshooting with the IaC Explorer

The IaC Explorer is also a handy tool for troubleshooting IaC issues and drift. Here are some common scenarios and how to leverage the Explorer:

Identifying Drift or Inconsistencies: If Firefly has flagged a drift in your environment (meaning the live infrastructure doesn't match the IaC), you can use the Explorer to inspect the IaC stack. For instance, if a resource is drifted, you might notice that its configuration in the state doesn't match what's actually running. By viewing the resource in the Explorer, you can confirm what the IaC thinks the settings are. From there, you may decide to update the code (pull the actual settings into code via Firefly's codification) or apply the code to overwrite the manual change.

Module Errors or Misconfigurations: If Terraform is throwing errors about module dependencies or you suspect a module wasn't used correctly, the Explorer shows how modules are wired. You can ensure that nested modules appear where expected. If something is missing, it might mean the module call wasn't properly included in the Terraform configuration. The visual breakdown can reveal, for example, that a resource is showing up under the root module when you expected it to be under a child module – indicating a possible configuration mistake in your .tf files.

Dependency Issues: The Explorer isn't a real-time Terraform planner, but seeing resources under their modules can hint at dependency relationships. If a certain resource is not present, perhaps it never got created due to dependency issues. Using the Explorer in conjunction with Terraform's plan/apply outputs helps pinpoint where in the IaC structure a failure might be occurring.

Understanding Legacy Configurations: For older stacks (maybe created by someone who left the team), the IaC Explorer gives you a quick understanding of what's inside without reading every line of code. This is useful for knowledge transfer and auditing. You can document how an outdated stack is structured, then plan how to break it into smaller modules or update it. For example, you might realize a huge stack has many components that could be refactored; the Explorer essentially provides an inventory of the stack's contents (resources and modules).

Cross-Team Visibility: Sometimes different teams manage different parts of the infrastructure code. The IaC Explorer lets one team see what another team's Terraform stack contains (given appropriate permissions). This can prevent duplicate work or conflicting changes. For example, before provisioning a new resource, you could check in Firefly if perhaps that resource (or something similar) is already managed in an existing stack/module.

In summary, the IaC Explorer page is your go-to interface for inspecting and understanding your Infrastructure-as-Code at a glance. It brings transparency to complex Terraform states, helps flag potential problem areas (like large blast radius updates), and serves as a troubleshooting aid when real infrastructure diverges from code. By regularly using the Explorer, you can maintain cleaner, more manageable IaC configurations and catch issues early.