En Sportradar, con frecuencia realizamos talleres de experiencia para desarrolladores, en los que solicitamos a nuestra comunidad interna de ingenieros que hablen sobre sus experiencias y sus desafíos. Estos talleres son de gran utilidad en muchos sentidos y siempre nos dejan con muchas ideas sobre cómo podemos mejorar el soporte que brindamos a nuestros desarrolladores. Una de las cosas que hemos hecho es introducir un enfoque cohesivo a la ingeniería de plataformas, lo que ha permitido que los equipos de desarrollo se vuelvan autosuficientes y multifuncionales.

Creo que un elemento esencial de la ingeniería de plataformas es escuchar a los clientes y a la comunidad para descubrir cuáles son sus necesidades y deseos, y ofrecerles eso. Y para nuestros equipos en la plataforma centralizada y en el entorno de DevOps, los clientes son los desarrolladores de Sportradar. 

En Sportradar, utilizamos la ingeniería de plataformas de cuatro maneras.

1. Reestructurar a los equipos para lograr autosuficiencia 

En Sportradar, utilizamos el modelo de Spotify, que depende de que cada grupo —incluido DevOps— tenga la experiencia de equipo necesaria para diseñar funciones y aplicaciones para su base de usuarios finales. A mediados de 2019, iniciamos nuestro propio proceso de reorganización, que llamamos “Sportify”, el que ya está completamente implementado. Como muchas empresas, una de las maneras en que Sportradar crece es a través de las adquisiciones, de modo que siempre hay un periodo de transición a medida que adquirimos nuevas compañías y ayudamos a que las personas se adapten a nuestro modelo. En nuestro modelo “Sportify”, los equipos de la plataforma desempeñan una función central mientras que los especialistas de DevOps son parte integral de los grupos.

Si bien los grupos están logrando un objetivo tras otro y generando beneficios para toda la organización, también se enfrentan a algunos desafíos. Cada equipo tiene su propio conjunto de objetivos y principios que guía la toma de decisiones, de modo que pueden presentarse dificultades si se tratan de aprovechar los recursos comunes para cosas como el uso de Kubernetes o la configuración del monitoreo de observabilidad. 

Para abordar este problema, hemos creado un nuevo grupo de habilitación de ingeniería destinado a apoyar el uso de las mejores prácticas en cada grupo; esto reúne a DevOps y a los ingenieros de plataformas en torno a principios y objetivos comunes, además de que se encarga de difundir estrategias y herramientas centralizadas. En este equipo recién creado, nos enfocamos en los grandes desafíos de ingeniería y luego diseñamos frameworks y herramientas para enfrentarlos. También nos esforzamos para asegurarnos de que los DevOps en los grupos y los del equipo de la plataforma central estén perfectamente compaginados.

2. Utilizar caminos pavimentados para tareas de desarrollo comunes

El grupo de habilitación de ingeniería utiliza la estrategia de caminos pavimentados para acelerar los nuevos proyectos y reducir la fricción en el desarrollo. Otras empresas pueden llamarlo a esto reglas de oro o caminos dorados, pero cualquiera que sea el nombre, quiere decir que los ingenieros van a lograr su cometido mucho más rápido. 

Cuando los desarrolladores crean aplicaciones, su objetivo es que esas aplicaciones funcionen bien, deleiten a los clientes y generen ingresos. Si abandonas el camino pavimentado, aún podrás lograr esos objetivos, pero te vas a demorar un poco más. Si sigues por el camino pavimentado, eliminarás una gran parte de la complejidad. Por eso es útil que la habilitación de ingeniería, la plataforma centralizada y los equipos de DevOps trabajen juntos. Las funciones centrales definen los servicios gestionados que se necesitan para dar soporte a los desarrolladores para que adopten una estrategia de caminos pavimentados. También comparten un stack común que ayuda con la observabilidad, las decisiones del ciclo de vida de desarrollo de software, las canalizaciones de integración y entrega continuas (CI/CD), y otros frameworks y soluciones.

3. Crear un conjunto básico de métricas comunes

En los caminos pavimentados, la función de observabilidad de New Relic está más disponible y estandarizada en toda la organización. Todos los grupos miden tres métricas básicas: disponibilidad, fiabilidad y rendimiento. Al comenzar un nuevo proyecto, los desarrolladores utilizan un stack de caminos pavimentados, que incluye New Relic y aplicaciones de New Relic especialmente diseñadas, para introducir estas métricas básicas y permitir que los desarrolladores sigan escribiendo código para sus aplicaciones en lugar de tener que crear y administrar una plataforma de aplicaciones. 

En última instancia, New Relic elimina la complejidad: es un servicio gestionado, de modo que los desarrolladores no tienen que encargarse de los servidores. La complejidad es baja porque con la instrumentación automática los desarrolladores pueden incluir al agente en sus aplicaciones. También podemos utilizar algunos de los otros frameworks existentes en un modelo de caminos pavimentados para hacer pruebas sintéticas de las aplicaciones en un entorno que no es de producción. Las métricas comunes en un modelo de caminos pavimentados ayudan a reunir todas estas cosas y reducir considerablemente el tiempo necesario para el lanzamiento del producto.

4. Publicar un catálogo de servicios gestionados

Un portal interno para desarrolladores proporciona un cuadro de mandos para todas nuestras aplicaciones y nuestros servicios. Un catálogo de servicios se utiliza para arrancar el proyecto y para agregar el servicio al portal para desarrolladores. Los desarrolladores del grupo seleccionan lo que desean, y el catálogo proporciona un stack específico con todos los componentes de la aplicación o del servicio que desean diseñar. Esto permite a los desarrolladores concentrarse en lo verdaderamente importante para ellos: diseñar aplicaciones excelentes. El equipo de la plataforma proporciona todas las soluciones de hosting gestionado y servicios básicos, resolución de nombres, redes y cualquier otra cosa que se necesite. El equipo centralizado de DevOps proporciona las capacidades de observabilidad y canalización automatizada. La plantilla de ese camino pavimentado arranca y el desarrollador puede entonces enfocarse en las complejidades de las aplicaciones, y no necesariamente en el ecosistema que se encuentra alrededor. 

También tenemos un líder de producto en el grupo de habilitación de ingeniería, que se dedica exclusivamente a analizar todas las funciones de la plataforma y de DevOps para asegurarse de que todos los productos que estamos diseñando sean razonables y que las implementaciones de caminos pavimentados se combinen de manera coherente y sirvan las necesidades de los desarrolladores de manera eficaz.