Platform Engineering 101: cómo dejar atrás los sistemas tradicionales de tickets en Azure

By Mirko Peters · 2026-08-13

Bienvenidos de nuevo, oyentes y lectores, a otra inmersión en el cambiante mundo de la arquitectura cloud, la experiencia del desarrollador y el DevOps moderno. Si escuchaste nuestro último episodio del podcast, sabrás que dedicamos buena parte del tiempo a desmontar uno de los cuellos de botella más frustrantes de la entrega de software actual: el sistema tradicional de tickets de TI. Ya conoces

Automatically translated with AI from the original post. Read the English original

Bienvenidos de nuevo, oyentes y lectores, a otra inmersión en el cambiante mundo de la arquitectura cloud, la experiencia del desarrollador y el DevOps moderno. Si escuchaste nuestro último episodio del podcast, sabrás que dedicamos buena parte del tiempo a desmontar uno de los cuellos de botella más frustrantes de la entrega de software actual: el sistema tradicional de tickets de TI. Ya conoces la rutina. Un desarrollador necesita una nueva base de datos, un entorno de staging o una simple actualización de DNS. Abre un ticket. El ticket espera en una cola. Se clasifica, se asigna, se reasigna y, por fin, días o incluso semanas después, se realizan las operaciones manuales. Cuando esa infraestructura llega, el sprint ya ha terminado, el impulso se ha perdido y todos están agotados.

En este artículo complementario vamos a profundizar en los conceptos clave que comentamos en antena. Veremos cómo las organizaciones que usan Microsoft Azure pueden escapar de ese bucle manual que tanto desgasta, adoptando la transformadora disciplina de la ingeniería de plataformas y creando sólidas plataformas internas para desarrolladores (IDP, por sus siglas en inglés).

Introducción: el cuello de botella de los tickets tradicionales en Azure

Pintemos un escenario conocido. Tu organización ha migrado sus cargas de trabajo a Microsoft Azure. Has adoptado la nube, utilizas Azure Kubernetes Service (AKS), Azure SQL, Cosmos DB y App Services. Sobre el papel, estás modernizado. Pero si observas de cerca tu flujo de trabajo, verás que tus desarrolladores tratan Azure igual que antes trataban la sala de servidores local: a través de un muro de burocracia y colas de tickets.

Cada vez que un equipo quiere aprovisionar un recurso, no puede hacerlo por sí mismo. Las barreras de protección se han implementado como obstáculos en lugar de como caminos seguros. Envían un ticket al equipo central de plataforma u operaciones. Esto genera una enorme carga cognitiva y socava por completo la agilidad que se suponía que debía aportar la computación en la nube. Azure ofrece una velocidad y un control programático increíbles, pero a menudo los desarrolladores quedan aislados de ello. El sistema tradicional de tickets funciona como un impuesto sobre la innovación. Cada solicitud requiere intervención humana, lo que introduce errores, malentendidos y retrasos dolorosos. Tenemos que dejar de tratar a los desarrolladores como si no pudieran confiarse en la infraestructura y empezar a verlos como creadores capacitados que necesitan autoservicio respaldado por barreras de protección automatizadas.

¿Qué es la ingeniería de plataformas y por qué importa?

Entonces, ¿cómo lo solucionamos? Aquí entra la ingeniería de plataformas. En los últimos años, la ingeniería de plataformas se ha consolidado como la evolución definitiva del DevOps. Mientras que el DevOps derribó en teoría el muro entre desarrollo y operaciones, en la práctica muchas organizaciones simplemente trasladaron toda la carga operativa a los desarrolladores. De pronto, se esperaba que los desarrolladores dominaran Kubernetes, Terraform, la seguridad de red y las directivas de IAM de Azure, mientras intentaban escribir la lógica de negocio.

La ingeniería de plataformas reconoce que esta situación es insostenible. En lugar de obligar a los desarrolladores a convertirse en expertos en infraestructura o a esperar en una cola de tickets, la ingeniería de plataformas trata la experiencia del desarrollador como un producto. Un equipo de plataforma dedicado construye una plataforma interna para desarrolladores (IDP) que abstrae la complejidad subyacente de Azure.

¿Por qué importa esto? Porque la carga cognitiva es el enemigo silencioso de la productividad en ingeniería. Cuando los desarrolladores dedican el 40 por ciento de su tiempo a pelear con configuraciones de infraestructura, listas de verificación de cumplimiento y esperas de aprobaciones, no están construyendo funcionalidades que deleiten a los clientes. La ingeniería de plataformas importa porque devuelve el estado de flujo a los equipos de ingeniería. Ofrece caminos dorados (golden paths): arquitecturas preaprobadas, muy seguras y conformes con la normativa que los desarrolladores pueden desplegar con un solo clic o un solo comando.

Más allá de las operaciones manuales: la visión de las plataformas internas para desarrolladores

Para ir de verdad más allá de las operaciones manuales en Azure, debemos cambiar nuestra mentalidad: pasar de gestionar infraestructura a construir plataformas. Una plataforma interna para desarrolladores no es solo una herramienta; es una capa cohesiva situada sobre tu infraestructura cloud de Azure que selecciona servicios y herramientas para entregar software sin fricciones.

El problema de los scripts ad hoc y el aprovisionamiento "salvaje"

Algunas organizaciones se dan cuenta de que la gestión de tickets es lenta, así que reparten acceso de colaborador a las suscripciones de Azure y dejan que los desarrolladores creen lo que quieran. Es el extremo opuesto, y resulta igual de desastroso. Muy pronto tienes recursos sin gestionar, facturas de nube disparadas, vulnerabilidades de seguridad masivas y ninguna forma estándar de supervisar o actualizar nada. Es el Salvaje Oeste.

El punto ideal de una IDP

Una IDP logra el equilibrio perfecto. Ofrece capacidades de autoservicio e integra la seguridad, el cumplimiento, la gestión de costes y los estándares de arquitectura directamente en el flujo de trabajo. Los desarrolladores obtienen la autonomía que buscan, mientras que los equipos de operaciones y seguridad consiguen la gobernanza y el cumplimiento que necesitan. Es un escenario en el que todos ganan, posibilitado por la automatización.

Pilares fundamentales para crear una plataforma de desarrollo basada en Azure

Cuando construyes tu Internal Developer Platform sobre Microsoft Azure, necesitas apoyarte en una base arquitectónica sólida. Veamos los pilares fundamentales que hacen que una plataforma basada en Azure tenga éxito.

1. Infraestructura como código (IaC) y catálogos de módulos

En el centro de cualquier plataforma en la nube está la infraestructura como código. En el ecosistema de Azure, normalmente significa Terraform, Bicep o plantillas de Azure Resource Manager (ARM). Sin embargo, escribir archivos Bicep no basta. Tu equipo de plataforma debe crear un catálogo curado de plantillas modulares, reutilizables y seguras. Por ejemplo, en lugar de dejar que un desarrollador escriba desde cero la configuración de su base de datos, la plataforma ofrece un módulo de Azure SQL que ya incluye cifrado de nivel empresarial, integración de red adecuada y directivas de copia de seguridad preconfiguradas. El desarrollador solo tiene que indicar el nombre de la aplicación y el nivel.

2. Directivas como código con Azure Policy

La gobernanza no puede depender de que las personas marquen casillas. Debe automatizarse. Al integrar Azure Policy y Azure Blueprints en tu plataforma, garantizas que cada recurso aprovisionado a través de la IDP cumpla automáticamente con los marcos normativos y los estándares corporativos internos. Si un desarrollador intenta aprovisionar una cuenta de almacenamiento sin cifrado en tránsito, la plataforma lo detecta al instante y lo rechaza antes de que llegue siquiera a Azure.

3. Integración fluida de CI/CD y GitOps

Tu IDP no debe vivir aislada. Debe integrarse de forma nativa con tu sistema de control de versiones y con tus canales de implementación. Tanto si usas GitHub Actions, Azure DevOps como ArgoCD para GitOps, la plataforma debe orquestar el flujo desde el commit del código hasta la implementación en Azure sin fricciones. Los desarrolladores deberían poder crear o eliminar entornos directamente desde sus pull requests.

4. Observabilidad y supervisión unificadas

No puedes gestionar lo que no puedes medir. Una gran plataforma ofrece observabilidad desde el primer momento, conectando las aplicaciones directamente con Azure Monitor, Application Insights y Azure Log Analytics. Cuando un desarrollador crea un nuevo microservicio a través de la plataforma, el registro, las métricas y el trazado se configuran y conectan automáticamente, sin necesidad de instrumentación manual.

Acortar los plazos de entrega y reducir la fricción para los desarrolladores

Hablemos del impacto tangible de implementar esta arquitectura. Cuando sustituyes un proceso de tickets de dos semanas por un portal de autoservicio de dos minutos, las métricas cambian de forma notable.

Time-to-Market y frecuencia de implementación

La velocidad de desarrollo se dispara. Las funciones que antes se quedaban estancadas en entornos de staging a la espera de configuraciones de red manuales ahora pueden implementarse al instante. Los equipos pueden crear entornos efímeros para cada pull request, probar su código en un entorno que es una réplica exacta de producción y eliminarlo cuando el PR se fusiona. Este nivel de agilidad es imposible en un mundo de tickets manuales.

Eliminar el agotamiento de los desarrolladores

La satisfacción de los desarrolladores es una métrica crítica que demasiadas organizaciones ignoran. Pelear constantemente con la burocracia, esperar a otros equipos y lidiar con tareas repetitivas y de poco valor conduce directamente al agotamiento y a una alta rotación. Al eliminar la fricción y automatizar lo tedioso, creas un entorno en el que los ingenieros se sienten creativos, productivos y valorados. Los desarrolladores felices escriben mejor código.

Buenas prácticas para implantar la ingeniería de plataformas en tu organización

Construir una Internal Developer Platform en Azure suena espectacular, pero ¿cómo se ejecuta realmente sin causar una disrupción enorme? Estas son algunas buenas prácticas que recomendamos a nuestros oyentes y a nuestros clientes de consultoría.

Tratar la plataforma como un producto

Esta es la regla de oro de la ingeniería de plataformas. Tus desarrolladores internos son tus clientes. Tienes que hacer investigación de usuarios, recoger comentarios, escribir documentación e iterar de forma continua según sus necesidades. Si tu plataforma es torpe y difícil de usar, los desarrolladores encontrarán soluciones alternativas y tu iniciativa fracasará.

Empieza poco a poco con una plataforma mínima viable (MVP)

No intentes construir una plataforma monolítica que lo abarque todo desde el primer día. Empieza con un único caso de uso que resuelva un problema importante. Por ejemplo, empieza automatizando el aprovisionamiento de microservicios estándar en Azure Kubernetes Service con registro y bases de datos integrados. Una vez que eso tenga éxito y se adopte, amplía las capacidades de la plataforma de forma iterativa.

Dedica mucha atención a la documentación para desarrolladores y a la experiencia del portal

Incluso la automatización de backend más potente no sirve de nada si los desarrolladores no saben cómo usarla. Invierte en un portal para desarrolladores: herramientas como Backstage de Spotify se han vuelto enormemente populares precisamente para esto. Si combinas Backstage con las integraciones de Azure, das a tus equipos un único punto de acceso para consultar la documentación, explorar los catálogos de servicios y ejecutar acciones de autoservicio.

Conclusión: capacitar a los equipos de desarrollo modernos para el futuro

Los sistemas de tickets tradicionales son reliquias de una época pasada. Frenan la innovación, frustran el talento de ingeniería y no aprovechan el verdadero poder y la agilidad de la infraestructura en la nube, como Microsoft Azure. Al adoptar la ingeniería de plataformas y crear plataformas internas para desarrolladores bien pensadas, seguras y automatizadas, las organizaciones pueden eliminar cuellos de botella, aplicar una gobernanza sólida y liberar todo el potencial de sus equipos de desarrollo.

Recuerda que el objetivo de la arquitectura cloud moderna no es simplemente trasladar tus servidores al centro de datos de otra persona; es capacitar a tu gente para entregar valor más rápido y de forma más segura que nunca. Gracias por seguir este artículo ampliado. Asegúrate de suscribirte al podcast, comparte este artículo con tus equipos de plataforma y DevOps, y acompáñanos la próxima vez, cuando sigamos explorando la vanguardia de la tecnología cloud.