O que é relatório de microsserviços?

Relatórios de microsserviços são aqueles criados a partir de uma arquitetura de microsserviços. Embora a arquitetura de microsserviços ofereça muitos benefícios às organizações, ela cria desafios para a geração de relatórios devido à sua natureza fragmentada.

O que é um modelo de microsserviço?

Para compreender os relatórios de microsserviços, deve haver um bom entendimento da arquitetura por trás deles. Uma arquitetura de microsserviços é um sistema baseado em nuvem onde o sistema de software de uma organização é composto por vários componentes menores. Esses serviços ou componentes podem ser implantados de forma independente, mas estão vinculados entre si até certo ponto, geralmente usando interfaces de programação de aplicativos (APIs). Semelhante ao funcionamento de um cérebro, os serviços são como células cerebrais, ligadas entre si por sinapses (APIs) que permitem a comunicação de informações de uma célula para outra. Cada um desses microsserviços é responsável por uma ação ou requisito específico e é implantado automaticamente quando necessário.

Todos esses serviços possuem seus próprios bancos de dados e não compartilham informações de um banco de dados central como outros sistemas fazem. Isso é chamado de 'delimitado', com tudo o que é necessário para que esse serviço funcione vinculado ao aplicativo.

Esta natureza delimitada é importante para garantir que não haja acoplamento não intencional de serviços. Se os esquemas de dados forem compartilhados entre os serviços, uma alteração em um deles deverá ser replicada em todos os esquemas de dados subjacentes. Ao manter tudo separado, isso significa que as mudanças são limitadas, existe total autonomia dos serviços e a arquitetura mantém toda a sua agilidade.

As organizações optam por usar microsserviços por vários motivos. Os aplicativos independentes podem ser facilmente atualizados e alterados, e novos recursos podem ser adicionados rapidamente. Diferentes equipes podem operar diferentes pilhas de aplicativos ou programas que operam sob a mesma esfera, agregando enorme agilidade ao modelo de negócios.

Também pode ser uma arquitetura muito econômica. As APIs são gratuitas ou de baixo custo; programas individuais podem ser software como serviço (SaaS) e pagos pelo usuário. É totalmente escalonável, e não há grandes requisitos de infraestrutura.

Empresas que usam arquitetura de microsserviços incluem Amazon, Netflix, Uber e SoundCloud. É verdadeiramente uma estrutura de software que permite enorme flexibilidade e escalabilidade num modelo de negócios.

No entanto, as desvantagens dos microsserviços são que as APIs criam mais riscos para ataques cibernéticos e a diversidade de linguagens de programação e de comunicação entre os aplicativos. Mas o maior problema diz respeito aos relatórios. Cada aplicativo ou programa possui seu próprio banco de dados. Então, como um usuário extrai todos os dados dos bancos de dados para gerar relatórios? Este conceito de extrair dados de cada aplicativo não preserva o valor central do contexto delimitado.

Relatórios de microsserviços

Se uma organização estiver executando uma arquitetura de microsserviços, um modelo simples poderia considerar que ela possui programas diferentes para:

• Finanças e faturamento
• Ferramenta de fluxo de trabalho
• Programa de vendas
• Sistema de folha de pagamento

Cada um desses microsserviços possui seu próprio banco de dados. As APIs funcionam para vincular esses programas para que possam operar em uma única interface. No entanto, os problemas começam quando são necessários relatórios que extraem dados de vários bancos de dados.

Um exemplo é quando os salários são baseados em trabalhos concluídos e faturados. A ferramenta financeira precisa de acesso à ferramenta de fluxo de trabalho e só então a ferramenta de folha de pagamento terá informações precisas para pagar os funcionários. Se uma empresa quiser gerar um relatório mostrando o trabalho em andamento versus as vendas concluídas do mês, ela precisará acessar três programas diferentes.

Isso torna-se ainda mais complexo quando há um grande número de microsserviços. A Netflix, por exemplo, tem mais de dois bilhões de solicitações de borda de API por dia, distribuídas por seus mais de 700 microsserviços. O Uber usa mais de 1.300 microsserviços. Com um grande número de serviços, os relatórios tornam-se mais complexos.

Desafios dos relatórios de microsserviços

Existem três desafios principais nos relatórios de microsserviços.

Problemas de desempenho

Se uma empresa tem dois bilhões de solicitações de API por dia para funções de negócios, imagine o quantos os relatórios serão uma sobrecarga. Se uma ferramenta de relatório extrai dados de diversas fontes, geralmente centenas de vezes por dia, como isso afetará o sistema? Isso vai desacelerar consideravelmente os processos ou, possivelmente, resultar em timeout dos processos.

Antipadrão

A própria ideia da arquitetura de microsserviços é que todo serviço seja delimitado. Ou seja, cada aplicativo é um miniprograma separado. Ele contém tudo o que precisa e opera dentro de seus próprios limites. Não precisa de acesso a mais nada para completar suas funções.

Quando os relatórios exigem que os serviços compartilhem seus bancos de dados, eles se tornam antipadrão.

Diferentes modelos e tipos de dados

Se cada serviço for escrito em uma linguagem de programação diferente, será necessário haver uma camada extra de comunicação entre os serviços para permitir a compreensão. E então, se os dados forem apresentados de forma diferente de outros, precisarão ser manipulados automaticamente para que possam ser digeridos e utilizados pela ferramenta de relatórios.

Dados conflitantes

Como cada serviço possui seu próprio banco de dados, pode haver redundância, duplicação ou conflitos de dados. Por exemplo, se um fornecedor também for cliente e tiver o mesmo endereço físico, mas um estiver incorreto no sistema, isso poderá causar problemas na compilação dos dados.

O que os relatórios para microsserviços exigem

Bons relatórios são essenciais para a saúde e o crescimento de uma organização. Um bom sistema de relatórios precisa ter os seguintes elementos:

Fácil utilização

Os relatórios devem ser simples de executar. Usando um painel central, os relatórios devem facilitar a seleção de parâmetros e a aplicação dos dados relevantes. Como todos os microsserviços estão sob um mesmo painel, isso é conseguido facilmente.

Uma única fonte de verdade

Para que os relatórios sejam precisos, os dados precisam estar corretos. Deve haver uma única fonte de verdade para os dados, sem duplicações ou informações antigas ou incorretas, e tudo o que o relatório precisa deve estar lá. Este é o maior desafio para os microsserviços, uma vez que os aplicativos são separados e acoplados de forma tênue.

Oportuno

Em um mundo onde tudo é instantâneo, os relatórios precisam estar atualizados ao minuto. Quando há liquidações de fim de ano, uma mudança no ambiente de trabalho ou um comportamento diferente do cliente, essas mudanças precisam ser observadas e abordadas o mais rápido possível. Isto também apresenta desafios ao modelo de microsserviços, dependendo de como os dados são acessados.

Rápido

Se um relatório levar horas para ser executado e sobrecarregar os recursos, será uma barreira significativa para o sucesso dos sistemas de relatórios. A execução simultânea de milhares de APIs para acessar dados cria uma barreira considerável para bons relatórios na arquitetura de microsserviços.

Automação

O sistema de obtenção, extração e processamento dos dados e a execução dos relatórios devem ser altamente automatizados. Os usuários não devem ter que acessar o back-end, executar operações manuais ou realizar manipulações manuais nos dados.

Fácil de entender

Apresentar relatórios em linhas de dados granulares nem sempre é o que é necessário, nem é a melhor forma de compreender as informações. Em vez disso, para que os relatórios sejam facilmente entendidos por uma variedade de usuários, os dados devem ser apresentados em gráficos, tabelas e imagens que mostrem rapidamente tendências, padrões e números.

A capacidade de detalhamento

Se um usuário ou apresentador tem um gráfico simples, mas precisa entender como e por que algo aconteceu, é necessário que haja funcionalidade para permitir que os usuários vejam dados granulares. As organizações precisam ser capazes de detalhar facilmente as informações para identificar problemas, pontos fortes e anomalias.

Funcionalidade de Inteligência Artificial (IA)

Não faz sentido ter dados se uma organização não puder criar melhorias úteis com base neles. Para ativar esta função, é necessário que haja funcionalidade de IA para que os dados se transformem em informações e previsões. Depois que os dados são coletados, é fácil adicionar funcionalidade de IA, dada a natureza segmentada dos microsserviços.

Soluções potenciais para relatórios de microsserviços

Há diversas opções disponíveis para permitir relatórios em uma arquitetura de microsserviços. A solução correta para uma organização dependerá de muitos fatores diferentes, e a resposta não é única.

O primeiro passo é encontrar os serviços corretos. O modelo de microsserviços significa que cada tarefa requer um aplicativo ou programa diferente. Esses microsserviços ficarão ao lado de todos os outros aplicativos e programas. É provável que uma empresa precise de um serviço que extraia ou receba dados, outro com funções de relatório e outro com recursos de IA.

Uma vez instalados esses serviços, é uma questão de extrair os dados dos outros microsserviços e criar os relatórios necessários.

Conexões diretas com bancos de dados

O serviço de relatórios conecta-se diretamente com outros microsserviços, recupera as informações relevantes de seus bancos de dados e as canaliza para um data warehouse. Isso é simples, mas significa que qualquer alteração em um esquema de banco de dados também exigirá uma alteração adicional no serviço de relatórios. Isso também quebra o contexto delimitado que é tão importante na arquitetura de microsserviços.

Modelo pull HTTP do serviço de agregação

Este serviço usa APIs para se conectar aos microsserviços relevantes. Ele acessa as informações necessárias e as canaliza por meio do data warehouse e da ferramenta de relatórios. No entanto, esse método está sujeito a desempenho lento e erros de tempo limite 504. Cada serviço adicional com o qual ele precisa se comunicar adiciona mais carga ao sistema, agregando diversas origens de dados que criam enormes problemas de desempenho.

Mais uma vez, por ser um modelo pull, ele viola o contexto delimitado.

Pull em lote e banco de dados dedicado

Nessa estratégia, um comando é executado de acordo com um cronograma, e as informações são extraídas em lotes de todos os bancos de dados de microsserviços relevantes. Esses dados são então atualizados em massa no banco de dados de relatórios. No entanto, assim como acontece com a conexão direta com o banco de dados, qualquer alteração no esquema poderá interromper todo o trabalho em lote. Cada vez que o esquema muda, as funções em lote também precisam ser atualizadas.

Outro problema é que, sendo um modelo pull, é contrário ao contexto delimitado e pode não resultar em relatórios oportunos. Se a solicitação pull estiver vinculada ao momento em que a carga estiver mais leve, às 2h, será apenas uma atualização por dia.

Banco de dados dedicado com push assíncrono de eventos

Isto é mais complicado, mas produz melhores resultados e não viola o modelo delimitado. Um microsserviço de processador de eventos recebe atualizações quando algo em outro serviço é atualizado ou alterado. O aplicativo, em vez de extrair informações dele, envia notificações de eventos. Isso significa que um serviço de captura de dados é notificado sobre quaisquer atualizações relevantes, e o banco de dados é atualizado. A partir daí, um serviço de relatórios pode executar relatórios conforme necessário.

Os benefícios deste método de relatório incluem:

• Preservação dos princípios da arquitetura delimitada de microsserviços. O serviço de relatórios não está escutando os aplicativos nem extraindo informações.
• Garantia de que os relatórios resultantes estejam atualizados porque o serviço de relatórios é notificado sobre eventos ou atualizações de informações.
• Filtragem das informações que não são necessárias em todo o serviço de captura de dados.
• Agregação de dados em um formato que o serviço de relatórios possa utilizar por meio do serviço de captura de dados.
• Fornecimento de relatórios assíncronos para evitar cargas pesadas de processamento, esgotamento do tempo limite ou acoplamento temporal.

Como resolver dados conflitantes

Como pode haver literalmente milhares de bancos de dados, é quase certo que haverá duplicações de dados ou dados incorretos ou falhos. Resolver isso é importante para criar relatórios precisos. Existem algumas soluções diferentes para esse desafio.

Um serviço para atualizar bancos de dados

Se houver um serviço intermediário que reconheça quando uma informação é atualizada, ele poderá enviar essa atualização para os outros serviços. Por exemplo, se o endereço físico de um cliente foi atualizado, essa informação é enviada para todas as instâncias das informações desse cliente. Isso pode ser incrivelmente complexo e exigir mais largura de banda no sistema, além de ser fora do padrão.

Escolha uma única fonte de verdade para cada tipo de dados

Como cada serviço nesta arquitetura executa uma única tarefa, o banco de dados para ele não precisa ser abrangente. O departamento de cobrança precisa saber o endereço postal, enquanto o departamento de vendas precisa do endereço físico para enviar o produto. Nomeie um serviço para ser a única fonte de verdade para esse dado.

Relatórios de microsserviços requerem planejamento

Existem vários desafios na criação de relatórios de microsserviços; esta não é a arquitetura mais simples para relatórios. Até mesmo a manutenção de dados consistentes requer mais planejamento e reflexão do que outras arquiteturas tradicionais. No entanto, é possível gerar relatórios mantendo os princípios dos serviços delimitados.

Se uma organização quiser adotar uma estrutura de microsserviços, a equipe de TI precisa realizar um planejamento e trabalho de base consideráveis para garantir que a consistência e a precisão dos dados estejam em primeiro lugar, seguido por um foco na rota dos dados enviados dos serviços de origem para outros serviços que criam data lakes como uma origem de dados e, em seguida, processar esses dados para que se tornem os relatórios necessários.

Considerando os enormes benefícios que o modelo de microsserviços pode oferecer a uma organização, vale a pena lidar com a complexidade extra nos relatórios. Todos os desafios podem ser superados com reflexão e planejamento.

Recursos relacionados