Em 25 de abril, nós do Grupo Mail.ru realizamos uma conferência sobre nuvens e ao redor - . Alguns destaques:
- O principal — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center e Yandex.Cloud falaram sobre as especificidades do nosso mercado de nuvem e seus serviços;
- Colegas do Bitrix24 contaram como eles ;
- Leroy Merlin, Otkritie, Burger King e Schneider Electric forneceram interessantes — quais tarefas seus negócios definem para a TI e quais tecnologias, incluindo as de nuvem, eles consideram mais promissoras.
Você pode assistir a todos os vídeos da conferência mailto:CLOUD , e aqui você pode ler como foi a discussão sobre microsserviços. Alexander Deulin, chefe do centro de pesquisa e desenvolvimento de sistemas de negócios MegaFon, e Sergey Sergeev, diretor de tecnologia da informação do grupo M.Video-Eldorado, compartilharam seus casos de sucesso na eliminação de monólitos. Também discutimos questões relacionadas à estratégia de TI, processos e até RH.
Painelistas
- Sergey Sergeev, CIO do Grupo "M.Video-Eldorado";
- Alexandre Deulin, chefe do centro de pesquisa e desenvolvimento de sistemas de negócios MegaFon;
- Moderador — Dmitry Lazarenko, Chefe da direção de PaaS Soluções em nuvem Mail.ru.
Após o discurso de Alexander Deulin ele é acompanhado por Sergey Sergeev da M.Video-Eldorado e pelo moderador da discussão Dmitry Lazarenko, Mail.ru Cloud Solutions.
Abaixo preparamos uma transcrição da discussão para você, mas você também pode assistir ao vídeo:
A transição para microsserviços é uma resposta às necessidades do mercado
Dmitriy:
Você já teve alguma experiência bem-sucedida de migração para microsserviços? E, em geral: onde você vê o maior benefício comercial com o uso de microsserviços ou com a mudança de monólitos para microsserviços?
Sergey:
Já avançamos um pouco na transição para microsserviços e usamos essa abordagem há mais de três anos. A primeira necessidade que justificou a necessidade de microsserviços foi a integração infinita de vários produtos front-end com o back office. E cada vez fomos obrigados a fazer integração e desenvolvimento adicionais, implementando as nossas próprias regras para o funcionamento deste ou daquele serviço.
Em algum momento, percebemos que precisávamos agilizar o funcionamento de nossos sistemas e a saída de funcionalidades. Naquele momento, já existiam no mercado conceitos como microsserviços e abordagem de microsserviços e decidimos experimentá-los. Isso começou em 2016. Em seguida, a plataforma foi instalada e os primeiros 10 serviços foram implementados por uma equipe separada.
Um dos primeiros serviços, o mais carregado, foi o serviço de cálculo de preços. Cada vez que você chega a algum canal, ao grupo de empresas M.Video-Eldorado, seja site ou loja de varejo, seleciona um produto ali, vê o preço no site ou na “Cesta”, o custo é automaticamente calculado por um serviço. Por que isso é necessário: antes cada sistema tinha seus próprios princípios para trabalhar com promoções - com descontos e assim por diante. Nosso back office cuida dos preços; a funcionalidade de desconto é implementada em outro sistema. Isto precisava ser centralizado e um serviço único e separável criado na forma de um processo de negócios que nos permitisse implementar isso. Foi assim que começamos.
O valor dos primeiros resultados foi muito grande. Em primeiro lugar, conseguimos criar entidades separáveis que nos permitem trabalhar separadamente e de forma agregada. Em segundo lugar, reduzimos o custo de propriedade em termos de integração com mais sistemas.
Nos últimos três anos, adicionamos três sistemas de linha de frente. Era difícil mantê-los com a mesma quantidade de recursos que a empresa podia pagar. Surgiu assim a tarefa de procurar novas saídas, respondendo ao mercado em termos de rapidez, em termos de custos internos e de eficiência.
Como medir o sucesso da migração para microsserviços
Dmitriy:
Como é determinado o sucesso na migração para microsserviços? Qual foi o “antes” de cada empresa? Que métrica você usou para determinar o sucesso da transição e quem realmente a determinou?
Sergey:
Em primeiro lugar, nasceu dentro da TI como um facilitador – “desbloqueando” novas capacidades. Tínhamos a necessidade de fazer tudo mais rapidamente, relativamente pelo mesmo dinheiro, respondendo aos desafios do mercado. Agora o sucesso se expressa na quantidade de serviços reaproveitados por diferentes sistemas, unificação de processos entre si. Agora é, mas naquele momento foi uma oportunidade de criar uma plataforma e confirmar a hipótese de que podemos fazer isso, vai dar efeito e calcular o business case.
Alexandre:
O sucesso é antes um sentimento interno. As empresas sempre querem mais e a profundidade do nosso backlog é prova de sucesso. Parece-me que sim.
Sergey:
Sim eu concordo. Em três anos já contamos com mais de duzentos serviços e backlog. A necessidade de recursos dentro da equipe só cresce – 30% ao ano. Isso está acontecendo porque as pessoas sentiram: é mais rápido, é diferente, existem tecnologias diferentes, tudo isso está se desenvolvendo.
Os microsserviços virão, mas o núcleo permanecerá
Dmitriy:
É como um processo sem fim onde você investe no desenvolvimento. A transição para microsserviços para empresas já terminou ou não?
Sergey:
É muito fácil responder. O que você acha: substituir telefones é um processo sem fim? Nós próprios compramos telefones todos os anos. E aqui está: enquanto houver necessidade de rapidez, de adaptação ao mercado, algumas mudanças serão necessárias. Isso não significa que abandonemos as coisas padrão.
Mas não podemos cobrir e refazer tudo de uma vez. Temos serviços de integração padrão legados que existiam antes: barramentos corporativos e assim por diante. Mas há um atraso e também uma necessidade. O número de aplicativos móveis e suas funcionalidades estão crescendo. Ao mesmo tempo, ninguém diz que você receberá 30% a mais de dinheiro. Ou seja, sempre há necessidades por um lado e busca por eficiência por outro.
Dmitriy:
A vida está em boa forma. (risos)
Alexandre:
Em geral, sim. Não temos abordagens revolucionárias para remover a parte central da paisagem. Está em andamento um trabalho sistemático para decompor os sistemas para que sejam mais consistentes com a arquitetura de microsserviços, para reduzir a influência dos sistemas uns sobre os outros.
Mas pretendemos manter a parte central, pois no cenário da operadora sempre haverá algumas plataformas que compramos. Mais uma vez, precisamos de um equilíbrio saudável: não devemos apressar-nos a cortar o núcleo. Colocamos os sistemas lado a lado e agora descobrimos que já estamos no topo de muitas partes essenciais. Além disso, desenvolvendo a funcionalidade, criamos as representações necessárias para todos os canais que trabalham com os nossos serviços de comunicação.
Como vender microsserviços para empresas
Dmitriy:
Também estou interessado - para quem ainda não mudou, mas pretende fazê-lo: quão fácil foi vender esta ideia às empresas e foi uma aventura, um projecto de investimento? Ou foi uma estratégia consciente: agora vamos para microsserviços e pronto, nada vai nos parar. Como foi para você?
Sergey:
Não estávamos vendendo uma abordagem, mas um benefício comercial. Houve um problema nos negócios e tentamos resolvê-lo. Naquele momento, isso se expressava no fato de diferentes canais utilizarem princípios diferentes de cálculo de preços - separadamente para promoções, para promoções, e assim por diante. A manutenção era difícil, ocorriam erros e ouvíamos as reclamações dos clientes. Ou seja, estávamos vendendo uma solução para um problema, mas chegamos com o fato de que precisávamos de dinheiro para criar uma plataforma. E mostraram um business case usando o exemplo da primeira fase de investimento: como continuaremos a recuperá-lo e o que isso nos permitirá fazer.
Dmitriy:
Você de alguma forma registrou o tempo da primeira etapa?
Sergey:
Sim, claro. Alocamos 6 meses para criar o núcleo como plataforma e testar o piloto. Durante esse tempo, tentamos criar uma plataforma para o piloto patinar. Então a hipótese foi confirmada e, como funciona, significa que podemos continuar. Eles começaram a replicar e fortalecer a equipe – transferiram-na para uma divisão separada que faz exatamente isso.
Em seguida vem o trabalho sistemático baseado nas necessidades do negócio, oportunidades, disponibilidade de recursos e tudo o que está em andamento.
Dmitriy:
OK. Alexandre, o que você me diz?
Alexandre:
Nossos microsserviços nasceram da “espuma do mar” - pela economia de recursos, por algumas sobras na forma de capacidade do servidor e pela redistribuição de forças dentro da equipe. Inicialmente, não vendemos esse projeto para empresas. Este foi um projeto onde pesquisamos e desenvolvemos adequadamente. Começamos no início de 2018 e simplesmente desenvolvemos essa direção com entusiasmo. As vendas apenas começaram e estamos no processo.
Dmitriy:
Acontece que uma empresa permite que você faça coisas como o Google - em um dia livre por semana? Você tem essa direção?
Alexandre:
Ao mesmo tempo que pesquisamos, também tratamos de problemas de negócio, portanto todos os nossos microsserviços são soluções para problemas de negócio. Só no início construímos microsserviços que cobriam uma pequena parte da base de assinantes e agora estamos presentes em quase todos os produtos emblemáticos.
E o impacto material já está claro – já podemos ser contados, a velocidade de lançamento de produtos e a perda de receita podem ser estimadas se tivéssemos seguido o caminho antigo. É sobre isso que estamos construindo o caso.
Microsserviços: exagero ou necessidade?
Dmitriy:
Números são números. E a receita ou o dinheiro economizado são muito importantes. E se você olhar para o outro lado? Parece que os microsserviços são uma tendência, um exagero e muitas empresas estão abusando disso? Com que clareza você diferencia entre o que você faz e o que não traduz em microsserviços? Se for legado agora, você ainda terá legado daqui a 5 anos? Qual será a idade dos sistemas de informação que funcionam na M.Video-Eldorado e MegaFon daqui a 5 anos? Haverá sistemas de informação com dez, quinze anos ou será uma nova geração? Comovocêvêisso?
Sergey:
Parece-me que é difícil pensar muito longe. Se olharmos para trás, quem imaginou que o mercado de tecnologia se desenvolveria dessa forma, incluindo aprendizado de máquina e identificação facial de usuários? Mas se você olhar para os próximos anos, parece-me que os sistemas centrais, sistemas empresariais de classe ERP nas empresas, estão funcionando há muito tempo.
Nossas empresas têm, coletivamente, 25 anos de existência, com ERP clássico muito presente no cenário de sistemas. É claro que estamos tirando algumas peças daí e tentando agregá-las em microsserviços, mas o núcleo permanecerá. Agora é difícil para mim imaginar que substituiremos todos os sistemas principais e passaremos rapidamente para o outro lado positivo dos novos sistemas.
Sou um defensor de que tudo o que está mais próximo do cliente e do consumidor é onde está o maior benefício e valor do negócio, onde a adaptabilidade e o foco na rapidez, na mudança, no “experimentar, cancelar, reutilizar, fazer algo diferente” estão necessário “—é aí que o cenário mudará. E os produtos embalados não cabem muito bem ali. Pelo menos não vemos isso. As soluções mais fáceis e simples são necessárias aí.
Vemos este desenvolvimento:
- sistemas de informação essenciais (principalmente back office);
- camadas intermediárias na forma de microsserviços conectam o núcleo, agregam, criam um cache e assim por diante;
- os sistemas de linha de frente são voltados para o consumidor;
- uma camada de integração que geralmente é integrada a mercados, outros sistemas e ecossistemas. Esta camada é tão leve quanto possível, simples e contém um mínimo de lógica de negócios.
Mas, ao mesmo tempo, defendo a continuação da utilização dos velhos princípios, desde que sejam utilizados de forma adequada.
Digamos que você tenha um sistema empresarial clássico. Ele está localizado no cenário de um fornecedor e consiste em dois módulos que funcionam entre si. Há também uma interface de integração padrão. Por que refazer e trazer um microsserviço para lá?
Mas quando há 5 módulos no back office, a partir dos quais as informações são coletadas em um processo de negócios, que é então usado por 8 a 10 sistemas de linha de frente, o benefício é imediatamente perceptível. Você pega cinco sistemas de back-office e cria um serviço, isolado, focado no processo de negócios. Torne o serviço tecnologicamente avançado - para que armazene informações em cache e seja tolerante a falhas, e também funcione com documentos ou entidades comerciais. E você o integra de acordo com um único princípio com todos os produtos da linha de frente. Eles cancelaram o produto de primeira linha - simplesmente desligaram a integração. Amanhã você precisará escrever um aplicativo mobile ou fazer um pequeno site e colocar apenas uma parte em funcionalidade - tudo é simples: você montou como um construtor. Vejo mais desenvolvimento nesta direção – pelo menos no nosso país.
Alexandre:
Sergey descreveu completamente nossa abordagem, obrigado. Direi apenas onde definitivamente não iremos - para a parte central, para o tópico de faturamento online. Ou seja, a classificação e a cobrança permanecerão, na verdade, um “grande” debulhador que irá dar baixa confiável no dinheiro. E este sistema continuará a ser certificado pelas nossas autoridades reguladoras. Todo o resto voltado para os clientes, é claro, são microsserviços.
Dmitriy:
Aqui a certificação é uma história. Provavelmente mais apoio. Se você gasta pouco com suporte ou o sistema não necessita de suporte e modificação, é melhor não mexer nele. Um compromisso razoável.
Como desenvolver microsserviços confiáveis
Dmitriy:
Multar. Mas ainda estou interessado. Agora você está contando uma história de sucesso: deu tudo certo, mudamos para microsserviços, defendemos a ideia para o negócio e deu tudo certo. Mas ouvi outras histórias.
Há alguns anos, uma empresa suíça que investiu dois anos no desenvolvimento de uma nova plataforma de microsserviços para bancos acabou encerrando o projeto. Completamente desmoronado. Muitos milhões de francos suíços foram gastos e, no final, a equipe foi dispersada - não deu certo.
Você já teve histórias semelhantes? Houve ou há dificuldades? Por exemplo, manter microsserviços e monitoramento também é uma dor de cabeça nas atividades operacionais da empresa. Afinal, o número de componentes aumenta dezenas de vezes. Como você vê, houve exemplos de investimentos mal sucedidos aqui? E o que você pode aconselhar às pessoas para que não encontrem tais problemas?
Alexandre:
Exemplos malsucedidos incluíram empresas que mudaram prioridades e cancelaram projetos. Quando estava em um bom estágio de prontidão (na verdade, o MVP está pronto), o negócio dizia: “Temos novas prioridades, estamos passando para outro projeto e estamos encerrando este”.
Não tivemos nenhuma falha global com microsserviços. Dormimos tranquilos, temos um plantão 24 horas por dia, 7 dias por semana, que atende todo o BSS [sistema de suporte empresarial].
E mais uma coisa: alugamos microsserviços de acordo com as regras que se aplicam aos produtos embalados. A chave do sucesso é que você precisa, primeiramente, montar uma equipe que prepare totalmente o microsserviço para produção. O desenvolvimento em si é, condicionalmente, de 40%. O resto são análises, metodologia DevSecOps, as integrações certas e a arquitetura certa. Prestamos especial atenção aos princípios de construção de aplicações seguras. Os representantes de segurança da informação participam de cada projeto tanto na fase de planejamento da arquitetura quanto durante o processo de implementação. Eles também gerenciam sistemas para analisar códigos em busca de vulnerabilidades.
Digamos que implantamos nossos serviços sem estado – nós os temos no Kubernetes. Isso permite que todos durmam em paz devido ao escalonamento e aumento automático de serviços, e o turno de plantão detecta incidentes.
Em toda a existência dos nossos microsserviços, houve apenas um ou dois incidentes que atingiram a nossa linha. Agora não há problemas com a operação. É claro que não temos 200, mas cerca de 50 microsserviços, mas eles são usados em produtos principais. Se eles falhassem, seríamos os primeiros a saber disso.
Microsserviços e RH
Sergey:
Concordo com o meu colega sobre a transferência para apoio - que o trabalho precisa ser organizado corretamente. Mas vou falar sobre os problemas que, claro, existem.
Em primeiro lugar, a tecnologia é nova. Isso é exagero no bom sentido, e encontrar um especialista que entenda e possa criar isso é um grande desafio. A competição por recursos é louca, por isso os especialistas valem seu peso em ouro.
Em segundo lugar, com a criação de determinadas paisagens e de um número crescente de serviços, o problema da reutilização deve ser constantemente resolvido. Como os desenvolvedores gostam de fazer: “Vamos escrever muitas coisas interessantes aqui agora...” Por causa disso, o sistema cresce e perde sua eficácia em termos de dinheiro, custo de propriedade e assim por diante. Ou seja, é preciso incluir o reuso na arquitetura do sistema, incluí-lo no roteiro de introdução de serviços e transferência do legado para uma nova arquitetura.
Outro problema – embora isto seja bom à sua maneira – é a concorrência interna. “Ah, novos caras da moda apareceram aqui, eles falam uma nova língua.” As pessoas, é claro, são diferentes. Há quem esteja acostumado a escrever em Java e quem escreva e use Docker e Kubernetes. São pessoas completamente diferentes, falam de maneira diferente, usam termos diferentes e às vezes não se entendem. A capacidade ou incapacidade de partilhar práticas, partilhar conhecimentos, neste sentido também é um problema.
Bem, dimensionando recursos. "Ótimo, vamos lá! E agora queremos mais rápido, mais. O quê, você não pode? Não é possível entregar o dobro em um ano? E porque?" Essas dores de crescimento são provavelmente padrão para muitas coisas, muitas abordagens, e você pode senti-las.
Em relação ao monitoramento. Parece-me que os serviços ou ferramentas de monitoramento industrial já estão aprendendo ou são capazes de trabalhar com Docker e Kubernetes de uma forma diferente e não padronizada. Para que, por exemplo, você não acabe com 500 máquinas Java nas quais tudo isso roda, ou seja, agrega. Mas ainda falta maturidade a esses produtos, eles têm que passar por isso. O tema é realmente novo e continuará a se desenvolver.
Dmitriy:
Sim, muito interessante. E isso se aplica ao RH. Talvez o seu processo de RH e a marca do RH tenham mudado um pouco ao longo desses 3 anos. Você começou a recrutar outras pessoas com competências diferentes. E provavelmente existem prós e contras. Anteriormente, o blockchain e a ciência de dados eram o hype, e os especialistas neles valiam milhões. Agora o custo está caindo, o mercado está saturado e há uma tendência semelhante nos microsserviços.
Sergey:
Sim, absolutamente.
Alexandre:
O RH faz a pergunta: “Onde está o seu unicórnio rosa entre o backend e o frontend?” O RH não entende o que é um microsserviço. Contamos a eles o segredo e dissemos que o backend fazia tudo e que não existe unicórnio. Mas o RH está mudando, aprendendo rapidamente e recrutando pessoas com conhecimentos básicos de TI.
A evolução dos microsserviços
Dmitriy:
Se você observar a arquitetura alvo, os microsserviços parecerão um monstro. Sua jornada durou vários anos. Outros têm um ano, outros três anos. Você previu todos os problemas, a arquitetura alvo, alguma coisa mudou? Por exemplo, no caso dos microsserviços, os gateways e as malhas de serviço estão aparecendo novamente. Você os usou no começo ou mudou a própria arquitetura? Você tem esses desafios?
Sergey:
Já reescrevemos vários protocolos de comunicação. No início havia um protocolo, agora mudamos para outro. Aumentamos a segurança e a confiabilidade. Começamos com tecnologias empresariais - Oracle, Web Logic. Agora estamos nos afastando dos produtos empresariais tecnológicos em microsserviços e migrando para tecnologias de código aberto ou completamente abertas. Abandonamos os bancos de dados e passamos para o que funciona de forma mais eficaz para nós neste modelo. Não precisamos mais de tecnologias Oracle.
Começamos simplesmente como um serviço, sem pensar no quanto precisávamos de cache, o que faríamos quando não houvesse conexão com um microsserviço, mas fossem necessários dados, etc. não na linguagem dos serviços, mas na linguagem empresarial, levamos a lógica empresarial para o próximo nível quando começamos a falar em palavras. Agora aprendemos a falar por letras, e o próximo nível é quando os serviços serão reunidos em algum tipo de agregado, quando já é uma palavra - por exemplo, um cartão de produto inteiro. Ele é montado a partir de microsserviços, mas é uma API construída sobre isso.
A segurança é muito importante. Assim que você começa a ficar acessível e tem um serviço através do qual pode obter muitas coisas interessantes, e muito rapidamente, em uma fração de segundo, surge o desejo de obtê-lo de uma forma não muito segura. Para fugir disso, tivemos que mudar as abordagens de teste e monitoramento. Tivemos que mudar a equipe, a estrutura de gestão de entregas, CI/CD.
Esta é uma evolução - como acontece com os telefones, só que muito mais rápida: primeiro surgiram os telefones com botão de pressão, depois surgiram os smartphones. Eles reescreveram e redesenharam o produto porque o mercado tinha uma necessidade diferente. É assim que a gente evolui: primeira série, décima série, trabalho.
Iterativamente, algo é definido por ano do ponto de vista da tecnologia, outra coisa do ponto de vista do backlog e das necessidades. Conectamos uma coisa a outra. A equipe gasta 20% com dívida técnica e suporte técnico para a equipe, 80% com a entidade empresarial. E avançamos com uma compreensão da razão pela qual o estamos a fazer, da razão pela qual estamos a fazer estas melhorias tecnológicas, aonde elas nos levarão. Assim.
Dmitriy:
Legal. O que há no MegaFon?
Alexandre:
O principal desafio quando chegamos aos microsserviços foi não cair no caos. O escritório de arquitetura MegaFon imediatamente se juntou a nós, até se tornou um iniciador e impulsionador - agora temos uma arquitetura muito forte. Sua tarefa era entender qual modelo alvo iríamos e quais tecnologias precisam ser testadas. Com arquitetura, nós mesmos conduzimos esses pilotos.
A próxima pergunta foi: “Então como explorar tudo isso?” E mais uma: “Como garantir a interação transparente entre microsserviços?” A malha de serviço nos ajudou a responder a última pergunta. Testamos o Istio e gostamos dos resultados. Agora estamos na fase de implantação em zonas produtivas. Temos uma atitude positiva em relação a todos os desafios - o fato de precisarmos mudar constantemente a pilha, aprender algo novo. Estamos interessados em desenvolver e não em explorar soluções antigas.
Dmitriy:
Palavras de ouro! Esses desafios mantêm a equipe e a empresa em alerta e criam o futuro. O GDPR criou diretores de proteção de dados e os desafios atuais criam diretores de microsserviços e arquitetura. E isso agrada.
Discutimos muito. O principal é que um bom design dos microsserviços e da própria arquitetura permite evitar muitos erros. É claro que o processo é iterativo e evolutivo, mas é o futuro.
Obrigado a todos os participantes, obrigado a Sergei e Alexander!
Perguntas do público
Pergunta do público (1):
Sergey, como o gerenciamento de TI mudou na sua empresa? Entendo que quando há uma grande pilha de vários sistemas, a forma como ela é gerenciada é um processo bastante claro e lógico. Como você reconstruiu o gerenciamento do componente de TI depois que um grande número de microsserviços foi integrado em tão pouco tempo?
Sergey:
Concordo com o meu colega que a arquitectura é muito importante como motor de mudança. Começámos por ter uma divisão de arquitectura. Os arquitetos são simultaneamente os donos da distribuição da funcionalidade e dos requisitos de como ela aparecerá na paisagem. Então eles também atuam como coordenadores dessas mudanças. Como resultado, houve mudanças específicas em um processo de entrega específico quando criamos uma plataforma de CI/CD.
Mas os princípios básicos e padrão de desenvolvimento, análise de negócios, testes e desenvolvimento não foram cancelados. Acabamos de adicionar velocidade. Anteriormente, o ciclo demorava muito, a instalação em ambientes de teste demorava muito mais. Agora as empresas vêem os benefícios e dizem: “Por que não podemos fazer o mesmo em outros lugares?”
É como, no bom sentido, uma injeção em forma de vacina que mostrou: você pode fazer assim, mas pode fazer de outra maneira. É claro que há um problema de pessoal, de competências, de conhecimento, de resistência.
Pergunta do público (2):
Os críticos da arquitetura de microsserviços dizem que o teste e o desenvolvimento são difíceis. Isso é lógico onde as coisas ficam complicadas. Que desafios sua equipe enfrentou e como você os superou? Pergunta para todos.
Alexandre:
Existem dificuldades ao passar de microsserviços para uma plataforma, mas elas podem ser resolvidas.
Por exemplo, estamos criando um produto que consiste em 5 a 7 microsserviços. Precisamos fornecer testes de integração em toda a pilha de microsserviços para dar luz verde para migrar para o branch master. Essa tarefa não era novidade para nós: já fazíamos isso há muito tempo na BSS, quando o fornecedor nos forneceu soluções já enviadas.
E nosso problema está apenas na equipe pequena. É necessário um engenheiro de controle de qualidade para um produto condicional. E assim, enviamos um produto de 5 a 7 microsserviços, dos quais 2 a 3 podem ser desenvolvidos por terceiros. Por exemplo, temos um produto em cujo desenvolvimento participam nosso fornecedor de sistema de faturamento, Mail.ru Group e MegaFon R&D. Precisamos cobrir isso com testes antes de enviá-lo para produção. O engenheiro de controle de qualidade está trabalhando neste produto há um mês e meio e o restante da equipe fica sem seu apoio.
Essa complexidade é causada apenas pelo dimensionamento. Entendemos que microsserviços não podem existir no vácuo; isolamento absoluto não existe. Ao alterar um serviço, sempre tentamos preservar o contrato da API. Se algo mudar sob o capô, o serviço frontal permanece. Se as mudanças forem fatais, ocorre algum tipo de transformação arquitetural e passamos para um metamodelo de dados completamente diferente, que é completamente incompatível - só então falamos sobre o aparecimento da especificação da API do serviço v2. Apoiamos a primeira e a segunda versões simultaneamente e, após todos os consumidores mudarem para a segunda versão, simplesmente fechamos a primeira.
Sergey:
Eu quero adicionar. Concordo plenamente com as complicações - elas acontecem. O cenário está se tornando mais complexo e os custos indiretos estão aumentando, especialmente para testes. Como lidar com isso: mude para testes automatizados. Sim, você terá que investir adicionalmente na escrita de autotestes e testes unitários. Para que os desenvolvedores não pudessem fazer commit sem passar no teste, eles não poderiam alterar o código. Para que mesmo o botão não funcione sem autoteste, teste unitário.
É importante manter a funcionalidade anterior e isso representa uma sobrecarga adicional. Se você reescrever uma tecnologia para outro protocolo, você a reescreverá até fechar tudo completamente.
Às vezes não fazemos testes ponta a ponta de propósito, porque não queremos interromper o desenvolvimento, embora também tenhamos uma coisa atrás da outra. A paisagem é muito grande, complexa, existem muitos sistemas. Às vezes são apenas tocos - sim, você diminui a margem de segurança e aparecem mais riscos. Mas ao mesmo tempo você libera o suprimento.
Alexandre:
Sim, autotestes e testes unitários permitem criar um serviço de alta qualidade. Defendemos um pipeline que não pode ser aprovado sem testes unitários e de integração. Muitas vezes temos que arrastar emuladores e sistemas comerciais para zonas de teste e ambientes de desenvolvimento, porque nem todos os sistemas podem ser colocados em zonas de teste. Além disso, eles não apenas ficam molhados – nós geramos uma resposta completa do sistema. Esta é uma parte importante do trabalho com microsserviços e também estamos investindo nisso. Sem isso, o caos seguirá.
Pergunta do público (3):
Pelo que entendi, os microsserviços inicialmente cresceram a partir de uma equipe separada e agora existem neste modelo. Quais são seus prós e contras?
Só temos uma história parecida: surgiu uma espécie de fábrica de microsserviços. Agora chegamos conceitualmente ao ponto de estender esta abordagem à produção por fluxos e por sistemas. Em outras palavras, estamos nos afastando do desenvolvimento centralizado de microsserviços, modelos de microsserviços, e nos aproximando dos sistemas.
Dessa forma, a nossa atuação também vai para os sistemas, ou seja, estamos descentralizando esse tema. Qual é a sua abordagem e qual é a sua história alvo?
Alexandre:
Você tirou o nome “fábrica de microsserviços” da sua boca - também queremos escalar. Em primeiro lugar, realmente temos uma equipe agora. Queremos fornecer a todas as equipes de desenvolvimento da MegaFon a oportunidade de trabalhar em um ecossistema comum. Não queremos assumir completamente todas as funcionalidades de desenvolvimento que temos agora. A tarefa local é escalar, a tarefa global é liderar o desenvolvimento para todas as equipes na camada de microsserviços.
Sergey:
Vou te contar o caminho que seguimos. Realmente começamos a trabalhar como uma equipe, mas agora não estamos sozinhos. Sou um defensor do seguinte: deve haver um dono do processo. Alguém precisa entender, gerenciar, controlar e construir o processo de desenvolvimento de microsserviços. Ele deve possuir recursos e se envolver no gerenciamento de recursos.
Esses recursos, que conhecem tecnologias, especificidades e entendem como construir microsserviços, podem ser localizados em times de produto. Temos um mix onde pessoas da plataforma de microsserviços estão na equipe de produto que faz o aplicativo mobile. Eles estão lá, mas trabalham de acordo com o processo do departamento de gerenciamento da plataforma de microsserviços com seu gerente de desenvolvimento. Dentro desta divisão existe uma equipe separada que lida com tecnologia. Ou seja, misturamos um conjunto comum de recursos entre nós e os dividimos, entregando-os às equipes.
Ao mesmo tempo, o processo permanece geral, controlado, segue princípios tecnológicos gerais, com testes unitários e assim por diante - tudo o que é construído em cima. Pode haver colunas na forma de recursos coletados de diferentes departamentos da abordagem do produto.
Alexandre:
Sergey, na verdade você é o dono do processo, certo? O backlog de tarefas é compartilhado? Quem é o responsável pela sua distribuição?
Sergey:
Olha: aqui está a mistura novamente. Existe um backlog que se forma com base em melhorias tecnológicas - essa é uma história. Existe um backlog, que é formulado a partir de projetos, e existe um backlog de produtos. Mas a sequência de introdução em cada um dos produtos do serviço ou de criação deste serviço é desenvolvida por um especialista do produto. Ele não está na diretoria de TI, foi especialmente afastado dela. Mas meu pessoal definitivamente trabalha de acordo com o mesmo processo.
Os proprietários do backlog em diferentes direções - o backlog de mudanças - serão pessoas diferentes. A ligação dos serviços tecnológicos, o seu princípio organizador - tudo isto estará na TI. Eu possuo a plataforma e os recursos também. No topo está o que diz respeito ao backlog e às mudanças funcionais, e à arquitetura nesse sentido.
Digamos que uma empresa diga: “Queremos esta função, queremos criar um novo produto – refazer um empréstimo”. Respondemos: “Sim, vamos refazer”. Os arquitetos dizem: “Vamos pensar: onde no empréstimo escreveremos microsserviços e como faremos isso?” Em seguida, dividimos tudo em projetos, produtos ou pilha de tecnologia, colocamos em equipes e implementamos. Você criou um produto internamente e decidiu usar microsserviços nesse produto? Dizemos: “Agora, os sistemas legados que tínhamos, ou sistemas de linha de frente, devem migrar para esses microsserviços”. Os arquitetos dizem: “Então: no backlog tecnológico dentro dos produtos de linha de frente - a transição para microsserviços. Ir". E os especialistas em produtos ou proprietários de empresas entendem quanta capacidade é alocada, quando isso será feito e por quê.
O fim da discussão, mas nem tudo
A conferência mailto:CLOUD foi organizada .
Também fazemos outros eventos - por ex. Encontro @Kubernetes, onde estamos sempre em busca de grandes palestrantes:
- Acompanhe @Kubernetes e outras novidades do @Meetup em nosso canal Telegram
- Interessado em falar em um dos @Meetups? Deixe um pedido para
Fonte: habr.com