Em 25 de abril, nós do Mail.ru Group realizamos uma conferência sobre nuvens e ao redor -
mailto: CLOUD . Alguns destaques:
- Os principais provedores russos se reuniram em um estágio - Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center e Yandex.Cloud falou sobre as especificidades de nosso mercado de nuvem e seus serviços;
- Colegas do Bitrix24 contaram como chegaram à multiclaud ;
- Leroy Merlin, Otkrytie, Burger King e Schneider Electric forneceram uma visão interessante por parte dos consumidores de nuvem - quais tarefas seus negócios definem para TI e quais tecnologias, incluindo as de nuvem, elas consideram as mais promissoras.
Todos os vídeos da conferência mailto: CLOUD podem ser vistos
aqui , mas 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 Sergeyev, diretor de tecnologia da informação do grupo M. Video-Eldorado, compartilharam seus casos - bem-sucedidos - de se livrar de monólitos. Eles também discutiram questões relacionadas à estratégia de TI, processos e até RH.
Painelistas
- Sergey Sergeev , diretor de tecnologia da informação , M.Video-Eldorado Group ;
- Alexander Deulin , chefe do centro de pesquisa e desenvolvimento de sistemas de negócios MegaFon ;
- Moderador - Dmitry Lazarenko , chefe da Mail.ru Cloud Solutions na direção do PaaS.
Após um discurso de Alexander Deulin
“Como o MegaFon expande seus negócios através de uma plataforma de microsserviços
”, Sergey Sergeev, da M.Video-Eldorado, se junta a ele para discussão e moderador da discussão Dmitry Lazarenko, Mail.ru Cloud Solutions.
Abaixo preparamos para você uma transcrição da discussão, mas você também pode assistir ao vídeo:
Mudando para microsserviços - uma resposta às necessidades do mercado
Dmitry:Você já teve alguma experiência bem-sucedida ao mudar para microsserviços? E em geral: onde você vê o maior benefício nos negócios com o uso de microsserviços ou a transição de monólitos para microsserviços?
Sergey:Já avançamos 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 sem fim de diferentes produtos de linha de frente com o back office. E cada vez que precisávamos fazer integração adicional, desenvolvimento, implementando nossas regras para a operação de um serviço.
Em algum momento, percebemos que precisávamos acelerar nossos sistemas e funcionalidade de saída. Naquele momento, conceitos como microsserviços, abordagem de microsserviço já existiam no mercado e decidimos experimentá-lo. Tudo começou em 2016. Em seguida, a plataforma foi lançada e os 10 primeiros serviços foram implementados, por uma equipe separada.
Um dos primeiros serviços, o mais carregado, foi um serviço de cálculo de preços. Cada vez que você acessa qualquer canal, o grupo de empresas M.Video-Eldorado, seja um site ou uma loja de varejo, pega mercadorias lá, vê o preço no site ou no "Cesto", um serviço calcula automaticamente o preço. Por que isso é necessário: antes disso, cada sistema tinha seus próprios princípios de trabalhar com descontos promocionais e assim por diante. O back office está envolvido nos preços, a funcionalidade de desconto é implementada em outro sistema. Era necessário centralizar e criar um serviço único e destacável na forma de um processo de negócios que nos permitisse implementá-lo. Foi assim que começamos.
O valor dos primeiros resultados foi muito grande. Em primeiro lugar, conseguimos criar entidades destacáveis que nos permitem trabalhar separadamente, agregadas. Em segundo lugar, reduzimos o custo de propriedade em termos de integração com um grande número de sistemas.
Nos últimos três anos, adicionamos três sistemas de linha de frente. Era difícil mantê-los na mesma quantidade de recursos que a empresa podia pagar. Portanto, surgiu a tarefa de buscar novas saídas, responder ao mercado em termos de velocidade, em termos de custos internos e eficiência.
Como avaliar o sucesso da transição para microsserviços
Dmitry:Como é determinado o sucesso na mudança para microsserviços? Qual foi o "antes" em cada empresa? Que métrica você usou para determinar o sucesso da transição, quem realmente a determinou?
Sergey:Primeiro de tudo, ele nasceu dentro da TI como facilitador - "desbloqueando" novos recursos. Tínhamos necessidade de fazer tudo mais rápido por relativamente o mesmo dinheiro, respondendo aos desafios do mercado. Agora, o sucesso é expresso no número de serviços reutilizados por diferentes sistemas, na unificação de processos entre si. Agora é assim e, naquele momento, foi uma oportunidade de criar uma plataforma e confirmar a hipótese de que podemos fazer isso, isso dará o efeito e o cálculo do caso de negócios.
Alexander:Sucesso é antes uma sensação interior. Os negócios sempre querem mais, e a profundidade do nosso backlog é a confirmação do sucesso. Eu acho que sim.
Sergey:Sim, eu concordo. Por três anos, já temos mais de duzentos serviços e backlog. A demanda por recursos dentro da equipe está crescendo apenas - anualmente em 30%. Isso ocorre porque as pessoas sentem: são mais rápidas, diferentemente, outras tecnologias, tudo isso está se desenvolvendo.
Os microsserviços virão, mas o núcleo permanecerá
Dmitry:É como um processo sem fim, onde você investe no desenvolvimento. A transição para microsserviços para os negócios já terminou ou não?
Sergey:Muito fácil de responder. O que você acha: substituir telefones é um processo sem fim? Nós mesmos compramos telefones todos os anos. E aqui está: embora haja necessidade de velocidade, na adaptação ao mercado, algumas mudanças serão necessárias. Isso não significa que recusamos coisas comuns.
Mas não podemos abraçar e refazer imediatamente tudo. Temos serviços de integração padrão herdados antes disso: barramentos corporativos e assim por diante. Mas há uma lista de pendências e também é necessário. O número de aplicativos móveis e sua funcionalidade estão aumentando. Ao mesmo tempo, ninguém diz que lhe dará 30% mais dinheiro. Ou seja, sempre há necessidades, por um lado, e, por outro, uma busca por eficiência.
Dmitry:A vida está em boa forma.
(Risos)Alexander:Em geral, sim. Não temos abordagens revolucionárias para remover as partes principais da paisagem. Está em andamento um trabalho sistemático para decompor sistemas para que sejam mais consistentes com a arquitetura de microsserviços, para reduzir a influência dos sistemas uns sobre os outros.
Mas planejamos manter a parte principal, pois no cenário da operadora sempre haverá algumas plataformas que compramos. Novamente, você precisa de um equilíbrio saudável: não devemos nos apressar para o âmago do "corte". Colocamos os sistemas lado a lado e, agora, acontece que já existem muitas partes principais. Além disso, desenvolvendo a funcionalidade, fazemos as representações necessárias para todos os canais que trabalham com nossos serviços de comunicação.
Como vender microsserviços para uma empresa
Dmitry:Ainda estou interessado - por aqueles que não mudaram, mas vão: quão fácil foi vender essa ideia para os negócios e foi uma aposta, um projeto de investimento? Ou era uma estratégia deliberada: agora vamos a microsserviços e isso é tudo, nada vai nos parar. Como foi com você?
Sergey:Não vendemos a abordagem, mas o ganho nos negócios. Houve um problema nos negócios e tentamos removê-lo. Naquele momento, foi expresso o fato de que em diferentes canais foram utilizados diferentes princípios de precificação - separadamente para promoções, ações e assim por diante. Foi difícil de manter, surgiram erros, ouvimos as reclamações dos clientes. Ou seja, vendemos a eliminação do problema, mas viemos com o fato de que precisamos de dinheiro para criar uma plataforma. E eles mostraram um caso de negócios no exemplo do primeiro estágio do investimento: como continuaremos a pagar por isso e o que isso nos permitirá fazer.
Dmitry:De alguma forma, você fixou o tempo da primeira etapa?
Sergey:Sim claro. Levamos 6 meses para criar o núcleo como plataforma e teste piloto. Durante esse período, tentamos criar uma plataforma na qual o piloto estava patinando. Eles confirmaram ainda mais a hipótese e, como funciona, podemos continuar. Eles começaram a replicar e fortalecer a equipe - eles a levaram a uma unidade separada, que está envolvida apenas nisso.
A seguir, é apresentado o trabalho sistemático decorrente das necessidades dos negócios, oportunidades, disponibilidade de recursos e tudo o que está em andamento no momento.
Dmitry:Ok Alexander, o que você diz?
Alexander:Nossos microsserviços nasceram da “espuma do mar” - devido à economia de recursos, devido a alguns resíduos na forma de capacidades do servidor e redistribuição de forças dentro da equipe. Inicialmente, não vendemos esse projeto para empresas. Foi um projeto em que pesquisamos e desenvolvemos de acordo. Começamos no início de 2018 e apenas desenvolvemos entusiasticamente essa direção. As vendas estão apenas começando e estamos no processo.
Dmitry:Mas acontece que uma empresa permite que você faça essas coisas com base no princípio do Google - em um dia gratuito por semana? Você tem essa direção?
Alexander:Ao mesmo tempo em que pesquisávamos, estávamos envolvidos em tarefas de negócios, porque todos os nossos microsserviços são soluções para problemas de negócios. Somente no início, construímos microsserviços que cobrem uma pequena parte da base de assinantes e agora estamos em quase todos os principais produtos.
E o impacto do material já é claro - já podemos ser contados, podemos estimar a velocidade da produção do produto e a perda de receita se seguirmos o caminho antigo. É aqui que estamos construindo o caso.
Microsserviços: exagero ou necessidade?
Dmitry:Números são números. E a receita ou o dinheiro economizado é muito importante. E se você olhar para o outro lado? Parece que os microsserviços são uma tendência, hype e muitas empresas abusam dele? Com que clareza você distingue entre o que traduz e o que não traduz em microsserviços? Se o legado for agora, você ainda terá legado em 5 anos? Qual será a idade dos sistemas de informação que funcionarão em M. Video-Eldorado e MegaFon em 5 anos? Haverá sistemas de informação de dez e quinze anos ou será uma nova geração? Como você vê isso?
Sergey:Parece-me que muito longe é difícil de fazer. Se você olhar para trás, quem sugeriu que isso desenvolveria o mercado de tecnologia e o mesmo aprendizado de máquina, identificação do usuário pelo rosto? Mas se você olhar nos próximos anos, parece-me que os sistemas centrais, sistemas corporativos da classe ERP nas empresas - eles estão trabalhando há muito tempo.
Nossas empresas estão juntas há 25 anos, nelas o ERP clássico está localizado profundamente no cenário do sistema. É claro que retiramos algumas peças de lá e tentamos agregá-las em microsserviços, mas o núcleo permanecerá. Agora é difícil imaginar que substituiremos todos os sistemas principais e passaremos rapidamente para o outro lado mais brilhante dos novos sistemas.
Eu sou um defensor de que tudo o que está mais próximo do cliente e do consumidor, onde há o maior benefício e valor comercial, onde a adaptabilidade e o foco na velocidade, nas mudanças, em “tentar, cancelar, reutilizar, fazem outra coisa "- aí a paisagem mudará. E os produtos de caixa não são muito bem construídos lá. Pelo menos não vemos isso. Requer as soluções mais leves e simples.
Vemos esse desenvolvimento:
- sistemas principais de informação (principalmente back office);
- as camadas intermediárias na forma de microsserviços conectam o núcleo, agregam, criam um cache e assim por diante;
- sistemas de linha de frente são direcionados ao consumidor;
- camada de integração, que geralmente é integrada a mercados, outros sistemas e ecossistemas. Essa camada é a mais leve possível, simples, com um mínimo de lógica de negócios.
Mas, ao mesmo tempo, sou a favor de continuar usando os velhos princípios, se eles estiverem acostumados com o local.
Digamos que você tenha um sistema corporativo clássico. Ele está localizado no cenário de um fornecedor, consiste em dois módulos que funcionam entre si. Há também uma interface de integração padrão. Por que refazê-lo e levar um microsserviço para lá?
Porém, quando existem 5 módulos no back office, dos quais as informações são coletadas no processo de negócios, que são usadas por 8 a 10 sistemas front-end, os benefícios são imediatamente visíveis. Você tira cinco sistemas de back-office, cria um serviço, além disso, isolado, focado no processo de negócios. Você torna um serviço tecnológico - para que ele armazene em cache as informações e seja tolerante a falhas, e também trabalhe com documentos ou entidades comerciais. E integre-o em um único princípio a todos os produtos da linha de frente. Eles cancelaram o produto da linha de frente - eles simplesmente desativaram a integração. No dia seguinte, você precisa escrever um aplicativo móvel ou criar um site pequeno e apenas uma parte para o funcional - é simples: você o cria como construtor. Eu vejo mais o desenvolvimento nessa direção - pelo menos em nosso país.
Alexander:Sergey descreveu completamente nossa abordagem, obrigado. Vou apenas dizer para onde definitivamente não iremos - a parte principal, o tópico de cobrança on-line. Ou seja, a classificação e cobrança permanecerão, de fato, uma debulhadora de "debulha" que baixará o dinheiro de maneira confiável. E esse sistema continuará sendo certificado por nossas autoridades reguladoras. Tudo o mais que olha para os clientes, é claro, são microsserviços.
Dmitry:Aqui a certificação é apenas uma história. Provavelmente mais suporte. Se você gastar um pouco em suporte ou o sistema não precisar de suporte e aprimoramento, é melhor não tocá-lo. Compromisso razoável.
Como desenvolver microsserviços confiáveis
Dmitry:Bom Mas ainda estou interessado. Agora você está contando uma história de sucesso: estava tudo bem, mudamos para microsserviços, defendemos a ideia na frente dos negócios e tudo deu 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ço para bancos, finalmente encerrou esse projeto. Completamente dobrado. Muitos milhões de francos suíços foram gastos, mas no final dispersaram a equipe - isso não aconteceu.
Você já teve histórias semelhantes? Houve ou há alguma dificuldade? Por exemplo, manutenção de microsserviço, o mesmo monitoramento também é uma dor de cabeça nas operações da empresa. Afinal, o número de componentes aumenta dezenas de vezes. Como você vê isso, houve algum exemplo mal sucedido de investimentos aqui? E o que as pessoas podem ser aconselhadas para que não encontrem problemas semelhantes?
Alexander:Exemplos malsucedidos foram de que a empresa mudou de prioridades e cancelou projetos. Quando em um bom estágio de prontidão (o MVP está realmente pronto), a empresa disse: "Temos novas prioridades, estamos indo para outro projeto e estamos fechando este".
Não possuímos arquivos globais com microsserviços. Dormimos em paz, temos um turno de serviço 24 horas por dia, 7 dias por semana, que atende todo o BSS [sistema de suporte comercial].
E ainda assim - alugamos microsserviços de acordo com as regras pelas quais os produtos embalados são alugados. A chave para o sucesso é que, em primeiro lugar, você precisa montar uma equipe que prepare totalmente o microsserviço para a produção. O próprio desenvolvimento é, condicionalmente, 40%. O resto são análises, metodologia DevSecOps, integrações corretas e arquitetura correta. Prestamos atenção especial aos princípios de criação de aplicativos seguros. Em cada projeto, representantes de segurança da informação participam do estágio de planejamento da arquitetura e do processo de implementação. Eles também gerenciam sistemas de análise de código para vulnerabilidades.
Suponha que implantemos nossos serviços sem estado - nós os temos no Kubernetes. Isso permite que todos durmam tranqüilamente devido a serviços de auto-dimensionamento e aumento automático, e a mudança de serviço capta incidentes.
Durante todo o tempo de existência de nossos microsserviços, houve apenas um ou dois incidentes que atingiram nossa linha. Agora não há problemas operacionais. Obviamente, não temos 200, mas cerca de 50 microsserviços, mas eles são usados em produtos emblemáticos. Se eles falhassem, seríamos os primeiros a saber sobre isso.
Microsserviços e RH
Sergey:Concordo com meu colega sobre a transferência no suporte - que você precisa organizar o trabalho corretamente. Mas vou dizer sobre os problemas que, é claro, são.
Em primeiro lugar, a tecnologia é nova. Este é um hype de uma maneira boa, e encontrar um especialista que entenda e possa criar isso é um grande desafio. A competição por recursos é louca, respectivamente, os especialistas valem seu peso em ouro.
Em segundo lugar, ao criar certas paisagens e um número crescente de serviços, o problema da reutilização deve ser constantemente resolvido. Como os desenvolvedores gostam de fazer: "Vamos escrever aqui um monte de coisas interessantes aqui ..." Por causa disso, o sistema cresce e perde sua eficácia em termos de dinheiro, custo de propriedade e assim por diante. Ou seja, você precisa reutilizar a arquitetura dos sistemas, incluir no roteiro a introdução de serviços e a transferência de legado para a nova arquitetura.
Outro problema - embora seja bom à sua maneira - é a concorrência interna. "Oh, novos caras da moda apareceram aqui, eles falam um novo idioma." As pessoas, é claro, são diferentes. Há quem está acostumado a escrever em Java e quem escreve e usa o Docker e o Kubernetes. , - , . , knowledge sharing, .
. «, ! , . , ? ? ?» — , , , , .
. , Docker, Kubernetes , . , , 500 Java-, , . , . , .
:, . HR. , R- HR- 3 . , . , , , . blockchain data science, . , , .
:, .
:HR : « backend' frontend'?» HR , . , backend , . HR , , IT-.
:, . . , — . , , -? , gateways, service mesh'. ? ?
:. , . . enterprise- — Oracle, Web Logic. enterprise- open source . , , . Oracle .
, , , , , , . . , , -, - , . , — - , — , . , API.
. , , , , . , . , , CI/CD.
— , : , . , , . : , , .
- , - — backlog' . . 20% , 80% — -. , , , , . .
:. «»?
:— . , «» — . , . .
: « ?». : « ?». service mesh. Istio, . . — , , - . , .
:! . GDPR chief data protection officers, . .
. — . , , .
, !
(1):, IT- ? , , — . IT- , ?
:, . , . , . . , CI/CD.
, , -, — . . -, — -. : « ?».
, , , : , -. , , , , .
(2):, . , - . ? .
:, .
, , 5-7 . , -. : BSS, .
. QA-. , 5-7 , 2-3 . , , , Mail.ru Group R&D «». , . QA- , .
. , , . , API-. - , front . , - , — , API- v2. , .
:. — . , , . : . , unit-. , . push , unit-.
, . , , .
end-to-end , , . , , . — , , . .
:, unit- . , unit- . , , . — . , . .
(3):, . ?
: . , . , , , .
, , . ?
:« » — . -, . , «», . , . — , — .
:, . , . : . - , , . -.
, , , , . , , . , . , . , .
, , , unit- — , . , .
:, , ? Backlog ? ?
:: . backlog, , — . backlog, , backlog . . IT-, . .
backlog' — backlog' — . , — IT. , — . , backlog' , .
, : « , — ». : «, ». : « : ?». , , . ? : « legacy-, , , ». : «: backlog — . ». , capacity, .
,
A conferência mailto: CLOUD foi organizada pela Mail.ru Cloud Solutions .Também realizamos outros eventos - por exemplo, o @Kubernetes Meetup , onde sempre procuramos palestrantes legais:- Siga as notícias de @Kubernetes e outros @Meetup em nosso canal Telegram t.me/k8s_mail
- Quer falar em um dos @Meetup? Deixe uma solicitação em mcs.mail.ru/speak