Construcción de una Internal Developer Platform en Kubernetes: PaaS para equipos DevOps

Introducción: qué es una Internal Developer Platform y por qué es necesaria en 2026

En 2026, la brecha entre la velocidad del negocio y la velocidad de entrega de código se ha convertido en un factor competitivo crítico. Los equipos que despliegan decenas de veces al día superan a los que esperan semanas para lanzar una release. Aquí es donde entra en juego la Internal Developer Platform (IDP) — un PaaS interno que abstrae al desarrollador de Kubernetes, la infraestructura cloud y las operaciones rutinarias.

Una IDP no es una única herramienta. Es un conjunto de herramientas estandarizadas, procesos e interfaces de autoservicio que permiten al desarrollador desplegar un nuevo microservicio, obtener un entorno de pruebas y gestionar secretos — sin necesidad de contactar al equipo de DevOps. Según el DORA Report 2024, las organizaciones con ingeniería de plataformas madura entregan cambios 2,5 veces más rápido y experimentan rollbacks 4 veces menos frecuentemente.

«La plataforma es un producto. Los desarrolladores son sus usuarios. Una mala DX destruye la velocidad igual que la deuda técnica.»

En este artículo veremos cómo construir un PaaS interno completo sobre Kubernetes, qué herramientas utilizar, cómo estandarizar CI/CD para servicios en Go y PHP, y cuál es el plan paso a paso más adecuado para equipos de entre 10 y 50 personas.

Componentes clave de una Internal Developer Platform

Una IDP completa se compone de varias capas, cada una de las cuales resuelve un problema concreto de los desarrolladores:

Despliegue de autoservicio — el desarrollador pulsa un botón o hace un git push, y la plataforma crea automáticamente el namespace, despliega el servicio y configura el ingress.
Plantillas de servicio (Service Templates) — golden path para un nuevo microservicio en Go, PHP o Node.js: repositorio, CI/CD, Dockerfile, Helm chart — todo creado a partir de una plantilla.
Gestión de entornos — dev, staging, producción y preview environments individuales para cada PR.
Gestión de secretos — integración con Vault o Kubernetes Secrets mediante External Secrets Operator.
Observabilidad out-of-the-box — logs, métricas y trazas se conectan automáticamente al desplegar un nuevo servicio.

Herramientas: Backstage como portal del desarrollador, Crossplane para infraestructura

Backstage — centro de control de la plataforma

Backstage de Spotify es un developer portal open-source que se ha convertido en el estándar de facto para las IDP. Resuelve preguntas como «¿dónde está la documentación?», «¿qué servicios tenemos?» o «¿quién es el responsable de este repositorio?».

En el contexto de una plataforma Kubernetes, Backstage cumple las siguientes funciones:

Software Catalog — catálogo de todos los microservicios, sus dependencias, propietarios y estado de despliegue.
Software Templates — formularios interactivos para crear un nuevo servicio siguiendo el golden path: el desarrollador introduce el nombre del servicio, elige el lenguaje (Go/PHP), pulsa «crear» y obtiene un repositorio con CI/CD, Helm chart y ArgoCD Application.
TechDocs — documentación directamente en el portal, generada a partir de markdown en los repositorios.
Kubernetes Plugin — visualización del estado de pods, deployments y servicios directamente en la ficha del servicio.

Crossplane — infraestructura como código a nivel de plataforma

Crossplane permite gestionar recursos cloud (RDS, S3, CloudSQL) mediante recursos de Kubernetes. El desarrollador crea un objeto PostgreSQLInstance en su namespace — Crossplane crea automáticamente la base de datos en AWS/GCP y entrega el connection string a través de un Kubernetes Secret.

Este es un elemento clave de la infraestructura de autoservicio: el equipo de desarrollo no escribe Terraform ni abre la consola de AWS — todo se hace mediante el familiar kubectl o la UI de Backstage.

CI/CD como parte de la plataforma: pipelines automáticos para Go y PHP

El CI/CD en una IDP no son simples pipelines. Son plantillas de pipelines estandarizadas y versionadas que el equipo de plataforma mantiene de forma centralizada y los desarrolladores utilizan sin modificaciones.

Ejemplo de estructura de GitLab CI para un servicio Go usando una plantilla compartida de la plataforma:

# .gitlab-ci.yml en el repositorio del servicio Go
include:
  - project: 'platform/ci-templates'
    ref: 'v2.1.0'
    file: '/go-service.yml'

variables:
  SERVICE_NAME: "payment-service"
  GO_VERSION: "1.22"
  REGISTRY: "registry.company.internal"
  HELM_CHART_VERSION: "1.4.0"

La plantilla go-service.yml en el lado de la plataforma implementa el pipeline completo:

# platform/ci-templates/go-service.yml
stages:
  - test
  - build
  - push
  - deploy-preview
  - deploy-staging
  - deploy-production

test:
  stage: test
  image: golang:${GO_VERSION}
  script:
    - go test ./... -race -coverprofile=coverage.out
    - go vet ./...
  coverage: '/coverage: (\d+\.\d+)% of statements/'

build-image:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t ${REGISTRY}/${SERVICE_NAME}:${CI_COMMIT_SHA} .
    - docker push ${REGISTRY}/${SERVICE_NAME}:${CI_COMMIT_SHA}

deploy-preview:
  stage: deploy-preview
  script:
    - argocd app create ${SERVICE_NAME}-pr-${CI_MERGE_REQUEST_IID}
        --repo ${CI_PROJECT_URL}
        --path helm
        --dest-namespace preview-${CI_MERGE_REQUEST_IID}
        --helm-set image.tag=${CI_COMMIT_SHA}
  only:
    - merge_requests

Existe una plantilla equivalente para servicios PHP — con pasos de composer install, phpunit y optimizaciones de caché de configuración específicas de Laravel.

Estandarización del despliegue de microservicios: Helm, Kustomize y GitOps con ArgoCD

Un único Helm chart para todos los microservicios

Una de las decisiones arquitectónicas clave en una IDP es contar con un Helm chart base único para todos los microservicios. Reside en el repositorio de la plataforma e incluye:

Deployment con readiness/liveness probes
HorizontalPodAutoscaler
PodDisruptionBudget
ServiceMonitor para Prometheus
NetworkPolicy
Ingress con TLS automático mediante cert-manager

Cada microservicio solo sobreescribe los valores necesarios en su values.yaml:

# values.yaml de un servicio concreto
service:
  name: payment-service
  port: 8080

image:
  repository: registry.company.internal/payment-service
  tag: "latest"

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

env:
  - name: DB_HOST
    valueFrom:
      secretKeyRef:
        name: payment-db-secret
        key: host

GitOps con ArgoCD

ArgoCD implementa el enfoque GitOps: el estado del clúster siempre coincide con lo definido en Git. El repositorio de infraestructura tiene la siguiente estructura:

gitops-repo/
├── apps/
│   ├── production/
│   │   ├── payment-service/
│   │   │   └── values.yaml
│   │   └── user-service/
│   │       └── values.yaml
│   ├── staging/
│   └── preview/
├── argocd-apps/
│   ├── production.yaml
│   └── staging.yaml
└── platform/
    ├── cert-manager/
    ├── external-secrets/
    └── monitoring/

ArgoCD ApplicationSet permite crear automáticamente una Application para cada servicio en el directorio:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: production-services
spec:
  generators:
    - git:
        repoURL: https://git.company.internal/gitops-repo
        revision: main
        directories:
          - path: apps/production/*
  template:
    spec:
      project: production
      source:
        repoURL: https://git.company.internal/gitops-repo
        targetRevision: main
        path: '{{path}}'
        helm:
          valueFiles:
            - values.yaml
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Gestión de entornos: Preview Environments para cada PR

Los preview environments son uno de los elementos más valiosos de la developer experience. Cada Pull Request obtiene automáticamente un entorno aislado con una URL del tipo https://payment-service-pr-142.preview.company.internal.

A nivel arquitectónico, esto se implementa de la siguiente forma:

El pipeline de CI/CD construye la imagen Docker y la sube al registry con la etiqueta pr-{número}.
El pipeline crea el namespace de Kubernetes preview-142.
ArgoCD crea una Application con el Helm chart, sobreescribiendo el image tag y el hostname.
cert-manager emite un certificado TLS para el dominio de preview.
Al cerrar o hacer merge del PR, el namespace y la ArgoCD Application se eliminan automáticamente.

Para gestionar el ciclo de vida de los preview environments es útil usar Argo CD Ephemeral Access o un Kubernetes Operator personalizado que monitorice el estado de los MRs a través de la API de GitLab/GitHub.

Integración con Docker Registry y gestión de secretos

Docker Registry

La plataforma debe proporcionar un Docker Registry interno único. Las opciones más populares son: Harbor (open-source, con escaneo de vulnerabilidades), GitLab Container Registry o AWS ECR. Harbor es la opción recomendada para entornos on-premise: soporta RBAC, replicación entre regiones e integración con Trivy para el escaneo de imágenes.

Cada servicio obtiene un proyecto individual en Harbor, cuyo acceso se gestiona mediante integración OIDC con el proveedor de identidad corporativo.

Gestión de secretos: Vault + External Secrets Operator

El estándar de oro para los secretos en una plataforma Kubernetes es HashiCorp Vault + External Secrets Operator (ESO). El desarrollador declara qué secreto necesita su servicio mediante un objeto ExternalSecret:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: payment-db-secret
  namespace: payment-service
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: payment-db-secret
    creationPolicy: Owner
  data:
    - secretKey: host
      remoteRef:
        key: secret/production/payment-service/database
        property: host
    - secretKey: password
      remoteRef:
        key: secret/production/payment-service/database
        property: password

ESO sincroniza automáticamente los secretos de Vault a Kubernetes Secrets y los actualiza cuando rotan. El desarrollador nunca ve los valores de los secretos — solo su estructura.

Métricas de la plataforma: métricas DORA y Developer Experience

Una plataforma sin métricas es una plataforma a ciegas. Las métricas clave se dividen en dos grupos:

Métricas DORA para evaluar la entrega

Deployment Frequency — con qué frecuencia el equipo despliega a producción. Objetivo para high-performers: varias veces al día.
Lead Time for Changes — tiempo desde el primer commit hasta producción. Objetivo: menos de 1 hora.
Change Failure Rate — porcentaje de despliegues que provocan un incidente. Objetivo: menos del 5%.
Mean Time to Recovery (MTTR) — tiempo de recuperación tras un fallo. Objetivo: menos de 1 hora.

Métricas de Developer Experience

Tiempo desde la creación de un nuevo repositorio hasta el primer despliegue en staging (onboarding time).
Tiempo de creación de un preview environment para un PR.
Porcentaje de servicios que utilizan las plantillas del golden path.
Encuestas NPS de los desarrolladores sobre la plataforma (trimestrales).

Para recopilar métricas, utilice la combinación Prometheus + Grafana para las métricas técnicas y el plugin Backstage Insights para las métricas de DX. Las métricas DORA pueden calcularse automáticamente a partir de datos de GitLab/GitHub mediante el plugin DORA de Liatrio para Backstage.

Plan paso a paso para construir una IDP desde cero en equipos de 10 a 50 personas

Construir una plataforma es un proceso iterativo. No intente hacerlo todo a la vez. Aquí tiene un roadmap pragmático:

Fase 1: Fundamentos (meses 1–2)

Desplegar un clúster Kubernetes production-ready (EKS/GKE o kubeadm en bare metal).
Configurar un Docker Registry centralizado (Harbor).
Desplegar ArgoCD y migrar los primeros 2–3 servicios a GitOps.
Crear el Helm chart base para microservicios.

Fase 2: Estandarización de CI/CD (meses 2–3)

Crear plantillas de CI/CD compartidas para servicios Go y PHP.
Implementar External Secrets Operator + Vault.
Configurar cert-manager para certificados TLS automáticos.
Lanzar los primeros preview environments.

Fase 3: Developer Portal (meses 3–5)

Desplegar Backstage y poblar el Software Catalog.
Crear Software Templates para los tipos de servicio más comunes (Go API, PHP/Laravel Worker).
Conectar los plugins de Kubernetes y CI/CD a Backstage.
Configurar TechDocs para la documentación interna.

Fase 4: Infraestructura de autoservicio (meses 5–7)

Implementar Crossplane para bases de datos y colas en autoservicio.
Configurar dashboards de métricas DORA en Grafana.
Realizar la primera encuesta trimestral de DX.
Iterar en función del feedback de los desarrolladores.

Conclusión y errores habituales

Construir una Internal Developer Platform es una inversión que se amortiza en un horizonte de 6 a 12 meses para equipos de más de 10 personas. Los principios clave de una plataforma exitosa son:

Platform as a Product — trate la plataforma como un producto con roadmap, SLA y retroalimentación de los desarrolladores.
Golden Path, no Golden Cage — la plataforma debe ofrecer un camino cómodo por defecto, pero no bloquear los casos no estándar.
Adopción incremental — migre los servicios de forma gradual, sin intentar reescribirlo todo en un sprint.

Errores habituales al construir una IDP:

Sobrecomplicar desde el inicio — un equipo de 15 personas no necesita Crossplane ni service mesh en las primeras etapas.
Ignorar la DX — la perfección técnica de la plataforma no sirve de nada si los desarrolladores no la usan por una UX complicada.
Falta de documentación — una plataforma sin TechDocs genera shadow IT y soluciones alternativas.
Sin ownership claro — la plataforma debe contar con un equipo dedicado o al menos un platform engineer responsable; de lo contrario, se deteriora.
Vendor lock-in sin plan de salida — elija herramientas open-source (Backstage, ArgoCD, Crossplane) o servicios cloud de forma consciente, con una exit strategy definida.

Kubernetes como base para una IDP en 2026 no es solo una tendencia de moda, sino una solución técnica madura con un ecosistema enorme. Una plataforma bien construida transforma el cuello de botella de DevOps en un habilitador escalable para toda la organización de ingeniería.

Construcción de una Developer Platform sobre Kubernetes: PaaS interno para equipos de desarrollo