Hace cuatro años, una base de clientes se mantenía por separado en cada tienda, más otra en el sitio.
En la serie anterior: hace tres años, decidimos que necesitábamos hacer nuestro desarrollo en Rusia. Hace dos años, comenzaron a escribir su propio código en lugar de modificar el código fork de la empresa matriz. La historia de hoy será sobre cómo cambiamos de un gran monolito Legacy a un grupo de pequeños microservicios conectados por una especie de autobús (orquestador).
El caso de usuario más fácil: haga un pedido a través del sitio y recójalo en la tienda real de Leroy Merlin en Rusia. Anteriormente, los pedidos de la tienda en línea se procesaban en otra aplicación en general y de acuerdo con un esquema diferente. Ahora necesitábamos un escaparate omnicanal para que cualquier pedido se dividiera en una interfaz: un cajero en una tienda, una aplicación móvil, un terminal en una tienda, un sitio web, lo que sea. Si pones Linux en el microondas, deja que esté el microondas. Lo principal es que algunas interfaces pueden golpear la API hacia atrás y decir que aquí debe realizar tal y tal orden. Y recibieron una respuesta clara a esto. La segunda historia fue con solicitudes de disponibilidad y propiedades de los bienes de su tarjeta.
En el frente (escribiremos sobre esto pronto), tenemos un monstruo: AEM, y detrás de él en la parte posterior había dos grandes aplicaciones: OPUS y MoVe. El primero es una base de datos de las propiedades de cada producto (desde las dimensiones hasta la descripción), el segundo es responsable del pago, es decir, el monolito de la caja. Si muy simplificado.
¿Qué le pasaba a Opus?
OPUS es una gran base distribuida. Más precisamente, es un software que proporciona una interfaz para acceder a la base de datos, es decir, accede a la base de datos y, por ejemplo, busca o simplemente expone la API para que los clientes no vayan directamente a la base de datos. Este software funciona y es compatible con Francia. La segunda característica,
como ya dijimos , es que la línea de mejoras es muy larga y no tenemos la máxima prioridad en comparación con la unidad de negocios de Francia.
Con gran dificultad, pudimos entender cómo los desarrolladores podían hacer cambios sin un equipo de Francia; se obtuvieron aprobaciones muy largas. Característica lanzada durante seis meses. En realidad, al principio queríamos hacer nuestro propio desarrollo y su revisión, y luego llegamos a nuestro propio desarrollo, nuestra infraestructura, nuestras pruebas y, en general, las nuestras. Y al mismo tiempo arrojó casi un tercio del código Legacy.
Pero volvamos a OPUS. Dado que el sistema almacena información relevante sobre la disponibilidad, características, transacciones y otras cosas, recurrimos a ella por cualquier motivo. Específicamente para el sitio, esto significa que si el usuario tiene tres productos en la cesta, entonces debe llamar a la base de datos desde cada página, porque se verifica la relevancia. Incluso si toca una vez el caché, y luego lo actualiza de manera inteligente, todavía había características. Cuando abre la página del catálogo en general, todas las especificaciones del producto se tomaron de OPUS.
El siguiente paso lógico es que comenzamos a extraer OPUS con menos frecuencia e hicimos nuestra base (más precisamente, microservicios con bases). El sistema en su conjunto se llamaba PUB ruso.
Luego formaron una orquesta, que ya puede almacenar agregados, es decir, los datos recopilados para la creación de páginas. En el sentido de que cuando el usuario cambia la vista de página de tarjetas a listas, sigue siendo el mismo agregado, solo el frente es diferente.
Es decir, dejamos el OPUS original (todavía está en Francia), pero nuestro espejo casi completo lo "chupa", lo que corta la base en pedazos, listo para ensamblar en una orquesta. Y el orquestador recoge y almacena los agregados (o los recibe rápidamente y comienza a almacenarlos), que otros sistemas necesitan. Como resultado, esta parte funciona como debería. De la funcionalidad original del OPUS francés, queda alrededor del cinco por ciento. Pronto lo reemplazaremos por completo.
¿Qué estaba mal con MoVe?
Nada especial, excepto por el hecho de que decidimos tirar todo el código, porque:
- Era antiguo en una vieja pila.
- Tomó en cuenta las características de cada región "Leroy Merlin" en la cadena de FI.
- Era tan difícil de leer y mantener que el mejor método de refactorización era "escribir de nuevo e inmediatamente documentar normalmente".
Lo cual hicimos. Solo que lo reescribimos no como un monolito, sino que comenzamos a hacer microservicios para cada función individual. Y luego, parte de la funcionalidad de MoVe con el cambio al microservicio se eliminó sin problemas. Y así, uno por uno, hasta que la funcionalidad de MoVe termine por completo. Es decir, todavía funciona, pero en algún lugar en el vacío y sin flujos de datos.
Desde que construimos la plataforma a partir de piezas, el proyecto se llamó Lego.
Lego cambió por completo este medio. Sí, aclaremos: un back-end real es un bus heredado, sistemas de archivos, bases de datos y otros niveles casi de infraestructura. Las grandes aplicaciones en torno a esto y los microservicios de lógica son intermedios. La presentación ya es el frente.
¿Por qué necesitabas reescribir todo esto?
Porque vivíamos con bases de clientes separadas para cada instancia, 15 años después de la apertura en Rusia, y esto no le convenía a nadie. Tampoco hubo sincronización. En otros países todavía viven así.
La empresa matriz de Francia hizo la logística general, reutilizamos el sistema Pixis: esta es una sola tienda de recibos, es decir, pedidos de clientes: una tienda ve los pedidos de otra tienda. Pero esto no resolvió por completo el problema del orden omnicanal. Por lo tanto, era necesario consolidar la base y hacer el procesamiento general. Esto es lo principal.
La segunda razón fue la ley federal de taquilla: con nuestros plazos de desarrollo para un sistema común (y pruebas) para todos los países, habríamos multado con multas.
Una opción aproximadamente similar se introdujo en Brasil: comenzaron Leroy Merlin allí sin ningún software de la empresa matriz, y tuvieron éxito. Eso fue antes de la decisión dividida. Por cierto, se comprometen mucho con los
innersors , tienen un desarrollo muy rápido.
Pixis solo podía hacer un pedido desde la caja registradora, de hecho. Cambiamos la situación en tres etapas:
- Primero creamos una aplicación móvil para el empleado, que simplifica enormemente su vida. Sobre esta base, comenzaron a construir un ecosistema donde las interfaces se separan con lógica.
- Mientras todo estaba configurado, los pedidos por Internet se llevaban a la caja a mano.
- Pusieron microservicios a su vez, lo que lo reemplazó todo en el medio.
¿Por qué necesitabas comenzar con la aplicación de la tienda? Porque nuevamente tenemos procesos únicos en comparación con Francia. Por ejemplo, una persona decidió comprar seis metros y diez centímetros de una cadena en una tienda. El vendedor lo interrumpió, le dio un documento de cuánto tiempo es y cuánto cuesta. Vas al cajero con este papel y pagas allí. Desde el punto de vista de la lógica, la venta no debe realizarse en la taquilla, sino que el vendedor debe tenerla, pero de hecho es en la taquilla donde comienza lo más interesante: debe tener tanto los productos como el papel.
Al final, vamos a ser una plataforma para hacer pedidos: ahora, por ejemplo, encima de nuestro sistema principal, se agregaron servicios para comprar servicios de maestros (compré una cocina, ordené la instalación de un maestro externo, pero lo encontramos y nos garantizamos),
mercado ( compra directa de un proveedor en un rango más amplio), y pronto debe haber un afiliado para que nuestros bloques se puedan colocar en cualquier lugar. Algo así como incrustar tiendas de Amazon en blogs, solo que más versátil.
¿Cómo se tomó la decisión de reemplazo?
Yo paso Refinar el modelo de negocio.Verificamos, y de hecho: el modelo, como en Rusia, precios bajos todos los días, es exitoso. Leroy Merlin en Europa es significativamente más caro, pero es en Rusia donde este es nuestro nicho: una tienda de construcción donde definitivamente puedes encontrar productos al mejor precio.
II paso. Crea un script de cliente.Es decir, construir procesos como queremos que interactúen con nosotros desde el punto de vista del cliente. Es decir, una visión única de quiénes queremos ser en unos años y cómo se ve desde el punto de vista de la arquitectura.
III paso. Construye una arquitectura.Divide esta visión en conocimientos y arquitectura específicos con mayor detalle. Resultó 110 proyectos, que dividimos en cinco categorías durante cinco años.
Luego formaron equipos especializados. Muy a menudo, estas son sus personas más un contratista. Al principio, sufrieron mucho de esto: cuando fueron a la producción, realmente no entendieron cómo digerir un volumen tan grande de cambios. Luego comenzaron a hacer un enfoque común para las tareas y a aumentar gradualmente la parte de su desarrollo.
En aquellos lugares donde el error fue crítico, trabajaron de acuerdo con los esquemas de la NASA, donde el error es inaceptable, no es una opción en absoluto. Esto se trata de transacciones de dinero.
Y donde era posible caer, lo principal era levantarse rápidamente, utilizamos un enfoque cercano al SRE de Google. Iterativamente, con jambas, pero los proyectos podrían implementarse lo antes posible. Y ahora estamos haciendo mucho, y es muy bueno desarrollarlo.
El tercer enfoque es la innovación. Desarrollamos una caja de arena de ideas para hacer rápidamente los primeros MVP con nuestros recursos internos, lo que nos permite realizar pruebas de forma rápida y económica. Este es el verdadero "intentar rápido, fallar rápido". Esto le permitió obtener un presupuesto y autoridad para aquellos que crearon un proyecto genial.
El segundo foco importante estaba en el geodesarrollo. Luego abrió 20 tiendas al año (ahora un poco más lento). Seis mil empleados. Muchas regiones. Era necesario reescribir toda la cadena de suministro, para desarrollar rápidamente procesos para elevar la infraestructura de las tiendas.
En 2017, decidimos convertirnos en una plataforma para pedidos de construcción: esta es una estrategia prometedora para los próximos años.
Para la geografía, necesitábamos una gran oficina administrativa de TI para el crecimiento de la empresa y el crecimiento de la cadena de suministro. Para omnicanal (orden general): un nivel diferente de SLA para sistemas internos, en tiempo real, microservicios y sincronización entre cientos de subsistemas. Este es generalmente un nivel diferente de madurez de TI. Para la plataforma, la velocidad de cambio también es importante.
Cuando recién comenzaba, todos pensaban que ágil salvaría al mundo. Con los contratistas, ágil puede no ser tan efectivo. De ahí el deseo de
reclutar 200 personas en el departamento de TI.
Vimos cuán rápido podemos implementar todo sin pérdida para la marca. Algo podría escribirse rápidamente, pero no tuvo tiempo para preparar el servicio. Por ejemplo, si no hay información de existencias, entonces no hay forma de pagar en línea sin una garantía de que los bienes serán reservados. Descomponemos la cadena de interdependencias en varias. Ahora ya sabemos que debemos acortar los ciclos, porque las competencias del equipo siguen siendo importantes. Ahora estamos cortando características en piezas pequeñas, estamos recopilando una conexión, ahora solo el año actual está en los planes. Una estrategia a largo plazo, pero por características, es de un año como máximo, y muchos equipos de productos separados.