Como solucionar desafios de gerenciamento de dados em um mundo de microsserviços

Trabalhar com microsserviços significa não compartilhar dados, para evitar o “acoplamento” – por outro lado, não compartilhar dados em circunstância nenhuma gera mais custos e complexidade.

Pergunte a qualquer líder de TI sobre o futuro do desenvolvimento de aplicativos empresariais e ele provavelmente responderá “microsserviços”. Popularizados por grandes empresas da Web, os microsserviços estão sendo adotados em muitas áreas de negócios.

Microsserviços são módulos refinados e leves que fazem uma única coisa bem e são conectados para criar aplicativos maiores. Eles combinam bem com ambientes nativos da nuvem. É fácil ver o apelo dos microsserviços. Os desenvolvedores podem trabalhar em paralelo usando a linguagem de programação, os frameworks e formatos de dados que desejarem. Podem implantar e escalar os componentes de aplicativos criados em torno de microsserviços sem precisarem coordenar com outros. Do ponto de vista da empresa, o apelo é por mais funcionalidades, fornecidas mais rapidamente.

Mas os usuários pioneiros descobriram que há um grande desafio a enfrentar: o gerenciamento de dados. Aplicativos empresariais típicos compartilham informações através do compartilhamento do banco de dados. No mundo dos microsserviços, isso é inaceitável – tudo é idealmente feito com APIs (interfaces de programação de aplicativo), eventos e mensagens.

Um microsserviço ideal isolaria completamente seus dados (encapsulamento de dados) do mundo externo e somente os exporia através de uma API. O objetivo maior é evitar o “acoplamento de dados”, por meio do qual uma mudança na maneira como um microsserviço representa seus dados deve ser comunicada e coordenada com outros desenvolvedores de microsserviços. 

Como qualquer pessoa que tenha atualizado um grande aplicativo empresarial sabe, o acoplamento e as dependências de dados podem reduzir a velocidade da introdução de novos recursos.

Mas insistir que microsserviços não podem compartilhar dados sob nenhuma circunstância inevitavelmente causará mais custo e complexidade do que permitir certas formas de compartilhamento de dados controlado. É possível, e até mesmo desejável, satisfazer as necessidades de os desenvolvedores trabalharem de forma independente, ao mesmo tempo em que se atendem às necessidades mais amplas da equipe maior de aplicativos.

Desafios do encapsulamento de dados

Ajuda pensar em termos de um aplicativo tipicamente grande, como um site de varejo, em que atualizações frequentes são necessárias. Primeiro, examinaremos os problemas típicos do gerenciamento de dados encontrados em microsserviços e depois sugeriremos uma maneira mais simples.

Certos elementos de dados, como informações de clientes e produtos, frequentemente são usados em muitos locais em um aplicativo grande. Em um design de microsserviços puro, um único microsserviço seria responsável por um único tópico, como informações do cliente e os elementos de dados associados, com todos os outros solicitando acesso e atualizações somente via uma API de propriedade do microsserviço.

Isso significa que os desenvolvedores devem considerar todas as necessidades potenciais de outros módulos à medida que desenvolvem seus microsserviços. Se um novo requisito surgir, o microsserviço proprietário da informação precisa ser atualizado. Voltando a nosso exemplo de site de varejo, talvez o microsserviço de informações do produto agora esteja sendo solicitado a fornecer informações adicionais a outros microsserviços, portanto precisa ser alterado. Essa necessidade de coordenar todos os usos potenciais de informações “próprias” pode afetar a produtividade do desenvolvedor e reduzir a velocidade de lançamento de novos recursos.

Outro desafio é a necessidade de análise de dados no aplicativo inteiro. Em um design de microsserviços clássico, os componentes de análise precisariam fornecer dados de cada componente relevante — extraindo, transformando e carregando dados relevantes de cada um conforme a necessidade. Além disso, cada microsserviço precisa produzir ou reter dados necessários para análise.

Para nosso aplicativo hipotético de varejo na Web, imagine que você queira uma visão horizontal de quão bem cada componente está funcionando a cada etapa da jornada do cliente. Isso implicaria analisar dados de vários módulos. Com uma abordagem de microsserviços típica, tempo e esforço adicionais são necessários para estabelecer uma visão analítica do aplicativo inteiro, tanto da parte da equipe de análise quanto dos microsserviços que a alimentam.

Mais difícil é o desafio de interromper transações comerciais de longa duração formadas por vários componentes — por exemplo, cancelar um pedido em caso de falta de estoque ou de não aprovação de crédito. No mundo convencional sem microsserviços, isso é feito com monitores de transação e confirmações de duas fases: ou a transação toda é um sucesso ou nenhuma parte dela tem sucesso.

Infelizmente, essa abordagem comprovada é considerada um “antipadrão” (a ser evitado a todo custo) no mundo dos microsserviços. Em vez disso, um processo de coordenação usa um “padrão saga” para coordenar transações complexas. Cada microsserviço participante precisa implementar uma funcionalidade de desfazer uma transação passada em caso de necessidade. Essa estrutura pode resultar em mais complexidade e maior chance de erro.

Por fim, o ambiente de gerenciamento de dados resultante pode ser operacionalmente complexo. Agora existem várias ferramentas de software de banco de dados, cada uma das quais deve ser instalada, configurada, monitorada, corrigida e atualizada. Existem muitos repositórios de dados, cada um dos quais precisando tornar-se altamente disponível, recuperável se necessário e protegido contra acesso não autorizado.

Uma maneira mais simples

Idealmente, haveria uma maneira mais simples de obter a velocidade e a produtividade de um modelo de microsserviços e, contudo, evitar a complexidade do gerenciamento de dados. O Oracle Database familiar é qualificado de forma incomparável para fazer isso.

Usando o Oracle Database, cada equipe de desenvolvimento fica livre para criar bancos de dados plugáveis, ou PDBs, usando o modelo de dados que preferir: JSON/XML, chave/valor, espacial/gráfico, objeto, relacional e outros. PDBs são bancos de dados lógicos, pequenos, leves e isolados que residem em um banco de dados de contêiner, ou CDB, maior.

PDBs podem ser expandidos de forma independente conforme a necessidade usando técnicas como in-memory e sharding (um tipo de particionamento de banco de dados). Eles podem ser copiados com facilidade e transferidos conforme a necessidade. PDBs também recebem o conjunto completo de recursos avançados do Oracle Database. Os desenvolvedores ficam assim livres para fazerem o que quer que seu microsserviço exija, com necessidade muito menor de coordenação com outros desenvolvedores.

O Oracle Database há muito oferece suporte a um recurso poderoso que minimiza o impacto do acoplamento de dados: a Redefinição Baseada em Edição (EBR). Com a EBR, os desenvolvedores ficam livres para alterar exibições e lógica conforme a necessidade, ao mesmo tempo em que preservam exibição e lógica herdadas para quem precisar deles. Atualizações em edições mais antigas ou mais novas podem ser propagadas com facilidade usando triggers.

Como essa abordagem ajuda nos desafios em torno do gerenciamento de dados de microsserviços?

Quando há a necessidade de que outra parte do aplicativo use certos dados (de clientes e produtos em nosso exemplo de varejo na Web), eles podem ser acessados diretamente, ou até mesmo atualizados, sem que o microsserviço proprietário dos dados precise ter conhecimento — caso assim se deseje.

Quando o desenvolvedor do microsserviço decide alterar como aquelas informações são representadas, não há impacto sobre outros módulos, que continuam a acessar uma edição anterior do banco de dados. Em algum momento, outros consumidores das informações daquele módulo podem ser atualizados, e as edições anteriores são descartadas. Dessa maneira, os desenvolvedores não são impedidos de fazer alterações conforme a necessidade.

Criar análise em todo o aplicativo também pode ser melhorado substancialmente. O ambiente de análise é livre para acessar diretamente dados de propriedade de microsserviços. Transformações de dados podem ser propagadas em bancos de dados plugáveis individuais sem alterar os dados subjacentes propriamente ditos. Data mining e machine learning complexas também podem ser propagadas para bancos de dados individuais com facilidade sem envolver desenvolvedores de microsserviços.

Há muito menos necessidade de operações familiares de extração, transformação e carregamento (ETL). Muito do trabalho pesado pode ocorrer no próprio banco de dados, perto dos dados. Os desenvolvedores ficam livres para alterar coisas, enquanto a análise continua a usar a exibição anterior até que seja conveniente fazer uma alteração. O resultado é análise melhor e mais rápida com muito menos complexidade e custo.

Quando se trata do problema complicado de cancelar transações complexas, existem novas opções atraentes. Coordenar processos pode ser feito usando “sagas” amigáveis a microsserviços, como antes, mas compensar transações que desfazem ações anteriores pode ser implementado de maneira opcional diretamente no banco de dados, em vez de exigir que os desenvolvedores do microsserviço façam esse trabalho. Adicionalmente, o enfileiramento de mensagens pode ser implementado em ainda outro recurso, o Oracle Advanced Queuing (AQ), que garante que as mensagens sejam entregues de maneira confiável e nada nunca se perca.

Finalmente, o ambiente operacional está muito mais simples que antes. Usando bancos de dados contêineres, há apenas um sistema de gerenciamento de dados para instalar, configurar, monitorar, corrigir e atualizar. Agora há um único mecanismo para fornecer alta disponibilidade e recuperabilidade, conforme a necessidade. E o Oracle Database fornece o conjunto mais avançado de recursos de segurança disponíveis — aplicados, impostos e monitorados de maneira uniforme em todo o seu ambiente.

Ambientes mais simples custam menos, exigem menos esforço e resultam em menos erros.

Diferentemente de abordagens clássicas de gerenciamento de dados de microsserviços, um banco de dados contêiner com vários bancos de dados plugáveis usa um único pool compartilhado de recursos de computação, rede e armazenamento — portanto é muito mais eficiente que várias ferramentas de gerenciamento de dados isoladas.

Essa eficiência também se aplica às habilidades. A maioria das organizações tem pessoas já familiarizadas com o Oracle Database.

O melhor dos dois mundos?

Muito do apelo de uma arquitetura de microsserviços é a velocidade: as equipes de desenvolvimento podem trabalhar de maneira independente, novos recursos podem ser adicionados rapidamente sem a necessidade de coordenação entre várias equipes. Mas fazer a mudança para microsserviços pode ser difícil — novas ferramentas, novas metodologias, novos processos operacionais e novas habilidades.

Embora evitar o acoplamento de dados certamente seja desejável, existe mais de uma maneira de conseguir isso. Usando os recursos avançados comprovados do Oracle Database (bancos de dados plugáveis, Redefinição Baseada em Edição, Advanced Queuing, in-memory, sharding, entre outros), as organizações podem concretizar os benefícios de aplicativos baseados em microsserviços com mais facilidade ao mesmo tempo em que evitam muito da complexidade e dos custos associados.

Artigo escrito por: Chuck Hollis – VP de Infraestrutura em Nuvem da Oracle

G&P e Oracle

A G&P é uma das maiores implementadoras de Soluções, Serviços Gerenciados e Projetos em Tecnologia Oracle.

Ao longo de vários anos de experiência na Implementação e Gestão dessas soluções, conta com uma equipe composta por arquitetos e implementadores de alto nível de conhecimento.

Gostaria de saber mais sobre o Oracle Database? Clique aqui e entre em contato com a nossa equipe.