Los desarrolladores quieren tener acceso a entornos Kubernetes de forma rápida y sin las demoras habituales de las solicitudes por tickets que pueden prolongarse una semana o más. Sin embargo, los equipos de plataforma son los encargados de gestionar los costes, permisos y el cumplimiento de políticas corporativas en estos entornos, generando una tensión natural en la implantación del autoservicio de Kubernetes: ¿qué se puede delegar con seguridad a los desarrolladores y qué debe seguir bajo control del equipo de plataforma?
En una reciente entrevista, especialistas en nube corporativa de Hewlett Packard Enterprise (HPE), como Marius Bogoevici, Senior Principal Product Manager, y Karthik Subramanian, Principal Product Manager de HPE Morpheus Software, analizaron los puntos de conflicto clave en este modelo de autoservicio.
HPE ofrece con su distribución certificada por la CNCF, HKS, integrada en el software HPE Morpheus, un modelo operativo que combina Kubernetes, máquinas virtuales e infraestructuras diversas, tanto en local como en nube híbrida y pública. Esta solución facilita a los equipos de plataforma la entrega y gestión del ciclo de vida de los entornos Kubernetes, asegurando que cumplen con las políticas internas. 
Juntos, HKS y HPE Morpheus extienden el alcance más allá de la provisión de infraestructura, enlazando catálogos de servicios y aplicaciones con pipelines CI/CD, registros de contenedores y herramientas de automatización usadas por desarrolladores. Esto elimina la necesidad de que cada equipo configure manualmente su cadena de herramientas para cada proyecto, ofreciendo un camino gobernado y listo para desplegar.
El desafío del autoservicio: complejidad y mantenimiento
El Kubernetes open source ofrece orquestación y APIs declarativas, pero carece de un modelo operativo completo. Las organizaciones que intentan construir su propia capa de autoservicio se enfrentan a dos problemas principales:
- Fragmentación de herramientas: Para tener un Kubernetes adecuado para producción, los equipos de plataforma deben administrar un vasto y cambiante ecosistema de herramientas CNCF relacionadas con networking, almacenamiento, ingreso, identidad y políticas, lo que demanda gran esfuerzo y mantenimiento constante.
- Gestión del ciclo de vida y diversidad de entornos: Crear un clúster Kubernetes es sencillo, pero mantenerlo actualizado en todos los entornos (desarrollo, pruebas, staging, producción) es complejo. Esto se agrava si los clústeres abarcan metal desnudo, nubes privadas, sitios edge y nubes públicas, donde scripts únicos y configuraciones específicas generan divergencias difíciles de corregir.
Dar acceso directo a las APIs de Kubernetes solo traslada el trabajo operativo a los desarrolladores, quienes acabarían depurando manifiestos y controladores en lugar de centrarse en su código. Mientras tanto, operaciones deben gestionar sobreaprovisionamiento, clústeres inactivos y configuraciones no revisadas que llegan a producción.
Control compartido: lo que el desarrollador elige y el equipo de plataforma gobierna
La respuesta práctica no es dar acceso sin restricciones, sino ofrecer un camino definido: servicios Kubernetes aprobados que los desarrolladores pueden solicitar con controles de acceso, configuración, ubicación, aprobaciones y gestión del ciclo definidos por plataforma.
Marius Bogoevici explica que el autoservicio debe centrarse en peticiones repetibles, de bajo riesgo y bien entendidas. Por ejemplo, solicitar un clúster de desarrollo, desplegar aplicaciones aprobadas, crear namespaces o elegir configuraciones preaprobadas sin necesidad de tickets. La plataforma establece qué configuraciones son seguras y el desarrollador selecciona dentro de ese catálogo.
“El equipo de plataforma decide qué configuraciones son seguras y el desarrollador elige de un menú de soporte.”
En lugar de que el desarrollador escriba YAML para ingress, clases de almacenamiento y RBAC, HPE Morpheus expone estos elementos mediante catálogos de servicios, plantillas reutilizables, flujos de trabajo, controles de acceso basados en roles, APIs y automatización. Esto permite a los desarrolladores mantener acceso directo a Kubernetes cuando se permite, pero bajo un marco gobernado.
Además, los catálogos pueden incluir servicios y componentes de aplicación aprobados que forman parte del flujo de trabajo de desarrollo, como herramientas CI/CD, repositorios de código y artefactos, registros de contenedores y dependencias en tiempo de ejecución, mientras que la configuración y gobernanza quedan bajo responsabilidad del equipo de plataforma.
Los desarrolladores pueden elegir parámetros clave para la aplicación, tales como:
- Versiones y tamaños de clúster Kubernetes preaprobados.
- Cuotas de recursos personalizadas (CPU, RAM, almacenamiento).
- Conjuntos integrados de herramientas y entornos IDE.
- Duración de los clústeres o entornos temporales para evitar proliferación de infraestructuras abandonadas.
En cambio, aspectos críticos como aislamiento de red, integración con proveedores de identidad, políticas de seguridad y asignación de costes permanecen controlados y automáticos por parte del equipo de plataforma.
Esta separación también se extiende a la cadena de entrega: los desarrolladores eligen servicios aprobados, mientras plataforma gestiona integraciones, credenciales, políticas y automatización, asegurando una experiencia consistente sin traspasar a cada equipo la responsabilidad de gobernar la cadena de herramientas.
En resumen, las responsabilidades quedan claras en áreas clave como provisión de clústeres, despliegues en producción, asignación de recursos, redes y seguridad, y gobernanza del ciclo y costos, con rutas definidas para excepciones, revisiones o configuraciones no estándar.
Del cuello de botella de tickets a un camino claro y repetible
Tradicionalmente, provisionar un entorno Kubernetes requiere múltiples equipos y procesos burocráticos con colas de espera que alargan la puesta en marcha semanas. La unificación de la orquestación, controles basados en roles y multi-tenancy en una sola experiencia operativa reduce estos tiempos a minutos u horas, proporcionando entornos usables y conformes a políticas sin necesidad de que el desarrollador conozca todos los pasos de infraestructura detrás.
“Reducir el tiempo de semanas a horas tiene un impacto tangible y significativo”, afirma Bogoevici.
Esta agilidad también permite automatizar la integración con los pipelines CI/CD y servicios de aplicaciones ya autorizados, eliminando esperas para conectar herramientas y dependencias, y entregando a desarrolladores un camino de desarrollo a despliegue listo para usar.
No obstante, la rapidez conlleva el riesgo de perder el control sobre qué se ha provisionado y para qué. HPE Morpheus ofrece visibilidad administrativa sobre uso y costes, además de controles de duración que cierran entornos temporales automáticamente al finalizar su plazo.
Para evaluar el éxito deben observarse indicadores como tasa de despliegues exitosos, excepciones, uso eficiente de recursos y esfuerzo diario en mantenimiento, más que el volumen de tickets.
La seguridad como pilar del diseño del servicio
La seguridad debe integrarse desde el diseño del servicio, no añadirse tras la creación del clúster, para evitar trabajo adicional y riesgos de inconsistencias en cada solicitud.
“La seguridad es una consideración esencial en el diseño, no una idea posterior,” asegura Bogoevici. HPE Morpheus incorpora identidad, control basado en roles, aislamiento multiusuario, aprobaciones y políticas dentro del flujo operativo.
Así, un entorno recién provisionado siempre llega con las configuraciones de identidad, permisos, inquilino, políticas y auditoría aprobadas. Los equipos de plataforma pueden validar y probar todas estas capas con solicitudes permitidas y rechazadas, asegurando trazabilidad y conformidad.
Un modelo operativo equilibrado para el futuro
El mejor autoservicio Kubernetes no oculta la tecnología ni impone el control total sobre cada carga de trabajo. Ofrece elecciones útiles y aprobadas para desarrolladores, junto a acceso directo donde convenga, mientras la plataforma estandariza procesos empresariales y políticas en segundo plano.
Dado que las empresas continúan operando máquinas virtuales, infraestructuras tradicionales y nubes públicas junto a Kubernetes, HPE Morpheus facilita un modelo común que abarca todos estos entornos, evitando silos o imponer un único runtime.
En la práctica, esto significa que el autoservicio debe entregar más que un clúster Kubernetes: proporciona un entorno completo con servicios de aplicaciones y herramientas DevOps integradas y gobernanza asegurada. De este modo, los desarrolladores dedican menos tiempo a montar la infraestructura de entrega y más a crear y lanzar aplicaciones.
Mirando a 2027, el objetivo es el acceso rápido y predecible con límites claros y una vía de excepción transparente, no el control ilimitado.
