Há quatro anos, uma base de clientes era mantida separadamente em cada loja, além de outra no site.
Na série anterior: há três anos, decidimos que precisávamos fazer nosso desenvolvimento na Rússia. Dois anos atrás, eles começaram a escrever seu próprio código, em vez de modificar o código da bifurcação da empresa-mãe. A história de hoje será sobre como mudamos de um grande monólito Legado para um monte de pequenos microsserviços conectados por um tipo de ônibus (orquestrador).
O caso mais fácil para o usuário: faça um pedido pelo site e pegue na loja real Leroy Merlin na Rússia. Anteriormente, os pedidos da loja on-line eram processados em outro aplicativo em geral e de acordo com um esquema diferente. Agora, precisávamos de uma vitrine omnichannel para que qualquer pedido fosse dividido em uma interface: um caixa em uma loja, um aplicativo móvel, um terminal em uma loja, um site - qualquer que seja. Se você colocar o Linux no microondas, deixe-o estar. O principal é que algumas interfaces podem bater na API para trás e dizer que aqui você precisa fazer esse e aquele pedido. E eles receberam uma resposta clara para isso. A segunda história foi com pedidos de disponibilidade e propriedades das mercadorias do cartão.
Na frente (escreveremos sobre isso em breve), temos um monstro - AEM, e atrás dele havia duas grandes aplicações: OPUS e MoVe. O primeiro é um banco de dados das propriedades de cada produto (das dimensões à descrição), o segundo é responsável pelo checkout, ou seja, o monólito do caixa. Se bastante simplificado.
O que havia de errado com o Opus?
O OPUS é uma grande base distribuída. Mais precisamente, este é um software que fornece uma interface para acessar o banco de dados, ou seja, ele acessa o banco de dados e, por exemplo, pesquisa ou simplesmente define a API para que os clientes não acessem diretamente o banco de dados. Este software funciona e é suportado na França. A segunda característica,
como já dissemos , é que a linha de melhorias é muito longa e não temos a maior prioridade em comparação com a unidade de negócios da França.
Com muita dificuldade, pudemos entender como os desenvolvedores poderiam fazer alterações sem uma equipe da França; aprovações muito longas ocorreram. Recurso lançado por seis meses. Na verdade, a princípio, queríamos fazer nosso próprio desenvolvimento e sua revisão, e depois chegamos ao nosso próprio desenvolvimento, nossa infraestrutura, nossos testes e, em geral, o nosso. E, ao mesmo tempo, jogou fora quase um terço do código legado.
Mas voltando ao OPUS. Como o sistema armazena informações relevantes sobre a disponibilidade, características, transações e outras coisas, nós o utilizamos por qualquer motivo. Especificamente para o site, isso significava que, se o usuário tiver três produtos na cesta, será necessário bater no banco de dados de cada página, porque a relevância é verificada. Mesmo se você bater uma vez no cache e atualizá-lo de forma inteligente, ainda havia recursos. Quando você abre a página do catálogo em geral, todas as especificações do produto foram obtidas do OPUS.
O próximo passo lógico é que começamos a extrair OPUS com menos frequência e criamos nossa base (mais precisamente, microsserviços com bases). O sistema como um todo foi chamado de PUB russo.
Então eles fizeram uma orquestra, que já pode armazenar agregados, ou seja, os dados coletados para a criação de páginas. No sentido em que, quando o usuário alterna a visualização da página de cartões para listas, ainda é o mesmo agregado, apenas a frente é diferente.
Ou seja, deixamos o OPUS original (ainda está na França), mas nosso espelho “quase completo” “suga”, que corta a base em pedaços, pronta para montagem em uma orquestra. E o orquestrador coleta e armazena os agregados (ou os recebe rapidamente e começa a armazená-los), de que outros sistemas precisam. Como resultado, esta parte funciona como deveria. Da funcionalidade original do OPUS francês, restam cerca de cinco por cento. Em breve iremos substituí-lo completamente.
O que havia de errado com o MoVe?
Nada de especial, exceto pelo fato de termos decidido jogar fora todo o código, porque:
- Era antigo em uma pilha velha.
- Ele levou em consideração as características de cada região "Leroy Merlin" na cadeia de FIs.
- Era tão difícil ler e manter que o melhor método de refatoração era "escrever novamente e imediatamente documentar normalmente".
O que nós fizemos. Somente o reescrevemos não como um monólito, mas começamos a fazer microsserviços para cada função individual ao redor. E então parte da funcionalidade do MoVe com a mudança para o microsserviço foi removida sem problemas. E assim - um por um, até a funcionalidade do MoVe terminar completamente. Ou seja, ele ainda funciona, mas em algum lugar no vácuo e sem fluxos de dados.
Desde que construímos a plataforma a partir de peças, o projeto recebeu o nome de Lego.
Lego mudou completamente este meio. Sim, vamos esclarecer: um back-end real é um barramento herdado, sistemas de arquivos, bancos de dados e outros quase em nível de infraestrutura. Grandes aplicativos em torno disso e microsserviços da lógica são intermediários. A apresentação já é a frente.
Por que você precisou reescrever tudo isso?
Porque vivemos com bases de clientes separadas para cada instância, 15 anos após a abertura na Rússia, e isso não serviu para ninguém. Também não houve sincronização. Em outros países, eles ainda vivem assim.
A matriz da França fez a logística geral, reutilizamos o sistema Pixis - trata-se de uma única loja de recebimentos, ou seja, pedidos de clientes: uma loja vê os pedidos de outra loja. Mas isso não resolveu completamente o problema de pedidos omnichannel. Portanto, era necessário consolidar a base e fazer o processamento geral. Esta é a principal coisa.
O segundo motivo foi a lei federal das bilheterias: com nossos prazos de desenvolvimento para um sistema comum (e testes) para todos os países, teríamos multado por multas.
Uma opção aproximadamente semelhante foi lançada no Brasil: eles começaram a Leroy Merlin lá sem nenhum software da controladora e tiveram sucesso. Isso foi antes da decisão dividida. A propósito, eles se comprometem muito com os
innersors , eles têm um desenvolvimento muito rápido.
Pixis permitiu fazer um pedido apenas na caixa registradora, na verdade. Mudamos a situação em três etapas:
- Primeiro, fizemos um aplicativo móvel para o funcionário, o que simplifica bastante sua vida. Com base nisso, eles começaram a construir um ecossistema em que as interfaces são separadas pela lógica.
- Enquanto tudo estava pronto, os pedidos pela Internet eram levados à mesa de caixa manualmente.
- Eles colocaram microsserviços, que substituíram tudo no meio.
Por que você precisou começar com o aplicativo da loja? Porque, novamente, temos processos únicos em comparação com a França. Por exemplo, uma pessoa decidiu comprar seis metros e dez centímetros de uma corrente em uma loja. O vendedor o interrompeu, deu um documento por quanto tempo e quanto custa. Você vai ao caixa com este pedaço de papel e paga lá. Do ponto de vista da lógica, a venda não deve ser nas bilheterias, mas o vendedor deve tê-la, mas, de fato, é nas bilheterias que começa a coisa mais interessante: você precisa ter as mercadorias e o papel.
No final, seremos uma plataforma para fazer pedidos: agora, por exemplo, no topo de nosso sistema principal, foram adicionados serviços de compra de mestres (comprei uma cozinha - pedi a instalação de um mestre externo, mas a encontramos e garantimos a nós mesmos),
mercado ( compra direta de um fornecedor em uma faixa mais ampla) e logo deve haver um afiliado para que nossos blocos possam ser colocados em qualquer lugar. Algo como incorporar lojas da Amazon em blogs, apenas mais versátil.
Como foi tomada a decisão de substituição?
Eu passo. Refine o modelo de negócios.Verificamos e, de fato: o modelo, como na Rússia - preços baixos todos os dias - é bem-sucedido. A Leroy Merlin na Europa é significativamente mais cara, mas é na Rússia que este é o nosso nicho: uma loja de construção onde você pode encontrar mercadorias com o melhor preço.
II passo. Crie um script de cliente.Ou seja, criar processos como queremos que eles interajam conosco do ponto de vista do cliente. Ou seja, uma visão única de quem queremos ser daqui a alguns anos e como ela se parece do ponto de vista da arquitetura.
III passo. Construa uma arquitetura.Divida essa visão em TK e arquitetura específicas com mais detalhes. Foram 110 projetos, divididos em cinco categorias por cinco anos.
Então eles formaram equipes especializadas. Na maioria das vezes, essas pessoas são seu pessoal e um contratado. A princípio, eles sofreram muito com isso: quando foram ao prod, eles realmente não entenderam como digerir um volume tão grande de alterações. Então eles começaram a fazer uma abordagem comum para as tarefas e aumentar gradualmente a parcela de seu desenvolvimento.
Nos lugares em que o erro era crítico, eles trabalhavam de acordo com os esquemas da NASA, onde o erro é inaceitável, não é uma opção. Isso é tudo sobre transações em dinheiro.
E onde era possível cair, o principal era levantar-se rapidamente, usamos uma abordagem próxima ao SRE do Google. Iterativamente, com batentes, mas os projetos podem ser implementados o mais rápido possível. E agora estamos fazendo muito, e é muito legal desenvolver.
A terceira abordagem é a inovação. Desenvolvemos um sandbox de idéias para fazer rapidamente os primeiros MVPs com nossos recursos internos, o que nos permite testar de forma rápida e barata. Este é o verdadeiro "tente rápido, falhe rápido". Isso permitiu que você obtivesse um orçamento e autoridade para aqueles que criaram um projeto interessante.
O segundo foco importante estava no geodesenvolvimento. Em seguida, abriu 20 lojas por ano (agora um pouco mais lento). Seis mil funcionários. Muitas regiões. Era necessário reescrever toda a cadeia de suprimentos, desenvolver rapidamente processos para elevar a infraestrutura das lojas.
Em 2017, decidimos nos tornar uma plataforma para pedidos de construção: essa é uma estratégia promissora nos próximos anos.
Para a geografia, precisávamos de um grande escritório de TI para o crescimento da empresa e o crescimento da cadeia de suprimentos. Para omnichannel (ordem geral) - um nível diferente de SLA para sistemas internos, tempo real, microsserviços e sincronização entre centenas de subsistemas. Geralmente, esse é um nível diferente de maturidade de TI. Para a plataforma, a velocidade da mudança também é importante.
Quando estava começando, todos pensavam que o ágil salvaria o mundo. Com os contratados, o ágil pode não ser tão eficaz. Daí o desejo de
recrutar 200 pessoas no departamento de TI.
Observamos com que rapidez podemos implementar tudo sem perda para a marca. Algo poderia ser escrito rapidamente, mas não havia tempo para preparar o serviço. Por exemplo, se não houver informações sobre o estoque, não há como pagar on-line sem a garantia de que as mercadorias serão reservadas. Nós decompusemos a cadeia de interdependências em várias. Agora já sabemos que precisamos reduzir os ciclos, porque as competências da equipe ainda são importantes. Agora estamos vendo recursos em pedaços pequenos, estamos coletando uma conexão, agora apenas o ano atual está nos planos. Uma estratégia de longo prazo, mas por recursos, tem no máximo um ano e muitas equipes de produtos separadas.