Migrando para a arquitetura de microsserviço





Em vez de apresentar



Vários meses se passaram desde o lançamento dos primeiros microsserviços. E agora, em nossa opinião, é hora de contar a experiência adquirida.



De imediato, vale a pena fazer uma reserva sobre o que estará neste artigo e o que não estará no artigo. O artigo não descreverá soluções e descrições arquitetônicas com a justificativa para essas decisões. Não vamos nos concentrar na pilha de tecnologia na qual criamos microsserviços.



O foco principal do artigo será nos problemas globais que nossa equipe enfrentou ao longo do projeto.



Este artigo será o primeiro de muitos. E seu objetivo, em primeiro lugar, é introduzir em nossos problemas no contexto da transição para uma arquitetura de microsserviço e conduzir suavemente aos seguintes tópicos, que revelam em detalhes certos aspectos da transição.



Como tudo começou



A decisão de mudar para uma arquitetura de microsserviço foi tomada há cerca de um ano e meio. Nosso desafio era nos prepararmos para o rápido crescimento de nossa empresa. Tínhamos que nos tornar mais flexíveis em termos de soluções técnicas, aumentar a velocidade de fazer mudanças e, claro, aumentar a resiliência de nossos sistemas. 



Depois que a decisão de mudar para uma arquitetura de microsserviço foi tomada, uma unidade separada foi criada por profissionais experientes e proativos. O fator determinante para considerar um candidato à transferência para um novo departamento foi o alto conhecimento em um ou mais sistemas de informação existentes.







Como não havia um entendimento claro da frente de trabalho naquela época, a equipe foi formada de forma espontânea. Mas, ao mesmo tempo, o princípio da autossuficiência já estava sendo estabelecido - desenvolvedores, analistas e testadores na equipe deveriam ter o seu próprio.



Dois caminhos foram escolhidos ao mesmo tempo como estratégia para mudar para microsserviços:



  1. colocamos em microsserviços o que (como pensamos) é mais fácil de remover;
  2. trazemos para os microsserviços aquele cuja transferência para microsserviços resolve a maioria dos problemas para os negócios e TI.


A primeira forma era boa porque no processo a equipe adquiria os conhecimentos necessários e preenchia sua mão, aumentando assim sua eficiência para o trabalho posterior. O segundo caminho foi proporcionar uma espécie de vitória rápida para a equipe, mostrando o acerto da decisão escolhida de mudar para microsserviços para a empresa e motivando a equipe para novas façanhas.



A equipe estava no início da jornada. Foi uma época feliz: o futuro parecia brilhante e sem nuvens, e parecia que tínhamos um plano.



Primeiras dificuldades



E, claro, já que estamos falando sobre microsserviços, não podemos deixar de falar sobre monólitos. Estes são os nossos principais sistemas de informação.







A arquitetura de nossos sistemas individuais é melhor ilustrada por esta foto tirada do artigo de Stefan Tilkov "Não comece com um monólito". Como podemos ver, os blocos funcionais no monólito estão extremamente relacionados uns com os outros. Esse é um sério obstáculo ao processo de transferência de uma funcionalidade separada para um microsserviço. 



Para referência, nossos monólitos têm cerca de 13 anos e a base de código do monólito média tem cerca de 1,2 milhão de linhas.



Em outras palavras, a equipe enfrentou os seguintes problemas repetidamente:



  • processo extremamente demorado de análise da funcionalidade existente;
  • frequentemente falta de compreensão do que exatamente estamos trazendo para o microsserviço;
  • a complexidade de integrar o monólito com o novo microsserviço.


Considerando que, além de resolver esses problemas, a equipe também precisava aumentar a expertise em uma nova pilha e uma nova abordagem de design, o progresso não foi muito rápido.



No entanto, alguns meses depois, a equipe começou a mostrar os primeiros resultados - os primeiros microsserviços forneciam suas APIs de maneira amigável para todos. A equipe acreditou em si mesma e tinha certeza de que estava fazendo tudo certo. Bem, muitas coisas em nossa vida são bastante ilusórias.



Primeiros sucessos e novas dificuldades







Apesar das primeiras dificuldades, a equipe recebeu novas experiências e primeiros resultados. Mas surgiram alguns riscos não contabilizados, impedindo o lançamento de microsserviços.



  • Descobriu-se que os monólitos não estavam prontos para funcionar com a nova pilha e a integração foi atrasada.
  • - .
  • , , , , .


Os primeiros dois problemas foram resolvidos de forma bastante simples - escrevendo clientes separados para integrar o monólito e o microsserviço e ajustando a funcionalidade do monólito de acordo. Mas o terceiro problema não foi totalmente resolvido até hoje.



A inconsistência de recursos foi parcialmente resolvida por meio do agendamento colaborativo de recursos. Parecia que a equipe levou em consideração todos os seus erros, havia uma compreensão do que e como fazer corretamente e, no início de 2020, cerca de uma dúzia de microsserviços foram escritos (alguns acabaram não sendo microsserviços) aguardando integração e lançamento em produção. Eles abordaram com sua funcionalidade a maioria dos processos críticos para os negócios, como calcular o custo e o tempo de entrega, trazer novas regiões e escritórios para o site de vendas, pesquisar e selecionar mercadorias, etc.



Seguimos em frente com confiança, já tendo uma experiência sólida e tendo preenchido muitos obstáculos. Parecia que estávamos enfrentando todas as armadilhas, e agora resta apenas deliberadamente, passo a passo, implementar nosso plano. 



Bem…



Quarentena, explorações de trabalho e, finalmente, sucesso



O início do ano fez ajustes significativos em nossos planos, e isso se deve às consequências do novo coronavírus que se espalhou na época. Obviamente, não há necessidade de explicar o que está em jogo: todo mundo já sabe muito sobre o assunto.



O início da pandemia e a crise econômica que a acompanhou forçaram nossa empresa a reconsiderar ligeiramente suas prioridades de desenvolvimento. E, como resultado, as prioridades de TI mudaram - novas tarefas foram definidas, projetadas para refazer rapidamente os processos de negócios para se adequar a novas realidades.



As mudanças também afetaram os planos de microsserviços. Devido à realocação de recursos, a integração de microsserviços com monólitos e, consequentemente, o lançamento dos próprios microsserviços foram novamente adiados.



Aqui, por fim, é necessário nos determos com mais detalhes sobre o que estava acontecendo na equipe e como a equipe se sentia.







Primeiro, desmotivação. Devido à falta de um resultado sólido por muito tempo, e não havia microsserviços totalmente prontos e integrados em produção por quase um ano, a equipe estava moralmente esgotada (contra este prazo, mas mesmo assim). A eficiência diminuiu muito. Não sem colapsos emocionais raros, mas vívidos.





Em segundo lugar, quarentena e uma transição completa para o controle remoto. Claro, temos uma vasta experiência em trabalhar remotamente: quase ⅔ dos desenvolvedores são trabalhadores remotos. Mas todos os que trabalharam em microsserviços trabalharam juntos no mesmo escritório, e a transição para o trabalho remoto não afetou da melhor maneira a eficácia da equipe. Por um lado, o fato de que demorou para se reestruturar e passar para um novo formato de trabalho. Por outro lado, foi durante o período de diminuição da motivação da equipe que foi necessária mais comunicação pessoal e apoio mútuo dentro da equipe.



Em terceiro lugar, a equipe precisava mostrar o resultado. Na verdade, toda a equipe, apesar dos problemas internos e externos, entendeu claramente: o destino posterior de toda a empresa depende da rapidez com que podemos espremer nossos objetivos para um resultado sólido. Muitos em nossa empresa estavam prontos para admitir a experiência de mudar para microsserviços como inoportuna, malsucedida e para encerrar o departamento.



Por quase dois meses, a equipe trabalhou de 12 a 15 horas, geralmente sete dias por semana. E ela conseguiu atingir o objetivo desejado - quatro microsserviços, totalmente funcionais e totalmente integrados com sistemas monolíticos, entraram em produção total de uma só vez. 



É importante notar que não usamos nenhuma técnica complicada para motivar a equipe, não há know-how para compartilhar. É que dia após dia a equipe fez o seguinte:



  • chamadas frequentes do Skype com atualização do status atual do trabalho e resolução imediata de problemas emergentes;
  • mantendo uma atitude positiva na equipe com verificação constante do estado de recursos de cada um.


Como um resultado



Em vez de uma conclusão, gostaria de me debruçar sobre as conclusões que tiramos para nós mesmos ...



  • Equipes cruzadas. Para implementar com sucesso projetos tão ambiciosos, deve haver uma equipe totalmente dedicada e autônoma com recursos suficientes para resolver qualquer problema. Em nosso caso, isso significa que a equipe de criação de microsserviços em uma nova pilha deve ter membros das equipes de desenvolvimento do monolith. Se tivéssemos entendido isso antes e pudéssemos levar essa ideia até o fim, isso teria nos permitido evitar erros associados a conhecimentos insuficientes em processos de negócios e inconsistência de recursos para a integração de microsserviço e monólito.


imagem1

  • . , , . . , , , , . .
  • . , . .


Agora, tendo feito o trabalho sobre os erros, podemos dizer com segurança: a experiência, que começou há quase um ano e meio, pode ser considerada um sucesso. E agora, da categoria de apenas um experimento, o projeto de transição para uma arquitetura de microsserviço está se tornando uma das principais estratégias de TI em nossa empresa.



No futuro, retornaremos a este tópico e falaremos com mais detalhes sobre a pilha de tecnologia, soluções individuais e muito mais. Nós acumulamos bastante material e experiência.



All Articles