Service Catalog (Internal Developer Portal)

The Service Catalog is a core component of the IaCConsole Internal Developer Portal (IDP). It provides a developer-friendly abstraction over the raw CMDB Inventory, enabling teams to self-serve and manage microservice configurations across multiple environments.

Overview

While the Inventory page displays raw CMDB Dimensions (VPCs, subnets, API keys, etc.), the Service Catalog specifically focuses on service dimensions. These dimensions represent logical applications that can consist of multiple “Deployment Kinds” sharing the same codebase but executing with different profiles.

Deployment Kinds

IaCConsole enforces a strict schema for service definitions to ensure compatibility with VirtualGitOps and automated Helm/Terraform templating. The following deployment kinds are currently supported:

• services: For HTTP-facing components (e.g., API servers, Web frontends). These typically result in a Kubernetes Deployment, Service, and Ingress.
• sqs-consumers: For background workers that process messages from a queue. These result in background Deployments without external HTTP exposure.
• db-migration: For one-time or lifecycle-linked database migration jobs.

Service Definition Schema

A service dimension must follow this strict JSON structure in its dimData:

{
  "services": {
    "api-server": {
      "cmd": "node dist/index.js",
      "workDir": "app"
    }
  },
  "sqs-consumers": {
    "email-worker": {
      "cmd": "node dist/worker.js",
      "workDir": "app"
    }
  },
  "db-migration": {
    "schema-update": {
      "cmd": "npm run migrate",
      "workDir": "app"
    }
  }
}

Schema Requirements:

• Each deployment kind is an object.
• Each sub-app within a kind must have a cmd (the execution command) and a workDir (the working directory within the container).

How it Works (VirtualGitOps)

1. Definition: When you define a service in the UI, IaCConsole saves it as a dimension with dimKey: "service".
2. Synthesis: The API synthesizes these definitions into a VirtualGitOps commit.
3. Deployment: Tools like ArgoCD or Flux detect the change and feed the JSON data into a unified Helm chart or Terraform module.
4. Templating: The templating engine iterates over the defined kinds to generate the necessary Kubernetes manifests (Deployments, HPA, Ingress, etc.) automatically.

Benefits

• Consistency: All microservices follow a unified deployment pattern without manual Helm chart management per app.
• Self-Service: Developers can manage their own application topology (adding workers or migration jobs) via simple configuration changes.
• Visibility: Clear visibility into what components make up a service and how they are executed across different environments.