En lugar de presentar
Han pasado varios meses desde el lanzamiento de los primeros microservicios. Y ahora, en nuestra opinión, es el momento de contar la experiencia adquirida.
Vale la pena hacer una reserva de inmediato sobre lo que estará en este artículo y lo que no estará en el artículo. El artículo no describirá soluciones arquitectónicas y descripciones que justifiquen estas decisiones. Tampoco nos centraremos en la pila de tecnología en la que construimos microservicios.
El enfoque principal del artículo estará en los problemas globales que nuestro equipo enfrentó a lo largo del proyecto.
Este artículo será el primero de muchos. Y su objetivo, en primer lugar, es introducir nuestros problemas en el contexto de la transición a una arquitectura de microservicio y conducir sin problemas a los siguientes temas, que revelan en detalle ciertos aspectos de la transición.
Cómo todo empezó
La decisión de cambiar a una arquitectura de microservicio se tomó hace aproximadamente un año y medio. Nuestro desafío fue prepararnos para el rápido crecimiento de nuestra empresa. Tuvimos que ser más flexibles en términos de soluciones técnicas, aumentar la velocidad de hacer cambios y, por supuesto, aumentar la resiliencia de nuestros sistemas.
Después de que se tomó la decisión de cambiar a una arquitectura de microservicio, se creó una unidad separada a partir de personas experimentadas y proactivas. El factor determinante para considerar a un candidato para el traslado a un nuevo departamento fue la alta experiencia en uno o varios sistemas de información existentes.
Dado que no había una comprensión clara del frente de trabajo en ese momento, el equipo se formó de manera algo espontánea. Pero al mismo tiempo, ya se estaba estableciendo el principio de autosuficiencia: los desarrolladores, analistas y probadores del equipo deberían tener el suyo.
Se eligieron dos rutas a la vez como estrategia para cambiar a microservicios:
- sacamos en microservicios lo que (como pensamos) es más fácil de sacar;
- Traemos a los microservicios aquel cuya transferencia a microservicios resuelve la mayoría de los problemas tanto para las empresas como para las TI.
La primera forma era buena porque en el proceso el equipo adquiriría la pericia necesaria y ocuparía su mano, aumentando así su eficiencia para el trabajo posterior. La segunda forma fue proporcionar una especie de victoria rápida para el equipo, mostrando la exactitud de la decisión elegida de cambiar a microservicios para la empresa y motivando al equipo para nuevas hazañas.
El equipo estaba al comienzo del viaje. Fue una época feliz: el futuro parecía brillante y despejado, y nos pareció que teníamos un plan.
Primeras dificultades
Y, por supuesto, dado que estamos hablando de microservicios, no podemos evitar hablar de monolitos. Estos son nuestros principales sistemas de información.
La arquitectura de nuestros sistemas individuales se ilustra mejor con esta imagen tomada del artículo de Stefan Tilkov "No empieces con un monolito". Como podemos ver, los bloques funcionales en el monolito están extremadamente relacionados entre sí. Este es un serio obstáculo para el proceso de transferir una funcionalidad separada a un microservicio.
Como referencia, nuestros monolitos tienen aproximadamente 13 años y el código base promedio del monolito es de aproximadamente 1.2 millones de líneas.
En otras palabras, el equipo enfrentó los siguientes problemas una y otra vez:
- proceso extremadamente lento de analizar la funcionalidad existente;
- a menudo, falta de comprensión de qué es exactamente lo que incorporamos al microservicio;
- la complejidad de integrar el monolito con el nuevo microservicio.
Teniendo en cuenta que, además de resolver estos problemas, el equipo también necesitaba aumentar la experiencia en una nueva pila y un nuevo enfoque de diseño, el progreso no fue muy rápido.
Sin embargo, después de unos meses, el equipo comenzó a mostrar los primeros resultados: los primeros microservicios proporcionaron amigablemente sus API a todos. El equipo creía en sí mismo y sabía con certeza que lo estaban haciendo todo bien. Bueno, muchas cosas en nuestra vida son bastante ilusorias.
Primeros éxitos y nuevas dificultades
A pesar de las primeras dificultades, el equipo recibió tanto nueva experiencia como primeros resultados. Pero han surgido algunos riesgos no contabilizados que impiden el lanzamiento de microservicios.
- Resultó que los monolitos no estaban listos para trabajar con la nueva pila y la integración se retrasó.
- - .
- , , , , .
Los dos primeros problemas se resolvieron de manera bastante simple: escribiendo clientes separados para integrar el monolito y el microservicio y ajustando la funcionalidad del monolito en consecuencia. Pero el tercer problema no se ha resuelto completamente hasta el día de hoy.
La inconsistencia de los recursos se abordó parcialmente mediante la programación colaborativa de recursos. Parecía que el equipo tomó en cuenta todos sus errores, había un entendimiento de qué y cómo hacer correctamente, y a principios de 2020 se habían escrito alrededor de una docena de microservicios (algunos resultaron no ser microservicios en absoluto) esperando su integración y lanzamiento en producción. Cubrieron con su funcionalidad la mayoría de los procesos críticos para el negocio, como calcular el costo y el tiempo de entrega, traer nuevas regiones y oficinas al sitio de venta, buscar y seleccionar productos, etc.
Avanzamos con confianza, ya que tenemos una experiencia sólida y hemos llenado muchos baches. Parecía que nos enfrentamos a todas las trampas, y ahora solo queda deliberadamente, paso a paso, implementar nuestro plan.
Bien…
Cuarentena, explotación laboral y finalmente éxito
El comienzo del año hizo ajustes importantes en nuestros planes, y esto se debe a las consecuencias del nuevo coronavirus que se extendió en ese momento. Evidentemente, no es necesario explicar lo que está en juego: todo el mundo ya sabe mucho sobre este tema.
El estallido de la pandemia y la crisis económica que la acompañó obligaron a nuestra empresa a reconsiderar ligeramente sus prioridades de desarrollo. Y como resultado, las prioridades de TI cambiaron: se establecieron nuevas tareas, diseñadas para rehacer rápidamente los procesos comerciales para adaptarse a las nuevas realidades.
Los cambios también afectaron los planes de microservicios. Debido a la reasignación de recursos, la integración de microservicios con monolitos y, en consecuencia, la liberación de los propios microservicios se pospuso nuevamente.
Aquí, finalmente, es necesario detenerse en más detalle sobre lo que estaba sucediendo en el equipo y cómo se sentía el equipo.
Primero, desmotivación. Debido a la falta de un resultado sólido durante mucho tiempo, y no hubo microservicios completamente integrados y listos para usar en producción durante casi un año, el equipo estaba muy agotado moralmente (contra este término, pero no obstante). La eficiencia ha disminuido enormemente. No sin raras pero vívidas crisis emocionales.
En segundo lugar, la cuarentena y una transición completa al control remoto. Por supuesto, tenemos una gran experiencia en el trabajo a distancia: casi la cuarta parte de los desarrolladores son trabajadores remotos. Pero todos los que trabajaron en microservicios trabajaron juntos en la misma oficina, y la transición al trabajo remoto no afectó la efectividad del equipo de la mejor manera. Por un lado, el hecho de que tomó tiempo la reestructuración y la transición a un nuevo formato de trabajo. Por otro lado, fue durante el período de disminución de la motivación del equipo cuando se requirió más comunicación personal y apoyo mutuo dentro del equipo.
En tercer lugar, el equipo necesitaba mostrar el resultado. De hecho, todo el equipo, a pesar de los problemas internos y externos, lo entendió claramente: el futuro destino de toda la empresa depende de qué tan rápido podamos exprimir nuestros objetivos para obtener un resultado sólido. Muchos en nuestra empresa estaban dispuestos a admitir el experimento de cambiar a microservicios como inoportuno, fallido y disolver el departamento.
Durante casi dos meses, el equipo trabajó de 12 a 15 horas, a menudo los siete días de la semana. Y pudo lograr el objetivo deseado: cuatro microservicios, en pleno funcionamiento y completamente integrados con sistemas monolíticos, entraron en plena producción a la vez.
Es importante tener en cuenta que no utilizamos ninguna técnica engañosa para motivar al equipo, no hay conocimientos para compartir. Es solo que día tras día el equipo hizo lo siguiente:
- frecuentes llamadas de Skype con actualización del estado actual del trabajo y resolución rápida de problemas emergentes;
- manteniendo una actitud positiva en el equipo con un control constante del estado de los recursos de cada uno.
Como resultado
En lugar de una conclusión, me gustaría detenerme en las conclusiones que hicimos por nosotros mismos ...
- Equipos cruzados. Para implementar con éxito proyectos tan ambiciosos, debe haber un equipo totalmente dedicado y autónomo con recursos suficientes para resolver cualquier problema. En nuestro caso, esto significa que el equipo que crea microservicios en una nueva pila debe tener miembros de los equipos de desarrollo de monolitos. Si hubiéramos entendido esto antes y pudiéramos llevar esta idea hasta el final, esto nos habría permitido evitar errores asociados con una experiencia insuficiente en los procesos comerciales y la inconsistencia de los recursos para la integración de microservicios y monolitos.
- . , , . . , , , , . .
- . , . .
Ahora, después de haber trabajado en los errores, podemos decir con confianza: el experimento, que comenzó hace casi un año y medio, puede considerarse un éxito. Y ahora, de la categoría de solo un experimento, el proyecto de transición a una arquitectura de microservicios se está convirtiendo en una de las estrategias clave de TI en nuestra empresa.
En el futuro, volveremos a este tema y hablaremos con más detalle sobre la pila de tecnología, las soluciones individuales y mucho más. Hemos acumulado suficiente material y experiencia.