Reva Hristo Wiki Fonseca

Challenge

Enterprise IT operations rarely fail from a single cause. They're stretched across multiple concurrent workloads, run by teams with limited headcount, and pushed to process a high volume of daily change requests, all while gaps in observability oversight make problems harder to catch early. Together, these pressures compound manual triage fatigue, and in the long run, this risks business continuity if a critical incident slips through unnoticed.

Action

To tackle these challenges, we built a centralized AIOps engine that brings IT infrastructure monitoring, ITSM/CMDB, internal documentation, and communication channels together into a single correlation layer, instead of leaving them as disconnected tools each engineer has to check separately. This consolidation matters because it lets telemetry and tickets feed one AI model that cross-references a knowledge base and memory store for context, then executes through an MCP-connected automation layer. Every action it proposes is still routed through a human approve/reject step before reaching production, so the system closes blind spots in observability without giving up institutional control over what actually runs.

Result

Challenge

Global compliance mandated provisioning through Terraform Enterprise's GitOps flow: a single repository with three branches for dev, staging, and production. Migrating the signature B2B workload, the company's main revenue application, meant inheriting years of unstandardized resources from earlier, less mature provisioning practices: inconsistent naming conventions and stateful or hard-to-replace resources such as IAM roles and policies, KMS encryption keys, and production databases, where an unintended destroy-and-recreate cycle risked data loss or downtime. Terraform's default behavior treats configuration drift as a trigger to replace a resource, which directly conflicted with a zero-downtime requirement from the business. Compounding this, resource existence itself was inconsistent across environments: some resources existed in dev and staging but not production, others only in one environment, a byproduct of ad hoc provisioning from before the migration began.

Action

Rather than hand-writing Terraform per environment, which would have meant three times the code and three times the drift risk, we built a config-based approach: a single Terraform codebase driven by per-environment YAML configuration, with each resource looped over via `for_each` and filtered by a dedicated environment flag. Terraform Enterprise injects the active workspace's environment as a `TF_VAR_env` variable per its standard variable convention, which the codebase reads as `var.env` to filter which resources apply. A dev-only resource is simply skipped once code promotes to staging, no code change required. The Terraform code itself only had to be written once, and a routine change never touches a `.tf` file, only the YAML configuration, cutting the chance of accidental breakage.

buckets:
  app-logs:
    envs: ["dev", "staging", "prod"]
    versioning: true
  legacy-cache:
    envs: ["staging", "prod"]
    versioning: false
  scratch-dev-only:
    envs: ["dev"]
    force_destroy: true

variable "env" {
  type        = string
  description = "Target environment, injected by Terraform Enterprise as TF_VAR_env per workspace"
}

locals {
  config = yamldecode(file("${path.module}/config.yaml"))

  buckets = {
    for name, cfg in local.config.buckets :
    name => cfg if contains(cfg.envs, var.env)
  }
}

resource "aws_s3_bucket" "this" {
  for_each = local.buckets

  bucket        = "${each.key}-${var.env}"
  force_destroy = try(each.value.force_destroy, false)

  tags = {
    Environment = var.env
  }
}

Result

With this approach, compliance is met without blocking the business: standardization concerns, like enforcing consistent bucket settings everywhere, can be tackled as a separate initiative instead of bundling every fix into the migration itself.

Benefits of this approach:

• Standardizes infrastructure provisioning across all three environments
• Brings every resource into Terraform Enterprise GitOps compliance
• Removes the need for environment-specific Terraform code
• Avoids dependency on HCL syntax for routine changes, so even an engineer who isn't a Terraform expert can safely make edits through YAML

Challenge

The product started as an on-premises, docker-based installation deployed per client. As the customer base grew, it moved to AWS Singapore, the closest region available at the time since AWS Jakarta had only just been introduced, but kept the same one-to-one model: every new client meant provisioning a dedicated EC2 instance. By the time this initiative began, that approach had grown past 100 EC2 deployments. The problem wasn't only cost: every new instance added operational overhead too, another server to patch, monitor, and maintain individually, none of it shared across clients.

Action

For a quick win, we redesigned the platform around a cloud-native, ECS-based container orchestration model rather than Kubernetes, since the team didn't yet have deep Kubernetes expertise at the time and ECS offered a faster path to multi-tenancy without that learning curve. Each client's workload was decoupled from its own dedicated EC2 instance into a shared, multi-tenant container platform, and the underlying infrastructure was migrated from AWS Singapore to the newly available AWS Jakarta region in the same initiative. Deployment was automated through a Bitbucket CI/CD pipeline that also introduced a DevSecOps stage, baking security scanning into the release process itself rather than treating it as a separate, after-the-fact step.

Result