🥇Servicios legados en su infraestructura

¡Hola! Me llamo Pasha Chernyak, soy desarrollador principal en QIWI, y hoy quiero hablar sobre lo inevitable. Sobre Legacy.

Empecemos con la pregunta: ¿qué es un servicio Legacy? ¿Es un servicio que el desarrollador no ha tocado en una semana/mes/año? ¿O es un servicio que fue escrito por un programador menos experimentado, como usted, pero hace un año? ¡Ahora ya es más experto y competente! O, ¿un servicio Legacy es aquel que ha decidido no volver a modificar y que está preparando lentamente para reemplazar? En cualquier caso, dejar un servicio así desatendido y sin actualizar es una bomba de tiempo que puede explotar más adelante.

Antes de pasar a cómo trabajamos en QIWI con nuestros servicios Legacy, les contaré cómo hemos organizado los servicios en la Billetera. Desde hace dos años, soy responsable de su funcionamiento. Si hay algún problema, la primera persona a la que llaman es a mí. Normalmente, no tengo el descaro de llamar a alguien más a las 11 de la noche, así que he tenido que sentarme y entender todos los servicios de nuestro dominio.

Pero yo, como cualquier persona, amo dormir por la noche, así que intenté entender la explotación: 'Chicos, ¿por qué me llaman?'. A lo que recibí una respuesta bastante concisa como '¿A quién más?'. Porque yo arreglo los servicios y, además, los chicos simplemente no saben a quién llamar.

Así que en una de las retrospectivas del equipo de backend de la Billetera, decidimos que era necesario crear una tabla con la lista de nuestros servicios, microservicios y monolitos de la billetera, y las personas responsables de ellos. Las tablas son realmente útiles, dentro de límites razonables.

Además de la información sobre quién es responsable de qué, también había respuestas a las preguntas: quién es el propietario del servicio, quién es responsable de su desarrollo, de la arquitectura y del ciclo de vida. Las personas responsables de este servicio son las que pueden arreglarlo si es necesario. El propietario del servicio tiene derecho a dejar +2 en los commits, y los responsables también deben asistir obligatoriamente a la revisión antes de que este servicio acepte un nuevo commit.

Con el paso del tiempo, comenzaron a aplicarse nuevas prácticas, como la migración a Kubernetes, el uso de checkstyle, spotbugs, ktlint, la inclusión de logs en Kibana, autodiscovery de servicios en lugar de indicar las direcciones directamente, entre otras utilidades. Y en todas partes nuestra tabla permitía mantener actualizados nuestros servicios. Para nosotros, es una especie de lista de verificación que indica qué habilidades tiene el servicio y cuáles aún no. Pero seguimos avanzando, dándonos cuenta de que nos falta información sobre nuestros servicios, como dónde se almacenan los códigos fuente, dónde se lanzan las tareas de construcción en TeamCity, cómo se despliegan, dónde se guardan los códigos fuente de las pruebas end2end, fotos sobre la arquitectura y las decisiones tomadas. Idealmente, queríamos que toda esta información estuviera disponible y accesible cuando la necesitáramos. Por eso, nuestra tabla se convirtió en el punto de partida para buscar información.

Pero QIWI, aunque conserva el espíritu de una startup, es una gran empresa. Ya tenemos 12 años, y los equipos cambian: las personas se van, otras llegan, se forman nuevos equipos. Y descubrimos en nuestro dominio varios servicios que heredamos. Algunos vinieron con desarrolladores de otros equipos, otros estaban de alguna manera relacionados con el Monedero, por lo que ahora tenemos ese servicio en nuestro balance. ¿Por qué investigar cómo y qué funciona? El servicio está operativo, y tenemos características del producto que necesitamos implementar.

Como suele suceder,

Pero en algún momento nos damos cuenta de que el servicio deja de cumplir su función, algo se rompió, ¿qué hacer en esa situación? El servicio simplemente dejó de funcionar. Por completo. Y nos enteramos de esto, primero, por casualidad y, segundo, seis meses después. Así suele ser. Lo único que sabíamos era en qué máquinas virtuales estaba desplegado el servicio, dónde estaban sus códigos fuente, y nada más. Hacemos un git clone y nos sumergimos en los pensamientos de la persona que escribió esto hace unos años, pero ¿qué vemos? No hay nada del habitual Spring Boot, aunque estamos acostumbrados, ya que somos full stack y esas cosas. ¿Quizás hay Spring Framework? Pero no, no hay.

El chico que escribió todo esto era estricto y programaba todo en Java puro. No hay herramientas familiares para el desarrollador, y surge la idea: sería bueno reescribir todo esto. Tenemos microservicios, y desde cada tostadora se escucha el habitual "¡Chicos, los microservicios son lo que necesitan!". Si algo va mal, pueden tomar cualquier lenguaje y todo estará bien.

El asunto es que actualmente no tenemos un cliente que se encargue de este servicio. ¿Cuáles eran sus requisitos comerciales, qué debería hacer este servicio? Y el servicio está estrechamente integrado en sus procesos comerciales.

Ahora díganme, ¿qué tan fácil es reescribir un servicio sin conocer sus requisitos comerciales? No está claro cómo se está registrando el servicio, no se sabe si hay métricas. ¿Cuáles son, si es que las hay? Aún más desconocido. Además, hay una gran cantidad de clases con lógica comercial confusa. Algo se registra en alguna base de datos de la que tampoco sabemos nada.

¿Por dónde empezar?

Por lo más lógico: la existencia de pruebas. Generalmente, ahí hay alguna lógica escrita y se pueden hacer inferencias sobre lo que está sucediendo. Actualmente, TDD está de moda, pero vemos que hace 5 años todo era prácticamente igual que ahora: casi no hay pruebas unitarias, y no nos dirán nada en concreto. Bueno, excepto tal vez alguna verificación de cómo se firma algún xml con algún certificado personalizado.

No pudimos entender nada del código, así que decidimos revisar qué estaba pasando en la máquina virtual. Abrimos los registros del servicio y encontramos un error del cliente HTTP: un certificado autofirmado que estaba incrustado en los recursos de la aplicación había caducado sin piedad. Nos pusimos en contacto con nuestros analistas, pidieron un nuevo certificado, nos lo emitieron y el servicio volvió a funcionar. En apariencia, eso debería ser todo. ¿O no? De hecho, el servicio funciona, realiza una función que necesita nuestro negocio. Tenemos ciertos estándares de desarrollo de aplicaciones, que probablemente también tenga usted. Por ejemplo, no almacenar registros en el nodo dentro de una carpeta, sino en algún tipo de almacenamiento, como Elastic, y consultarlos en Kibana. También podríamos recordar las métricas doradas. Es decir, la carga en el servicio, la cantidad de solicitudes al servicio, si está vivo o no, cómo pasa su HealthCheck. Al menos, estas métricas ayudarán a saber cuándo se puede retirar el servicio de manera tranquila y olvidar su existencia como un mal sueño.

¿Qué hacer?

Por lo tanto, añadimos este viejo servicio a la tabla y luego vamos a buscar entre los desarrolladores voluntarios que se encarguen del servicio y lo pongan en orden: que escriban al menos alguna información sobre el servicio, que añadan enlaces a los paneles en Grafana, a las tareas de compilación, que entiendan cómo desplegar la aplicación; no se puede simplemente subir archivos mediante FTP.

Lo principal: ¿cuánto tiempo tomará toda esta útil actividad de voluntariado? Un sprint para un desarrollador más o menos experimentado, por ejemplo, durante el 20% de la deuda técnica. ¿Y cuánto tiempo se ha gastado en entender toda la enraizada lógica de comunicación con algún sistema gubernamental, y actualizarla a tecnologías más nuevas? No puedo garantizarlo, tal vez un mes, o tal vez dos de trabajo del equipo. Lo digo por la experiencia de integración en la actualidad con algún nuevo servicio.

Sin embargo, no hay salida de valor empresarial alguna. Absolutamente ninguna. Tomar un servicio en soporte y dedicarle algo de tiempo es normal. Pero después de nuestros estándares habituales de trabajo con el servicio, lo añadimos a la tabla, se agregó información sobre él y, quizás, en algún momento lo reescribamos. Pero ahora cumple con nuestros estándares de operación de servicios.

Como conclusión, me gustaría proponer un plan sobre qué hacer con los servicios Legacy.

Reescribir el legado desde cero es una mala idea.
En serio, ni siquiera hay que pensarlo. Es claro que hay preferencias, y hay algunas ventajas, pero generalmente, a nadie le importa, incluyendo a ustedes mismos.

Guía
Revise los códigos fuente de sus aplicaciones, haga una guía que indique qué hay y dónde está, además de cómo funciona. También incluya una descripción del proyecto (el correspondiente readme.md) para que quien se encargue de esto después de ustedes pueda entender rápidamente dónde se encuentran los registros y las métricas. El desarrollador que se haga cargo solo les dará las gracias.

Entienda el dominio
Si posee algún dominio, trate de estar al tanto. Puede sonar obvio, sí, pero no todos se aseguran de que los servicios estén alineados. En realidad, trabajar bajo un mismo estándar es mucho más sencillo.

Solo los usuarios registrados pueden participar en la encuesta. Inicie sesión, por favor.