Sensedia Webinar | Modernização de Aplicações

Olá, pessoal. Sejam todos bem-vindos. Eu sou o Marcelo Dias, sou arquiteto de soluções aqui na Sensedia. E hoje eu vou falar aqui um pouco com vocês sobre modernização de aplicações.

Antes de entrar aqui propriamente dito em técnicas, tecnologias e padrões utilizados aí nessa jornada de modernização de aplicações, primeiro a gente precisa entender um pouco o porquê precisamos modernizar as nossas aplicações. Quais são os motivos que levam uma empresa a iniciar uma jornada como essa? Eu gosto sempre de iniciar as minhas apresentações com alguma frase que consiga representar a mensagem que eu estou tentando transmitir durante essa apresentação. Para essa de hoje eu escolhi essa frase do filósofo grego Heráclito, onde ele diz que não existe nada de permanente, a não ser a mudança. E esse é um dos principais objetivos que levam as empresas a iniciarem, a adotarem uma jornada como essa de modernização de aplicações, para conseguirem responder de forma mais ágil, mais rápida, às mudanças de mercado, às mudanças que o negócio exige. Seja para serem mais ágeis, para lidar com seus concorrentes ou até mesmo para questões regulatórias.

E dentro ainda desse cenário de adaptação a mudanças, eu trouxe aqui alguns dos principais casos de uso, os principais cenários relacionados à necessidade de mudança que nós encontramos aqui no nosso dia a dia, nos projetos aqui da Sensedia, nos projetos que atuamos aqui com os nossos clientes. São basicamente esses três principais aqui:

Experiências digitais: cada vez mais as empresas estão posicionando os clientes no centro das suas estratégias, oferecendo ali melhores produtos e serviços, através de diferentes canais digitais, seja através de websites, aplicativos móveis ou até mesmo integração com dispositivos.

Integração com parceiros: a habilitação de todo esse ecossistema de fornecedores, parceiros e até mesmo clientes. Então integrações que antigamente levavam meses para serem implementadas, hoje precisam ser implementadas em questões de dias. Essa integração precisa ser ágil e descomplicada, com toda a segurança e controle que esse tipo de integração exige.

Novos modelos de negócio: algumas empresas estão se posicionando como plataformas para alavancar, impulsionar modelos de negócio de outras empresas, sejam elas startups ou até mesmo concorrentes. Se vocês olharem o exemplo do Open Finance, Open Banking, Open Insurance, as instituições financeiras colaboram e compartilham informações entre si, com todo o devido consentimento de seus clientes, visando oferecer melhores produtos e serviços para seus clientes através de uma inovação aberta, um modelo aberto de inovação.

Então aqui é só um resumo, esses são os três principais cenários, os três principais casos de uso nesse foco de adaptação a mudanças que nós encontramos aqui no nosso dia a dia com os nossos clientes aqui na Sensedia. Então agora que a gente já falou um pouquinho sobre o porquê, por que as empresas adotam uma jornada de modernização como essa, é importante a gente falar também agora um pouco sobre com que eu realizo essa modernização,quais são as principais tecnologias, os padrões envolvidos nesse processo de modernização de aplicações. O processo de modernização de aplicações. Um termo bem comum quando se fala de uma arquitetura moderna são os microserviços. ideia aqui não é entrar no detalhe da explicação desses conceitos, dessas tecnologias. É fornecer uma visão geral de quais são essas tecnologias envolvidas nesse processo de modernização e os principais características e benefícios. Mas de qualquer forma, na descrição do vídeo aqui vão estar disponíveis alguns links com alguns materiais bem interessantes e bem relevantes aqui da Sensedia com maiores informações, com mais detalhes sobre essas tecnologias. Sejam microserviços, APIs, até mesmo temas de segurança. Na descrição do vídeo você tem acesso a diversos materiais interessantes. Então se tiver um tempinho, dê uma olhada lá que com certeza são materiais que vão auxiliar bastante no dia a dia de vocês.

Retomando aqui a questão dos microserviços, o que é um microserviço? É um estilo de arquitetura onde uma aplicação é composta por serviços menores e independentes e geralmente organizados por capacidades de negócio, baseada nos domínios de negócio de uma empresa. Diferente de um monolito, uma aplicação legada mais antiga, onde todas as funções de negócio, todas essas capacidades de negócio estão sob o mesmo processo, no mesmo bloco. Isso dificulta a escalabilidade individual dessas capacidades de negócio.

Aqui mais à direita a gente vê alguns dos principais benefícios desse estilo de arquitetura de microserviços. Que são eles:

Agilidade: por se tratarem de componentes serviços menores e independentes, você pode também estruturar o seu desenvolvimento nas suas equipes em equipes menores, com mais autonomia para fazer evoluções, melhorias nesses serviços, e até acelerando o ciclo de desenvolvimento e a entrega desses serviços para consumo.

Escalabilidade: um dos principais benefícios desse estilo de arquitetura. Por serem componentes independentes, é possível você ter uma escalabilidade individual dessas capacidades de negócio, de acordo com a demanda que o negócio está exigindo naquele momento. Por exemplo, é uma capacidade aqui relacionada ao processo de vendas. Você pode escalar aquele serviço específico de vendas para atender uma necessidade específica, uma demanda específica naquele momento. Imagine, por exemplo, um período de Black Friday, onde as vendas, a quantidade de vendas aumenta. Então você pode escalar individualmente essa capacidade de negócio para atender essa demanda. Diferente do monolito, onde como as funções estão no mesmo processo, você acaba escalando de forma igual todas as funcionalidades e acaba desperdiçando até seus recursos tecnológicos. Eventualmente, algumas funcionalidades, como contas a pagar, o cadastro de clientes, não precisariam escalar naquele momento. Então, nesse estilo de arquitetura, de microserviços, você tem essa flexibilidade de escalar conforme a capacidade, conforme a demanda de cada capacidade.

Facilidade de implantação: por serem componentes menores, você pode ter ali o controle do código, do versionamento de forma mais efetiva, a implementação de esteiras de entrega contínua para acelerar o seu ciclo de desenvolvimento, permitindo toda aquela autonomia que eu comentei anteriormente que as equipes podem ter em seus microserviços.

Liberdade tecnológica: nesse estilo de arquitetura, as equipes de desenvolvimento têm total autonomia para escolher qual tecnologia, qual linguagem de programação, por exemplo, vai ser utilizada no desenvolvimento do microserviço sob a sua gestão. É importante ressaltar aqui, não estou querendo dizer que é para desenvolver cada microserviço numa linguagem diferente. Não é isso. Mesmo nessa arquitetura, na verdade aqui especialmente nesse estilo de arquitetura, continua sendo importante você trabalhar em cima de alguns padrões, algumas arquiteturas de referência para o desenvolvimentodos seus serviços. O ponto aqui é justamente a questão da liberdade, para você poder experimentar uma tecnologia em alguns cenários que façam sentido ali para o negócio. Por exemplo, vamos citar aqui um exemplo de um requisito de performance. Às vezes você otimizou, fez de tudo que estava à sua disposição para otimizar a performance daquele serviço, mas eventualmente você pode estar limitado a algumas restrições da plataforma que você está utilizando, do stack de tecnologia que você está utilizando. E eventualmente o uso de uma outra tecnologia, uma outra linguagem de programação, pode trazer ali um benefício de performance que é esperado. Então para esse caso específico, você pode experimentar essa nova tecnologia para aquela capacidade de negócio, então certificar que você consiga atingir aquele requisito de negócio.

Um outro exemplo comum também nessa questão de liberdade tecnológica, é muito comum os produtos de software, os frameworks de desenvolvimento, terem ali as suas diferentes versões. Eles também vão evoluindo ao longo do tempo, tendo todo o seu ciclo de vida. E com o tempo, algumas versões vão sendo descontinuadas. Mas geralmente a gente já sabe isso com antecedência, às vezes dois, três anos de antecedência, já tem ali alguma publicação informando que aquela tecnologia, aquele produto de software, aquele framework, ele será, aquela determinada versão vai ser descontinuada. Então aqui nesse estilo de arquitetura, você tem essa liberdade de, em vez de sair migrando toda a sua aplicação, como faria ali no monolito, vamos atualizar a versão de um único serviço menos crítico e testar ali essa tecnologia. Deu certo? Vamos passar a migrar os demais. Então esse é um outro tipo de objetivo para essa liberdade tecnológica.

A reusabilidade, você passa aqui a reutilizar as suas funções de negócio, as suas capacidades, sem a necessidade de ficar replicando ali código entre aplicações. E geralmente essa reusabilidade é feita através de APIs para consumo desses microserviços. E um outro item aqui é a questão da resiliência. É um estilo de arquitetura que fornece ali uma melhor tolerância a falhas. Então a falha de um componente individual, de uma capacidade de negócio específica, que não seja crítica para o negócio, por exemplo, ela não deveria afetar ali o todo. Você tem ali componentes independentes e essa flexibilidade de tratar melhor a questão da tolerância a falhas. Uma aplicação mais resiliente. Diferente do monolito, onde a falha de uma função, de uma capacidade de negócio, pode afetar o todo. Porque está todo mundo ali no mesmo processo, no mesmo bloco. Então aqui uma visão geral de microserviços, os principais benefícios. Isso é o seu contexto em todo esse processo, na sua importância num processo de modernização de uma aplicação.

Um outro tópico que é um tópico extremamente importante aqui são as APIs. As APIs são um formato padrão de comunicação entre esses diferentes serviços que vão compor as suas aplicações, as suas jornadas de negócio. É através dessas APIs que a gente vai fazer a exposição dessas capacidades para consumo. De toda a sua regra de negócio vai ser exposta através de APIs. Essa frase aqui resume bem a importância das APIs nesse processo: "Tão importante quanto compartilhar serviços é focar em como eles serão compartilhados." E para isso, tanto as APIs quanto um API Gateway, por exemplo, exercem um papel fundamental. E por isso é importante tratar suas APIs como produtos de negócio. Definir toda uma estratégia adequada para suas APIs, olhando sempre para questões de segurança e controle. Com toda a governança e monitoração necessária para fazer uma exposição segura e governada das suas capacidades de negócio.

Um outro tópico que é importante também, quando se fala de uma aplicação moderna, principalmente nesse contexto de se adaptar ao ritmo de mudanças do mercado, é uma arquitetura orientada a eventos. Que é um estilo de arquitetura que permite uma comunicação assíncrona. Uma aplicação, um serviço que produz uma informação, produz ali um evento, ele não precisa necessariamente conhecer a aplicação que vai consumir aquele evento. Então você temesse, através desse estilo de arquitetura, você consegue aqui um desacoplamento dessas partes envolvidas. Um exemplo comum que nós temos encontrado aqui em nossos clientes, onde esse cenário, esse estilo de arquitetura atende bem os requisitos, é quando se tem ali, por exemplo, diferentes aplicações de mercado desenvolvidas por diferentes fornecedores, que de alguma forma elas precisam se comunicar.

Então imagina que você tem ali um RP, que ele vai produzir uma informação, por exemplo, um novo cliente cadastrado, e essa informação precisa ser sincronizada também com o meu sistema de CRM. Mas são sistemas distintos, aplicações distintas desenvolvidas por fornecedores distintos. E nem sempre é fácil, às vezes você tem um alto custo para customizar essas aplicações prontas para se conversarem, principalmente quando são de fornecedores distintos, ou até mesmo, às vezes, a impossibilidade de fazer essa integração por não ser parte da estratégia daquele fornecedor alterar a aplicação dele para chamar, integrar com um outro fornecedor, até mesmo um concorrente.

E para isso, esse estilo de arquitetura... Mas geralmente nessas aplicações fornecem algum tipo de interface de integração, geralmente APIs. Então você tem as APIs disponíveis tanto do RP ou até mesmo web service, se for o caso. Depois a gente vai explorar aqui um dos padrões de integração que foca bastante nesse cenário aqui. Ou APIs ali também do seu CRM.

E através daqui de uma plataforma que suporte esse estilo de arquitetura orientado a eventos, você pode integrar de forma bem mais flexível e totalmente desacoplada dessas aplicações. Você pode gerar um evento a partir do cadastro de um cliente ali no seu RP. E através da plataforma que vai suportar a arquitetura de eventos, que vai fazer todo o tratamento do evento, garantir a segurança ali nessa comunicação, políticas de retentativas no caso de alguma falha de entrega de informação, e a garantia da entrega daquele evento.

Então a plataforma é quem vai disponibilizar essa informação, seja através de um consumo, ou através de estimulando aquela aplicação ali via APIs, entregar aquela informação para o sistema de CRM ali, por exemplo. Fazendo ali as conversões, transformações necessárias. Então você tem ali uma grande flexibilidade de integrar aplicações reutilizando as APIs fornecidas ali por elas, através de uma plataforma que permita esse desacoplamento entre as aplicações.

Bom, e agora que a gente comentou aqui rapidamente, uma visão geral de tecnologias de micro serviços, APIs e uma arquitetura orientada a eventos, é importante a gente falar um pouco aqui também sobre Compose of Enterprise.

O que é Compose of Enterprise? É um conceito introduzido pelo Gartner, onde ele diz que uma empresa que entrega resultados e se adapta ao ritmo de mudanças do mercado. E ela faz isso através da combinação de capacidades de negócio, que o Gartner chamaria de PBCs, Package Business Capabilities. E esses PBCs são blocos que compõem ali a sua aplicação e que representam de forma clara uma capacidade de negócio. Representam de tal forma que aquela capacidade de negócio seja, por exemplo, reconhecida por um usuário de negócio.

Mas então a gente pode até se perguntar, um PBC aqui é um bloco de construção organizado ali em capacidades de negócio. Qual é a diferença então de um microserviço? Estamos falando aqui em blocos de construção, capacidades de negócio, não estamos falando da mesma coisa? Então, no caso do PBC, qual seria a diferença?

O PBC é uma coleção de esquemas de dados, de serviços, APIs e canais de eventos. Um PBC pode ser composto por mais de um serviço, por mais de um microserviço, por exemplo. E eventualmente alguns desses microserviços têm responsabilidades mais internas, mais técnicas ali às vezes, e que não fazem sentido expor esses microserviços para consumo por aplicações externas àquele PBC, àquela aplicação.

Para isso, nós temos ali essa camada de APIs e canais de eventos que vão fornecer a granularidade necessária para aquele PBC, para aquela capacidade de negócio, para

que seja exposta por consumo por outras aplicações, sejam aplicações internas, ou até mesmo ali aplicações de parceiros ou de clientes, né? Então essa é uma das principais diferenças aí, né? Ou a relação, né?

Entre um PBC e o microserviço, né? Então o PBC ele vai ser composto eventualmente ali por mais de um serviço, né? Então nem todos os serviços fazem sentido expor eles como uma capacidade de negócio.

Bom, e agora que a gente já comentou aqui rapidamente sobre o porquê das empresas, um dos principais motivos que levam as empresas a adotar uma jornada como essa e tivemos aqui uma visão geral sobre quais são as principais tecnologias envolvidas aqui, né? De microserviços, APIs, eventos e o conceito de composable enterprise e PBCs. Agora vamos falar um pouco sobre alguns padrões de modernização, né? Como eu posso modernizar a minha aplicação? Aqui eu vou explorar um pouco nessa apresentação três dos principais padrões aqui de modernização, tá? Existem diferentes referências, né? Quando a gente pesquisa sobre padrões de modernização. Esses aqui são os mais recorrentes quando se fala aqui principalmente desse cenário de adaptação a mudanças. Mas também existem outros padrões, né? Que eu não vou explorar aqui nessa sessão, mas eu vou comentar aqui rapidamente, né? Como, por exemplo, existem padrões que são mais focados ali na migração do ambiente de execução da sua aplicação, né? Você pode ter uma aplicação que está rodando no seu ambiente on-premises, no seu próprio data center e eventualmente você pode migrar o ambiente de execução dessa aplicação para um serviço de nuvem, né? Colocar um serviço gerenciado ali na nuvem, né? Seja num modelo de infraestrutura como serviço, né? Onde você provisiona ali servidores, hosts para hospedar a sua aplicação ou até mesmo num modelo de plataforma como serviço, no modelo PaaS, né? Onde você vai migrar a sua aplicação diretamente para uma plataforma gerenciada por um provedor de serviços de nuvem, né? Esses estilos de modernização, né? Mais focados, ou seja, ali em mudança da plataforma ou mudança ali do host, né? São alguns padrões que geralmente são mais focados em redução de custos de infraestrutura, né? Operação dessa infraestrutura. Mas, eventualmente, né? Elas podem fornecer muitos benefícios para empresas que estão iniciando a sua jornada para um ambiente em nuvem, uma jornada para a cloud. Então, pode ser bem interessante nesse sentido também. Mas como é um padrão que não foca muito na mudança interna da aplicação, em refatorar, evoluir o código interno da aplicação, eu não vou explorar muito aqui nessa apresentação.

Um outro padrão aqui também existente, antes de eu entrar aqui nesses três, é em relação à substituição de uma aplicação, né? O retirement and replacement. Onde o foco é, você tem ali uma aplicação legada, uma aplicação antiga, numa tecnologia onde, eventualmente, não se encontram tantos profissionais mais qualificados no mercado para poder fazer algum tipo de evolução. Então, às vezes, o que resta a algumas empresas é partir para um padrão de substituição. Então, você, eventualmente, tem ali um sistema interno que foi desenvolvido para atender seus processos de negócio interno, não está conseguindo evoluir, e vai migrar ali para um RP de mercado, desenvolvido por algum fornecedor. Esse é um padrão que exige um pouco mais de tempo, tem mais complexidade, é preciso reconfigurar os seus processos na nova aplicação, às vezes até mesmo adaptar a forma como você trabalha para se adequar a essas aplicações, dependendo da complexidade. E exige também um trabalho considerável, razoável, de migração dos dados. Como eu vou levar os dados do meu sistema antigo para o meu sistema novo? E também por ser um padrão que não foca muito na melhoria da arquitetura interna, estou substituindo, estou jogando fora um e adotando um novo, também não vou entrar muito no detalhe desse padrão aqui.

Então, agora eu vou explorar aqui um pouco mais, esses três padrões que estou mencionando aqui na nossa apresentação de hoje. O primeiro deles aqui, em relação à exposição de APIs, que é um cenário bem comum, que a gente tem encontrado aqui nos nossos projetos. Qual é o principal propósito aqui desse padrão? Eventualmente, as empresas, em muitos casos a genteencontra isso, as empresas vão possuir aplicações, sejam legadas ali, desenvolvidas internamente ou não, onde foi feito um alto investimento. Internamente ou não, onde foi feito um alto investimento naquela aplicação, seja de desenvolvimento ou aquisição disso de um fornecedor. E por mais que ela esteja em uma arquitetura de monolito, onde todas as funções de negócio, todas as capacidades de negócio estão presentes através de módulos no mesmo bloco, no mesmo processo, eventualmente essa aplicação está atendendo bem os meus processos de negócio, pelo menos a maioria deles, geralmente os processos internos de back-office. E eu ainda não tive esse retorno de investimento, de todo esse investimento que foi feito. E eu só preciso integrar essa aplicação com outras aplicações para compor novos processos, novas jornadas de negócio, e fazendo reuso dessas capacidades.

Então, para isso, o que propõe aqui esse padrão? Que você consiga, de alguma forma, expor APIs, expor essas capacidades de negócio através de APIs para que possam ser reutilizadas para a construção de outros cenários, outras jornadas.

O primeiro exemplo que a gente tem aqui, ele mostra aqui um exemplo de uma aplicação onde, de alguma forma, exista alguma interface de integração pronta para consumo. Então, mesmo que seja ali um monolito, as funções no mesmo bloco, eventualmente não vou conseguir tirar todo o proveito daqueles benefícios que eu citei lá no início, de uma arquitetura de microserviços. Mas, eventualmente, essa aplicação pode fornecer alguma interface pronta para consumo dessas funcionalidades. Nesse exemplo aqui, estamos colocando aqui uma aplicação que exponha as suas funcionalidades através de web service do protocolo SOAP. Então, eu posso consumir essas integrações através dessa interface, expondo isso no formato padrão, um formato padrão de comunicação, que é o de APIs, através de uma API Gateway, por exemplo, e tendo todos os recursos de segurança e controle que uma API Gateway possa oferecer para a gente.

No segundo exemplo aqui, nessa aplicação aqui do meio, a gente tem aqui a mesma representação de um monolito com as funções internas, seus módulos. E, eventualmente, aqui, nesse cenário, eu não tenho aqui uma interface de integração pronta para consumo. Não tem algo que eu possa só consumir, fazer alguma conversão, alguma transformação, e expor isso como API. Mas, eventualmente, pode ser que aquela aplicação, aquela tecnologia que foi utilizada, aqui estou citando alguns exemplos, Java ou .NET, mas qualquer outra ferramenta que forneça algum kit de desenvolvimento, algum SDK, que permita que a gente possa construir componentes intermediários, um adaptador, que pode até mesmo ser um microserviço esse adaptador, que vai fazer esse meio de campo, essa tradução aqui entre as funções de negócio daquela aplicação, num formato mais proprietário, através do seu kit de desenvolvimento, e permitir a sua exposição através de APIs. Então, esse cenário também é bem presente que a gente tem encontrado em alguns dos nossos clientes.

E o terceiro cenário aqui, também muito comum, onde a aplicação, eventualmente, não possua nenhuma interface pronta para consumo das suas integrações, e também ali possa não fornecer nenhum tipo de kit de desenvolvimento. Então, existem muito ainda cenários como esse. Então, eu tenho muita dificuldade ali de integrar com aquela aplicação. E também não posso, em função do investimento que foi feito, não posso fazer um trabalho de melhoria ou refatoração daquela aplicação. Mas, muitas vezes, você tem ali a possibilidade de fazer integrações diretamente com o banco de dados daquela aplicação.

E para isso, qual a abordagem que a gente tem feito em alguns dos nossos clientes? Você implementa um componente ali que atua como um conector, que ele sim vai ter a comunicação direta com o seu banco de dados. O seu banco de dados não precisa e não deve estar exposto diretamente para consumo externo, por questões de segurança ali, para evitar também um forte acoplamento entre as aplicações. Então, esse conector é ele quem vai fazer a comunicação com o seu banco de dados e converter as instruções de acesso ao banco, seja uma consulta ou uma atualização, ele vai converter isso em operações de umaAPI, para ser expostas ali, que podem ser expostas através de uma API Gateway com toda a segurança e o controle, a monitorização esperada. API Gate com toda a segurança e controle, a monitoração esperada. Quem está consumindo essa integração, ele olha para uma API, ele nem sabe que está comunicando diretamente com um banco de dados. E para isso existem até algumas ferramentas, plataformas prontas que podem auxiliar nesse processo. A própria Sensidia, por exemplo, possui o Sensidia Connector que auxilia muito, acelera muito esse tipo de integração em nossos clientes.

Então aqui é uma visão geral desse primeiro padrão aqui de modernização focado em exposição de APIs. Um ponto importante aqui para reforçar, antes de eu entrar aqui no próximo, a modernização de aplicações é uma jornada. Um único padrão não vai resolver os seus problemas, não existe ali uma bala de prata. Então provavelmente você vai precisar adotar diferentes padrões de modernização na sua jornada. Vai depender muito ali da sua necessidade, qual é o requisito de negócio que está exigindo ali uma mudança mais rápida do seu modelo de negócio. Quais são as aplicações envolvidas nessa jornada de negócio? A arquitetura dessa aplicação, se eu posso ou não mudar, se eu vou ter que expor API, se eu posso evoluir o código daquela aplicação. Você eventualmente vai até adotar aqueles padrões que eu comentei rapidamente lá no início, de migração de runtime, substituição de aplicação.

Então assim, um único padrão não vai resolver todos os seus problemas. É uma jornada onde diferentes padrões podem ser adotados, inclusive para uma mesma aplicação, adotar diferentes padrões ao longo do tempo. De repente começar com uma exposição de APIs, até que seja possível adotar um outro padrão.

Esse segundo padrão aqui se refere à questão da refatoração do monolito, da aplicação legada ali, em microserviços. Esse padrão consiste em você extrair esses módulos, essas funcionalidades do seu monolito e converter isso em serviços menores. E assim, podendo tirar proveito de todos aqueles benefícios de microserviços que eu mencionei lá no início, quando eu expliquei rapidinho ali uma visão geral sobre microserviços.

O importante aqui nesse padrão, geralmente se inicia pelo entendimento aqui da aplicação, entendimento da estrutura do código, como está codificada ali, como foi desenvolvida aquela aplicação. E dependendo da técnica que foi utilizada, dos padrões que foram utilizados, isso pode até facilitar esse trabalho aqui. Por exemplo, vamos pegar um exemplo de uma aplicação Java. Então, dependendo de como as classes Java daquela aplicação foram organizadas em pacotes, se já foi pensado lá no início, mesmo sendo monolito, se o design dessa aplicação já foi pensado ali nos domínios de negócio, tentando ter uma representação do negócio, isso pode facilitar essa tarefa aqui de extrair o código convertendo em serviços menores.

Um ponto importante aqui para ressaltar, apesar da imagem aqui passar uma arquitetura mais simples desse padrão, mas eventualmente vão existir ali dependências entre esses módulos, entre essas funcionalidades. Alguns serviços ali comuns dentro dessa aplicação. E não é algo trivial fazer essa quebra. Aí é onde está o maior desafio dessa técnica. Como quebrar ali essas dependências com serviços comuns entre esses módulos para conseguir realmente separar em serviços menores, ter os repositórios específicos de cada serviço, conseguir automatizar ali, implantar esteiras automatizadas de entrega contínua para cada serviço. Então, existe esse desafio aí nessa preocupação em como quebrar ali a divisão entre esses módulos e principalmente em serviços que sejam comuns, bibliotecas comuns ali geralmente entre esses serviços.

Um outro ponto a se considerar nesse padrão é em relação ao banco de dados da aplicação. Também é importante pensar nessa segregação. Como que eu vou resolver a segregação dos meus dados entre esses diferentes serviços, que vão ser extraídos ali do monolito. Então, até que se atinja ali um nível onde tem uma segregação completa ali dessas bases, cada serviço com sua base, você pode de repente ali inicialmente adotar alguma técnica, algum padrão intermediário.Por exemplo, num primeiro momento eu posso continuar usando o mesmo serviço ali de banco de dados, o mesmo gerenciador, e tentando separar pelo menos em esquemas de dados distintos, no mesmo gerenciador, mas tentando separar em esquemas de dados distintos, já fazendo esse exercício de separar qual dado é vinculado àquele módulo, naquela capacidade que foi separada, até que realmente eu consiga segregar ali o serviço e tirar um maior benefício dessa arquitetura.

E eventualmente, como a gente está falando aqui em aplicações mais distribuídas, serviços menores, independentes, mas é importante ressaltar que existem dados que vão ser compartilhados entre esses serviços, então existem dados comuns, eles não vão estar 100% isolados. Então você tem ali um serviço que vai cuidar de cadastro do cliente, mas o código do cliente vai precisar ser referenciado numa compra, no serviço de RH, então precisa ter algumas referências. Então existem alguns dados compartilhados.

Então é importante também nesse padrão de modernização ter em mente que eventualmente vai ser necessário adotar algumas técnicas, alguns padrões, algumas tecnologias para fazer todo o sincronismo desse dado, seja através de técnicas de integração ou até mesmo de técnicas de replicação de dados. Então esse é um ponto também sempre importante de ter em mente nesse padrão de extração de código, de refatoração do monolito em serviços menores.

E aqui um outro padrão, que é o estrangulamento do monolito, que apesar do nome estranho aqui, estrangulamento, é um padrão que conceitualmente, falando na ideia simples, e até com características semelhantes aqui ao padrão anterior. Então aqui, qual é o conceito aqui desse padrão de estrangulamento do monolito? Gradualmente eu vou substituindo as funções ali, as capacidades de negócio da minha aplicação, do meu monolito, por serviços menores, seja ali micro serviços. Eu vou substituindo gradualmente essas funções por esses novos serviços.

Um novo serviço, uma nova demanda que surgia durante o período de modernização, já deveriam nascer, aqui está até exemplificando aqui um serviço numa cor diferente, um serviço de vendas, de sales. Os novos serviços já deveriam nascer já nessa nova arquitetura, uma arquitetura mais moderna, com componentes menores ali e independentes.

E um ponto aqui também para se destacar nesse padrão de arquitetura, diferente aqui do padrão anterior, eu não preciso aqui necessariamente seguir a mesma tecnologia. No padrão anterior, como a gente estava falando de refaturação, eu estou pegando a mesma base de código, separando ela, fazendo algumas quebras ali. Aqui não, aqui eu não tenho essa necessidade. Eventualmente, o meu monolito está naquele cenário que eu comentei anteriormente, onde foi utilizado algum produto que vai ser descontinuado, ou uma tecnologia muito antiga que está tendo alguma restrição de escalabilidade, de performance, e que também ali possa nem encontrar mais tantos profissionais no mercado que possam evoluir aquela aplicação.

Então aqui, diferentemente do padrão anterior, eu posso construir os novos serviços em linguagens totalmente diferentes. O serviço de compras, de supply chain, eu posso construir, imagina que eu tenho meu monolito em Java, eu posso construir os novos serviços, por exemplo, em Node, eu não tenho essa mesma obrigatoriedade. Então eu tiro proveito daqueles benefícios que eu comentei lá no início de microserviço.

E reforço aqui novamente, a ideia aqui não é que você saia desenvolvendo os microserviços cada um em uma linguagem, continua sendo importante ter ali o seu padrão, a sua arquitetura de referência, mas também ter a liberdade para fazer experimentações de tecnologia. Então esse aqui é o principal conceito aqui, desse padrão aqui, apesar do nome estranho, estrangulamento, mas esse conceito aqui relativamente simples.

E aqui também fica aquele mesmo ponto de atenção do padrão anterior em relação ali à base de dados. Eu preciso também segregar essa base de dados e preciso também ali conviver nesses dados comuns, desses novos serviços, com aqueles serviçosque ainda estão dentro do meu monolito, de forma ali mais acoplada na minha aplicação. Então eu preciso também pensar em técnicas para manter o sincronismo desses dados, né? Seja técnicas de integração ou até mesmo ali, durante um tempo, ali, um período de convivência, se for o caso, até mesmo técnicas de replicação desses dados.

Então existe também esse ponto de atenção, uma característica semelhante com o padrão anterior. Como eu comentei aqui, né? A modernização de aplicações, ela é uma jornada, né? Então um único padrão aqui não vai resolver os seus problemas. Então provavelmente você vai precisar adotar diferentes padrões de modernização, dependendo de qual processo de negócio você precisa evoluir, alterar para suportar uma mudança. O contexto atual da sua aplicação, o contexto a médio prazo da sua aplicação pode ser outro e ser mais interessante adotar um outro padrão. É sempre ter em mente que você vai precisar adotar mais de um padrão. Provavelmente até mesmo aqueles que eu só mencionei lá no início e não explorei aqui.

E para isso, né? Existem também outros aspectos extremamente importantes que precisam ser observados, né? Como, por exemplo, a entrega contínua. É extremamente importante que essas aplicações, esses serviços menores, tenham essa capacidade de entrega contínua, né? Com versionamento, repositório de código adequados, as esteiras de automação de entrega contínua, a integração contínua do código para verificar a qualidade, segurança contra vulnerabilidades. Então, sempre a gente precisa ter em mente em ter essa questão da entrega contínua e procurar sempre ao máximo automatizar essa entrega.

A questão da segurança, que é extremamente importante, principalmente quando a gente fala em serviços menores, que representam as suas capacidades de negócio. Então, você está expondo o seu negócio para que alguém consuma, né? E está expondo agora através de diversos serviços, né? Para poder compor a sua empresa, no conceito de compor uma enterprise, os PBCs, né? Eu estou expondo diversas capacidades para compor a empresa. Então, preciso fazer isso de uma forma segura, né? Eu preciso garantir que somente as aplicações autorizadas que deveriam ter acesso àquela informação, né? Aquele serviço, que somente elas realmente estão acessando isso, né? Que sejam autorizadas a consumir aquela informação, né? Então, preciso pensar na segurança desde o design ali do meu serviço.

A governança é um outro tema ali extremamente importante, né? Apesar de todos aqueles benefícios que eu citei lá no início, de uma arquitetura de micro-serviços, é importante ter em mente que existem também algumas implicações desse estilo de arquitetura, né? Uma delas é a quantidade de componentes, a quantidade de serviços que vão existir. Você tem diferentes serviços que vão representar a sua aplicação. Diferente do monolito, né? Que tem ali um bloco que contenha as suas capacidades de negócio, né? Então, é preciso conhecer quais são os serviços, ter um catálogo adequado desses serviços, dessas APIs, ter os papéis e responsabilidades bem definidos, né? Conhecer também quais são esses serviços. Até fazendo um link aqui da governança com a segurança, né? Eu preciso ter um catálogo adequado para conseguir até mesmo pensar na segurança desses serviços, né? Eu não consigo aplicar segurança daquilo que eu não conheço, né? Então, é extremamente importante aqui o papel da governança nessa jornada como um todo, né?

E um outro ponto aqui é a questão da observabilidade, né? De novo aqui a questão dessa implicação da quantidade de serviços disponíveis, né? Vou ter mais componentes para observar, para monitorar, para operar, né? E por isso aqui sempre é importante pensar na observabilidade desses serviços e, na medida do possível, usar os recursos tecnológicos disponíveis, né? Seja ali da própria aplicação ou da plataforma em si para te auxiliar nesse processo, né? Então, eu preciso saber adequadamente quais são esses serviços, como eles estão respondendo ali o meu negócio, se está com meus requisitos não funcionais ali adequados e tudo isso através ali de uma monitoração adequada com logs, métricas agregadas que representam o comportamento desses serviços, toda a rastreabilidade através de traces ali na comunicação distribuída desses microserviços, as transações de negócio agora estão distribuídas entre diferentes serviços. Então, eu preciso conseguir observar o que está acontecendo ali ao longo de todos esses serviços que compõem as minhas aplicações, que compõem as minhas jornadas de negócio.

E por último aqui é a questãoda resiliência, né? Que é uma arquitetura mais tolerante a falhas, né? E eu preciso ali de alguma forma também tirar um maior proveito desse benefício. Um serviço, por exemplo, que não seja tão crítico, não deveria, uma falha nele, não deveria afetar serviços de missão crítica da minha empresa. Tem um exemplo aqui de um aplicativo de banco. Um serviço que não seja tão crítico, por exemplo, uma recomendação de produtos de crédito. Uma falha nele não deveria afetar minha experiência de como usuário para funções críticas, como ver o meu saldo ou fazer um pagamento, fazer um pix.

Então a gente precisa sempre aqui tirar o proveito desse benefício, dessa arquitetura, e através de muitos testes, técnicas de resiliência na minha aplicação, e fazer muitos testes para realmente garantir que a experiência do usuário final, que a aplicação que suporta aquela jornada, que ela realmente seja resiliente.

Então aqui só uma visão geral desses outros aspectos importantes para se olhar, independente de qual seja o padrão de modernização adotado.

Bom, e aqui agora eu vou falar rapidamente sobre a Sensídia, e como a gente pode ajudar aqui nesse processo de modernização de aplicação da sua empresa. A Sensídia é uma referência nacional do mercado de APIs e microserviços, tanto através da nossa plataforma de integração moderna, quanto com os nossos serviços de consultoria especializada e nossos serviços profissionais. E hoje a gente está presente tanto na América Latina, na Europa e também aí nos Estados Unidos. Então a gente está num forte processo de expansão global.

Dentre os produtos aqui da nossa plataforma de integração moderna, eu queria fazer um destaque aqui sobre a nossa plataforma de gestão de APIs, o Sensídia API Platform, e a nossa solução de Service Mesh, o Sensídia Service Mesh, que através da combinação de APIs e microserviços, a gente consegue auxiliar aqui através da nossa plataforma, todo esse processo aqui de modernização de aplicações, suportando a gestão e o suporte ali, tanto do tráfego que a gente chama ali de tráfego norte-sul, que é aquele tráfego externo às suas aplicações, que geralmente chegam ali através dessas APIs, e quanto o que a gente chama ali de tráfego leste-oeste, que é o tráfego que ocorre entre os seus serviços internos, os seus microserviços.

Lembrando aqui aquela questão que eu comentei lá sobre Composable Enterprise, IPBCs, um PBC, um Package Business Capability, ele vai ser composto por mais de um serviço, e nem todos esses serviços precisam ser expostos, alguns são mais internos ali, então só alguns vão ser expostos ali no tráfego norte-sul. A maioria deles vai continuar ali no tráfego leste-oeste, comunicação interna. E mesmo nessa camada de tráfego interno, a gente precisa também olhar ali a observabilidade e segurança ali de forma adequada. E para isso a nossa plataforma também consegue auxiliar as empresas nessa necessidade.

E dentro aqui do nosso serviço de consultoria especializada, eu queria só fazer um destaque em relação ao nosso assessment de arquitetura moderna, onde a gente faz um trabalho bem bacana ali de entendimento das dores dos nossos clientes, entendimento dos objetivos, estratégia de uma determinada jornada de negócio, mapeando também a arquitetura atual dele, identificando os possíveis gaps existentes, e propondo e auxiliando na implementação de um roadmap de uma arquitetura moderna baseada em APIs, eventos e microserviços. Tudo isso baseado num roadmap bem claro, com níveis de maturidade bem definidos.

Novamente aqui eu menciono a questão dos links que vão estar disponíveis aqui na descrição do vídeo, onde você pode até encontrar maiores informações aqui sobre os nossos roadmaps, aqui o nosso assessment, tanto no contexto de mais integração, ele focado nas APIs, nos eventos, como também na parte de microserviços e desenvolvimento moderno de aplicações, com esteiras de DevOps automatizada, um service mesh. Então você pode encontrar maiores informações também sobre essa nossa oferta aqui, essa nossa oferta de serviços, totalmente focada nesse contexto de modernização de aplicações.

Bom, pessoal, era isso que eu tinha para falar hoje, sobre a modernização de aplicações. Espero que vocês tenham gostado, que eu possa ter contribuído com um pouco deinformação. E contem com a Sensedia para ajudarem vocês nessa jornada de transformação digital, de modernização das suas aplicações. Até mais!

>Nada de transformação digital, de modernização das suas aplicações. Até mais!

‍