Quando percebemos que seria entediante realizar a próxima reunião, decidimos transformá-la em algo mais cheio de ação. Ou seja, em um duelo, em um
duelo entre duas abordagens de integração - ESB e Distributed - cuja honra foi defendida por especialistas em pesos pesados. Neste post, mostraremos como foi a batalha e descobriremos o vencedor.
Algumas palavras sobre o formato
Alexander Trekhlebov , nosso arquiteto corporativo, falou pelo ônibus centralizado. Para descentralização - Andrey Trushkin, chefe do centro de inovação e tecnologias promissoras do Promsvyazbank. Eles revezaram-se em suas tecnologias e responderam a várias perguntas, provocativas e não muito. Foi assim que foi.
Por que o ESB é legal?
Para começar, você deve saber e dizer como tudo começou. Muitos provavelmente lembram que, no primeiro estágio, tudo aconteceu sem nenhuma integração, quando cada sistema se comunicava e executava seus testes de integração com todos os outros sistemas.
Consequentemente, se uma pessoa desistisse ou algo mais acontecesse com ele, ninguém sabia como tudo isso funcionaria. Cada computador interagiu com algum servidor. Que protocolo, que tipo de interação? Somente a pessoa que trabalhou no sistema sabia tudo isso.
Depois veio o barramento de integração. Parecia não apenas isso, mas porque os principais protocolos e métodos de interação estavam reunidos e era possível não forçar o sistema a descrever coisas específicas. Ela poderia se comunicar com eles usando seus algoritmos internos.
Além disso, descobriu-se que na maioria das vezes eles se comunicam com o barramento através de filas ou através do REST.
Com o tempo, no entanto, a necessidade de um ônibus e o REST desapareceram em muitos casos. Mas parecia uma reversão, questões importantes pendiam novamente:
- Como orquestrar se não houver pneu. Onde isso vai acontecer?
- O que fazer com os formatos de dados e protocolo?
Além disso, o desempenho em um sistema centralizado é muito melhor do que no Distribuído. Você pode contar com velocidade, volume e disponibilidade. Tudo isso porque é um sistema que uma equipe específica está atendendo.
Quão vulnerável é este sistema? O que acontece se um computador é invadido?Sempre há redundância e centralização. No caso de um estar fora de ordem, o sistema funcionará.
Quem é responsável pelo pneu? Sua equipe ou desenvolvedores de terceiros?Na equipe interna, fornecemos serviços operacionais, fornecemos confiabilidade e monitoramento. Se algo não funcionar, sabemos onde procurar. Há uma pergunta: "É possível confiar em fornecedores nesses casos e em equipes de terceiros?" É necessário um bom monitoramento aqui. Porque a qualidade, em qualquer caso, é de responsabilidade da equipe interna.
À medida que o barramento cresce, os serviços não se conectam. Você muda de serviço com lançamentos ou o quê? O que fazer com o Agile?Aqui chegamos à questão fundamental.
A integração não é um aplicativo. Costumava fazer parte, mas agora não é. Desenvolvimento de integração não é desenvolvimento de aplicativos. É o desenvolvimento de interações de integração ou o desenvolvimento dentro da estrutura de um projeto separado, mas não especificamente de um aplicativo.
Suas preocupações ágeis são compreensíveis. Este modelo é usado quando criamos um sistema separado que está conectado ao barramento em algum lugar do lado. Quando eu trabalhava em outro banco, havia um sistema assim: um mês de testes, um mês de desenvolvimento. Como resultado, todas as interações de integração são rapidamente implementadas no barramento. Ainda mais rápido que os analistas os descrevem, porque os sistemas de desenvolvimento são bastante sofisticados e simples. E o ágil é usado no desenvolvimento do sistema final.
Por quanto tempo a equipe procura o serviço de que precisa e onde o procura?Todo mundo sonha que existe um mapa do mundo no qual todas as principais áreas de negócios estão espalhadas pelos continentes. E é ainda parcialmente implementado. O analista vai até lá e começa a vagar intensamente pelos continentes, depois de algum tempo encontra a interação necessária. Além disso, se tudo se encaixa perfeitamente, ele simplesmente a usa. Caso contrário, descreve em TK quais acréscimos ele precisa. Seria ótimo ter essa opção, mas até agora sistemas menos convenientes que exigem muito mais tempo e esforço para trabalhar com eles são relevantes.
Ou talvez o Service Mesh seja mais legal?
Para começar, muita coisa realmente mudou em 3-4 anos. Mas o que exatamente aconteceu? A mesma banalidade que todos os oradores repetem regularmente, e pela qual também não podemos passar, aconteceu: o mundo está mudando.
Os requisitos para a velocidade da mudança estão se tornando enormes. Ao mesmo tempo, os requisitos de confiabilidade, os requisitos de segurança não desaparecem em lugar algum e os requisitos de carga apenas aumentam. Como podemos ver, todo mundo está tentando capturar participação de mercado, o que inevitavelmente leva a um aumento do ônus para os sistemas corporativos e, conseqüentemente, para a integração.
De fato, o ESB ao mesmo tempo muito legal ajudou como um modelo para implementação técnica em termos de descentralização de aplicativos, a alocação de lógica entre aplicativos diferentes, um dispositivo unificado para integrar aplicativos entre si. Digamos apenas unificado condicionalmente.
Agora vamos imaginar que não há 20 sistemas na empresa - afinal, ele procura mudar para a própria arquitetura chamada buzzword "microsserviços". E o que é um microsserviço? Existem muitas definições, uma delas é usada periodicamente por Martin Fowler: é um serviço que um desenvolvedor intermediário é capaz de desenvolver em um sprint. Imagine quantos desses serviços estarão em uma grande empresa. Por exemplo, a Netflix estima o número de seus microsserviços em 800-900. Em princípio, em uma empresa que busca construir um ecossistema externo de parceiro, esses serviços podem exceder mil. Mas cada um desses serviços, a longo prazo, suporta uma carga tremenda e deve se desenvolver de forma independente.
E o ônibus? Se o barramento continuar sendo esse complexo comum entre eles, isso se tornará um gargalo e atrasará o desenvolvimento dos serviços. Não apenas porque ela está esperando por esses serviços, mas porque ela está se desenvolvendo como uma equipe separada, por pessoas que possuem essas mesmas tecnologias e habilidades.
E agora vamos imaginar: várias dezenas de equipes de produtos estão desenvolvendo e trabalhando conosco. E cada um deles vê vários serviços. E o ônibus é dirigido por duas equipes. Naturalmente, essas equipes com um alto grau de probabilidade não serão capazes de desenvolver essa integração com o nível necessário de velocidade e qualidade.
Surge a pergunta: "Como podemos garantir a mesma velocidade rápida sem perder acessibilidade, segurança e assim por diante?" A resposta é muito simples: "Deixe esses serviços interagirem diretamente, sem um intermediário explícito".
Em seguida, a próxima questão importante é levantada: "Como os serviços aprendem um sobre o outro?" E aqui a resposta também é muito simples: você pode criar um sistema com o qual os próprios serviços reportariam sobre si mesmos. Ou seja, no momento em que o serviço for desenvolvido, ele publicará informações sobre si mesmo em um determinado registro. E com base nessas informações, todos os serviços poderão começar a interagir com ele.
Assim, formou-se o conceito de uma “grade” de serviços - como era originalmente chamado de
“malha de serviço” . Como um tipo de nível intermediário de integração entre serviços, que fornece essa integração, como se fosse uma solução em nuvem.
As grandes empresas agora estão tentando resolver os problemas de velocidade de desenvolvimento em paralelo - para encontrar para isso uma certa solução geral, distribuída e frequentemente incorporada. Nesse caso, cada serviço usa um conjunto específico de bibliotecas prontas para publicar automaticamente as informações em um registro durante a implantação.
Muitas vezes, ainda surge a pergunta: "Mas o que fazer com o modelo de dados canônicos, cuja fonte, em regra, era o ESB, que investiu tanto dinheiro e esforço para implementá-lo e mantê-lo?" Afinal, ela era um modelo de uso padrão. Aqui está uma contra-pergunta: “E que vantagens isso trouxe para nós? E não foi exatamente isso que atrasou nosso desenvolvimento? " De fato, ao desenvolver serviços, o modelo se expande cada vez mais. Sempre haverá desafios cada vez mais novos.
Para ser franco, o
custo de adicionar novos dispositivos, organizar a interação etc., geralmente é significativamente menor que o custo de manter o modelo de dados ESB canônico atualizado .
Além disso, a integração descentralizada garante, em grande parte, a mesma alta disponibilidade. Cada um dos microsserviços é independente, inclusive de outros microsserviços, mas depende criticamente da carga externa que é colocada sobre ele. Implantado em paralelo com a integração também pode ser tecnologicamente implementado de forma independente.
Às vezes, o uso de um ESB bastante pesado em condições modernas não faz sentido ou vice-versa, reduz a qualidade da solução. A aplicação de tecnologias sem servidor, a própria infraestrutura que não se adapta às necessidades efêmeras das soluções criadas, já está à beira, mas já é entregue na versão necessária formada para um serviço específico. Agora parece algo muito distante, mas o mundo está mudando, como já foi dito, muito rapidamente.
Muitos fornecedores de software seguem esse caminho em termos de suas soluções de integração. Já existem estruturas que implementam essencialmente o conceito de malha de serviço (o mesmo Linkerd ou Istio). O mesmo já está acontecendo como parte da hospedagem de um grande número de proxies de rede e serviços de integração de malha de serviço. Muito em comum com os sistemas de malha de serviço e orquestração de contêineres como o Kubernetes.
É possível construir o Distributed com base no ESB? Ou seja, é possível criar outro a partir de um sistema? E se sim, qual é o objetivo dessas disputas?Aqui Hegel e sua "negação de negação" vêm à mente. Quando uma idéia se repete em um nível histórico mais alto. Vir de um para o outro, na minha opinião, é possível. Outra questão é como iremos fazer isso. De fato, em essência, o próprio conceito de microsserviços e sua implementação é, em muitos aspectos, semelhante ao conceito de integração que era originalmente: a interação dos microsserviços entre si, cada um com cada um.
É possível chegar à integração de acordo com os princípios da rede, se formos do ESB? Na verdade, a Red Hat, agora IBM, já está seguindo o mesmo princípio. Basta olhar para o entendimento do conceito de pilha de integração e integração flexível (integração ágil). Eles oferecem um grande número de proxies de integração que não são sobrecarregados com lógica. O mais importante é a transparência e o próprio conhecimento dos serviços exigidos por todos os novos participantes na interação.
O seu banco entende que o ESB sobreviveu a si próprio se continuar investindo orçamentos significativos nele?Francamente, questões orçamentárias são um segredo comercial. Quanto às abordagens utilizadas, atualmente estamos desenvolvendo um paralelo de duas abordagens. No Promsvyazbank, existem muitos sistemas vinculados ao ônibus. Eles ainda estão integrados através do barramento. Mas, por nossa parte, entendemos que o ESB é uma abordagem pouco promissora e é mais eficiente investir em integrações distribuídas sem usar um barramento. Esta é a nossa prioridade estratégica agora.
Onde é o local para o monitoramento de negócios em um sistema distribuído?Na integração descentralizada, a presença de um grande número de serviços não exclui a presença de monitoramento de negócios. Tudo isso pode ser estabelecido no nível dos respectivos quadros. Assim, esse monitoramento pode mesclar informações em um determinado armazenamento responsável pelos dados. Esses dados são analisados lá e um relatório resumido é preparado.
Como você vê o plano para a transição para a integração descentralizada?A transição para a integração descentralizada faz sentido considerar no contexto da transição para novos princípios arquitetônicos. Essa é uma transição complexa que não pode acontecer ao mesmo tempo. Sim, você pode tentar mantê-lo no formato de "big bang", mas essa opção de cenário traz sérios riscos. Mais lógica é a opção de criar um novo circuito em paralelo ao existente e, à medida que é criado (no modo iterativo), introduzir novos produtos nele. À medida que o novo contorno arquitetônico se desenvolve, os produtos do atual cenário de TI que passaram pelo teste do tempo podem ser transferidos para lá. Esse caminho é bastante longo - é estimado em 4-5 anos - mas, devido à iteração, é possível obter resultados no modo de operação industrial sequencialmente.
Quem venceu?
Após três rodadas interativas com apresentações, perguntas e respostas, o público se escondeu em antecipação ao anúncio do resultado final. Você provavelmente percebe que o vencedor da batalha do PSB foi Andrey Trushkin e o sistema distribuído.
Em conclusão, oferecemos um vídeo que ajudará a sentir a atmosfera de nossa batalha: