El impuesto de TypeScript y React

Backstage es, por naturaleza, un marco de trabajo para construir un portal de desarrollo, no un portal llave en mano en sí mismo. Arquitectónicamente, requiere mantener un gran espacio de trabajo de Yarn que contiene tanto un backend en Express.js como un frontend complejo en React. 

Considere a su equipo de ingeniería de plataforma o SRE. Por lo general, se trata de ingenieros especializados en Kubernetes, redes de AWS, Terraform, Go, Python o scripting avanzado en Bash. Al imponer un despliegue de Backstage, de repente está obligando a expertos en infraestructura a convertirse en desarrolladores de JavaScript de pila completa (full-stack). Se les encomienda la tarea de configurar Webpack, resolver conflictos en el árbol de dependencias de Node.js y depurar estados complejos de componentes de React solo para renderizar una tabla de microservicios. Este "Impuesto de React" asigna fundamentalmente de manera incorrecta a su talento de infraestructura más costoso y especializado.

La carga del mantenimiento de plugins

Para obtener algún valor real de una IDP (Plataforma Interna de Desarrollo), esta necesita ingerir datos de su cadena de herramientas existente. Datadog, GitHub Actions, AWS EKS, PagerDuty, SonarQube, ArgoCD; la lista continúa. Aunque la comunidad de código abierto ofrece un catálogo de plugins, la realidad de integrarlos en un entorno de producción es brutal. 

Los plugins frecuentemente se desactualizan, chocan con las actualizaciones de la versión principal de Backstage o simplemente no se adaptan a sus casos de uso arquitectónicos personalizados. Gestionar los límites de tasa de API, manejar las rotaciones de tokens para sus integraciones de CI/CD y garantizar que la base de datos PostgreSQL/SQLite que respalda su catálogo no se convierta en un cuello de botella se convierte en un trabajo de tiempo completo. Su equipo de plataforma termina manteniendo integraciones de API personalizadas y depurando el enrutamiento del frontend en lugar de construir automatización de infraestructura central y escalable.

La desviación de YAML y el panel único de mentiras

Un catálogo de software depende en gran medida de los metadatos. In el mundo DIY (hágalo usted mismo) de Backstage, esto generalmente significa archivos catalog-info.yaml dispersos en docenas, si no cientos, de repositorios dispares. 

Sin una gobernanza estricta y automatizada y procesadores de catálogo personalizados que validen estos archivos durante el proceso de CI, estos metadatos se deterioran rápidamente. Se cambia el nombre de los repositorios, los propietarios abandonan la empresa y los puntos de enlace de la API cambian. El prometido "panel único" se convierte rápidamente en un "panel único de mentiras". Una vez que los desarrolladores se dan cuenta de que los datos del catálogo son inexactos, su confianza en el portal cae a cero y la adopción se estanca.

En Betta, vemos este patrón exacto repetidamente. Una startup en crecimiento decide construir una IDP para aumentar la velocidad, pero termina dedicando ciclos cruciales de ingeniería central a gestionar una herramienta interna que no genera un solo dólar de ingresos.

La Plataforma como Producto (PaaP): Cambiando el paradigma

Para escapar de la resaca de Backstage, el liderazgo de ingeniería necesita reformular cómo ve la ingeniería de plataforma. El objetivo final no es construir un portal visualmente atractivo; el objetivo es construir un camino pavimentado.

Tratar su plataforma como un producto (PaaP, por sus siglas en inglés) significa tratar a sus desarrolladores internos como sus clientes principales. Cuando adopta una mentalidad de PaaP, comienza a realizar investigaciones de usuarios reales. Pregunta a sus ingenieros de producto: ¿Qué los está retrasando realmente? ¿Qué les causa la mayor fricción en su día a día?

La mayoría de las veces, la respuesta no es "No tengo una interfaz de usuario para ver mis servicios". Las respuestas están profundamente arraigadas en cuellos de botella de los flujos de trabajo:

• "Me toma tres días, cinco tickets de Jira y un hilo de Slack con DevOps para que me aprovisionen una nueva base de datos PostgreSQL."

• "No tengo idea de cómo configurar correctamente nuestros pipelines de GitHub Actions para un nuevo servicio Node.js sin copiar y pegar de un repositorio heredado."

• "Levantar un entorno efímero para pruebas de integración requiere un doctorado en Kubernetes y Helm."

Una verdadera IDP debe ser un motor de autoservicio. Debería proporcionar plantillas de andamiaje que levanten instantáneamente un nuevo microservicio con Dockerfiles de mejores prácticas, configuraciones de Terraform, escaneo de seguridad y flujos de trabajo de CI/CD ya inyectados y conformes con la política de la empresa. 

Si su equipo de plataforma pasa su tiempo corrigiendo un error de alineación de CSS en un panel de React o actualizando un backend de Express.js, no están construyendo estos caminos pavimentados críticos. 

Cómo resuelve Betta la trampa: la pila de IDP eficiente

Recientemente, una empresa de SaaS B2B en etapa de Serie B llegó a Betta en estado de crisis. Tenían un equipo de ingeniería de 60 personas, pero su tiempo de comercialización se había detenido de manera agonizante. Habían asignado a cuatro de sus ingenieros de backend e infraestructura más experimentados para construir y mantener una instancia personalizada de Backstage para gestionar su creciente arquitectura de microservicios. 

Esos cuatro ingenieros se estaban ahogando en errores de frontend, conflictos de plugins y problemas de validación de YAML. Mientras tanto, el resto del equipo de desarrollo estaba crónicamente bloqueado, esperando días por el aprovisionamiento de infraestructura básica porque los expertos en infraestructura central estaban ocupados jugando a ser desarrolladores de interfaz de usuario (UI).

Aquí está exactamente cómo el equipo de ingeniería fraccional de Betta resolvió el cuello de botella y restauró la velocidad de la ingeniería:

Paso 1: Eliminar el trabajo pesado, incorporar SaaS

Inmediatamente pausamos el desarrollo en el portal personalizado de Backstage. Realizamos la transición del cliente a una IDP SaaS moderna y gestionada (en este caso, Port, aunque Cortex y OpsLevel también son excelentes opciones de nivel empresarial). 

Al aprovechar una herramienta SaaS, descargamos instantáneamente la carga de alojar, parchear, asegurar y mantener un frontend en React y un backend en Node. El problema de la interfaz de usuario fue resuelto permanentemente por un proveedor, lo que permitió al equipo interno volver a centrarse por completo en el valor del negocio.

Paso 2: Comprar el panel, construir la automatización

Con el "panel único" proporcionado por un proveedor completamente gestionado, los SRE fraccionales de Betta se pusieron a trabajar en lo que realmente importaba: la compleja automatización de la infraestructura debajo del panel. 

Utilizamos el robusto sistema de API y webhooks de la IDP SaaS para conectarnos directamente a sus ejecutores de GitHub Actions. Construimos módulos de Terraform seguros y estandarizados para su infraestructura de AWS, encapsulando las mejores prácticas de seguridad y alta disponibilidad. 

Ahora, cuando un desarrollador hace clic en "Crear nuevo servicio" en el portal SaaS, un webhook activa una GitHub Action, que invoca de forma segura nuestros módulos personalizados de Terraform. Este flujo de trabajo completamente automatizado aprovisiona un espacio de nombres de EKS, una base de datos RDS, los roles de IAM necesarios e inyecta el código del repositorio base, todo en menos de cinco minutos y de forma completamente autónoma.

Paso 3: Talento elástico para un problema elástico

Debido a que el cliente utilizó los servicios de ingeniería de plataforma fraccionales de Betta, no necesitaron contratar a un equipo de plataforma costoso de tiempo completo solo para configurar la capa de automatización inicial. 

Trajimos expertos especializados para construir los caminos pavimentados complejos y de alta fricción, los integramos sin problemas en el portal SaaS, documentamos los flujos de trabajo de manera exhaustiva y transferimos la operación diaria de regreso a su personal de DevOps interno más eficiente. 

¿El resultado? Esos cuatro ingenieros de backend senior fueron reasignados nuevamente a construir el producto central de la empresa que genera ingresos. El tiempo de entrega para los cambios de infraestructura se redujo de días a minutos, y el tiempo general de comercialización mejoró en un 45 % en dos meses. 

Medir las métricas correctas: Validar su plataforma

¿Cómo sabe si su estrategia de ingeniería de plataforma realmente está funcionando, o si solo está introduciendo otra capa de complejidad arquitectónica? Necesita realizar un seguimiento de las métricas correctas. 

En Betta, vinculamos rigurosamente las iniciativas de plataforma con las métricas DORA y los indicadores de carga cognitiva para garantizar un ROI medible:

1.  Frecuencia de despliegue: ¿Están los desarrolladores entregando lotes más pequeños y seguros con más frecuencia porque el camino pavimentado de CI/CD es fluido y confiable?

2.  Tiempo de entrega para cambios: ¿Cuánto tiempo pasa desde una confirmación (commit) inicial hasta que el código se ejecuta en producción? Si los desarrolladores están esperando tickets de TI o DevOps para aprovisionar infraestructura, este número aumenta. Los portales de autoservicio robustos reducen significativamente este número.

3.  Tiempo medio de recuperación (MTTR): ¿Ofrece su portal un acceso fácil y centralizado a los manuales de incidentes, paneles de observabilidad de Datadog y alertas de PagerDuty, permitiendo a los desarrolladores resolver incidentes en vivo más rápido?

4.  Carga cognitiva del desarrollador: Aunque es más difícil de medir cuantitativamente, se puede rastrear fácilmente a través de encuestas trimestrales del marco SPACE. ¿Se sienten los desarrolladores abrumados por YAML, manifiestos de Kubernetes y scripts de pipeline, o están enfocados puramente en escribir lógica de negocio?

Si su implementación de IDP no está mejorando activamente estas métricas específicas, es probable que esté sufriendo de la resaca de Backstage. 

El balance final

La ingeniería de plataforma no consiste en construir paneles de interfaz de usuario y catálogos de software desde cero; se trata de eliminar implacablemente la fricción de su ciclo de vida de desarrollo de software. Para las startups en crecimiento, dedicar ciclos de ingeniería escasos y muy bien remunerados a construir portales internos DIY es un lujo que simplemente no se pueden permitir.

Adopte la mentalidad de Plataforma como Producto (PaaP), aproveche las alternativas ágiles de SaaS para adquirir la capa de interfaz de usuario y confíe en expertos técnicos especializados para construir la automatización subyacente que realmente marque la diferencia. Sus desarrolladores, y su director financiero, se lo agradecerán.