Design-First or Infrastructure-as-Code? Choosing the Source of Truth for your Solace Broker

In a modern Event-Driven Architecture (EDA), the broker is no longer just "infrastructure". It is the heartbeat of the business. As enterprises scale their event meshes, the question isn't if they should automate, but where the "Source of Truth" should live.

In the Solace ecosystem, you have two powerful paths: Terraform (Infrastructure-as-Code) or Event Portal (Design-First). Both are excellent, but they represent fundamentally different philosophies. To avoid configuration drift and operational chaos, you must choose your "North Star."

The IaC Path: Terraform & Engineering Excellence

This approach treats your Solace broker like any other cloud resource, such as an S3 bucket or an EC2 instance. You define your queues, RDPs, and ACLs as code.

resource "solacebroker_msg_vpn_queue" "this" {
  msg_vpn_name        = "default"
  queue_name          = "acme-queue"
  max_msg_spool_usage = 70000
  ingress_enabled     = true
  egress_enabled      = true
}

Key Benefits:

• Unified Pipeline: Seamless integration into existing CI/CD and GitOps workflows.
• Version Control: Every change is documented in Git, requiring Pull Requests and Peer Reviews.
• Scale: Manage hundreds of Message VPNs across different regions with a single command.

Ideal for: Organizations that require strong cross-team alignment on data contracts and architectural visibility.

The Design-First Path: Solace Event Portal

The Design-First approach focuses on modeling your "Event API" before a single line of infrastructure is provisioned. It’s about the "What" and "Why" rather than just the "How".

Key Benefits:

• Visual Governance: Stakeholders and architects see the flow of data through visual graphs, not just lines of code.
• Schema Registry: Native management of payloads (Avro, JSON, etc.) and versioning of events.
• Discovery: Developers can easily find existing events to subscribe to, preventing the creation of redundant "event silos."

Ideal for: Organizations that require strong cross-team alignment on data contracts and focused on data contracts and architectural visibility.

You Can’t Have Two Masters

Without a clear boundary, organizations may face Configuration Overlap. If both Terraform and the Event Portal attempt to manage the same broker objects without a hierarchy, the system state can become inconsistent.

The Solution: Establish a clear hierarchy. For example, use the Event Portal for high-level design and contract definition, while designating Terraform as the final authority for deploying those resources to the broker.

Decision Matrix: Which one is for you?

Feature	Terraform (IaC)	Event Portal (Design-First)
Primary User	DevOps / Platform Engineer	Architect / Application Developer
Visibility	Low (Code-centric)	High (Visual/Graph-centric)
Schema Management	Manual / External	Native / Integrated
Best For	Infrastructure Automation	Event Governance & Discovery

Conclusion: Picking Your North Star

Choosing between Terraform and Event Portal isn't about which tool is "better". It's about who owns the Source of Truth.

• If your team lives in the terminal and manages 50+ production brokers with a focus on uptime and reliability, Terraform is your best friend.
• If your team is building a complex ecosystem of microservices and needs to govern data contracts and event discovery, Event Portal is your home.

The "Hybrid" Bridge: Keep in mind that Solace Event Portal and Terraform can co-exist. You can, for example, deploy your entire infrastructure with Terraform and use the Discovery functionality in Event Portal to scan, load, and visualize your runtime environment. This gives you the best of both worlds: automated, code-based deployments and a clear, graphical map of your ecosystem. However, even in this setup, the hierarchy must be clear: One tool configures, the other visualizes. One tool configures, the other visualizes.