Data Gateways na era Cloud Native

Atualmente, há muita empolgação a respeito de aplicações em 12 fatores, microservices e service mesh, mas não tanto em dados cloud native. O número de conferências, posts em blogs, boas práticas e ferramentas criadas especificamente para o acesso a dados cloud native é relativamente baixo. Uma das principais razões para isso é porque a maioria das tecnologias de acesso a dados é projetada e criada em um stack que favorece ambientes estáticos, ao invés da natureza dinâmica dos ambientes cloud e Kubernetes.

Este artigo explora as diferentes categorias de data gateways, desde os mais monolíticos até os projetados para a cloud e Kubernetes. Serão abordados quais são os desafios técnicos introduzidos pela arquitetura de microservices e como os data gateways podem complementar os API gateways para enfrentar esses desafios na era do Kubernetes.

Evolução na arquitetura de aplicações

A maneira como o código e os dados são gerenciados têm mudado na última década. Antigamente os front-ends eram desenvolvidos com Servlets, JSP e JSF. No back-end, o EJB, SOAP e gerenciamento de sessões no servidor eram as tecnologias e técnicas de última geração. Mas as coisas mudaram rapidamente com a introdução do REST e a popularização do Javascript. O REST nos ajudou a separar os frontends dos backends por meio de uma interface uniforme e solicitações orientadas a recursos, o que popularizou os serviços stateless e habilitou o cache de resposta, movendo todo o estado da sessão do cliente, para o cliente e assim por diante. Essa nova arquitetura foi a resposta para as enormes demandas de escalabilidade das empresas modernas.

Uma mudança semelhante aconteceu com os serviços de backend através dos microservices. O desacoplamento do frontend não foi suficiente, e o backend monolítico precisou ser desacoplado em um contexto delimitado, permitindo entregas independentes em ritmo acelerado. Estes são exemplos de como as necessidades de negócios pressionaram a evolução das arquiteturas, ferramentas e técnicas para uma entrega rápida de software em escala global.

Isso nos leva à camada de dados. Uma das motivações existenciais para os microservices é ter as fontes de dados independentes por serviço. Se existirem diferentes microservices que acessam os mesmos dados, em algum momento irão introduzir o acoplamento e limitar a escalabilidade ou entrega independente. Não é apenas uma base de dados independente, mas também heterogênea, portanto, qualquer microservice deve ser livre para usar o tipo de banco de dados que atenda às suas necessidades.

A evolução da arquitetura de aplicações traz novos desafios

Embora o frontend desacoplado do backend e a divisão de monólitos em microservices permitiram a flexibilidade desejada, acabaram criando desafios que antes não estavam presentes. A descoberta de serviços, o balanceamento de carga, a resiliência no nível da rede e a observabilidade, se transformaram nas principais áreas de inovação tecnológica abordadas nos anos seguintes.

Da mesma forma, novos desafios surgiram com a necessidade de criação de uma base de dados por microservice e a possibilidade de escolher diferentes tecnologias para o armazenamentos de dados. Isso se mostra cada vez mais com a recente explosão de dados e a demanda por acesso a dados, não apenas pelos serviços, mas por outras necessidades como relatórios em tempo real, inteligência artificial (AI) e aprendizagem de máquina (ML).

A ascensão dos API gateways

Com a crescente adoção dos microservices, tornou-se evidente que a operação de uma arquitetura desse tipo é complexa. A ideia de ter todos os microservices independentes parece perfeita, porém exige ferramentas e práticas que anteriormente não eram necessárias e nem existiam, dando origem a estratégias de entregas mais avançadas, como implantações blue/green, implantação canário e entregas no escuro. Com isso, surgiram a injeção de falhas e os testes de recuperação automática. E que, finalmente, deu origem à telemetria e ao rastreamento de rede avançados. Estes novos recursos introduziram uma nova camada que fica entre o frontend e o backend. Essa camada é ocupada principalmente por gateways de gerenciamento de API, descoberta de serviços e tecnologias de service mesh, e também por componentes de rastreamento, balanceadores de carga de aplicações e todos os tipos de proxies de gerenciamento e monitoramento de tráfego. Incluindo até projetos como o Knative, com recursos de ativação e redimensionamento para zero (do termo em inglês scaling-to-zero), impulsionados pela atividade de rede.

Com o tempo, ficou evidente que a operação em escala de microservices criados em um ritmo acelerado, requer ferramentas que antes não eram necessárias. Algo que foi totalmente tratado por um único balanceador de carga, precisou ser substituído por uma nova camada de gerenciamento avançado. Nasceu uma nova camada de tecnologia, um novo conjunto de práticas e técnicas e um novo grupo de usuários.

O caso dos data gateways

Os microservices influenciam a camada de dados nas duas dimensões a seguir. A primeira, cada microservice exige um banco de dados independente. Do ponto de vista da implementação prática, pode ser de uma instância de banco de dados independente para esquemas independentes e agrupamentos lógicos de tabelas. A regra principal é que apenas um microservice possui e acessa um conjunto de dados. E todos os dados são acessados ​​por meio de APIs ou eventos do microservice proprietário; A segunda, é através da proliferação do armazenamento de dados, possibilitando que os microservices sejam gravados em diferentes linguagens. Essa arquitetura permite que todos os sistemas baseados em microservices tenham uma camada de persistência poliglota. Com essa liberdade, um microservice pode usar um banco de dados relacional, outro pode usar um banco de dados de documentos e um terceiro pode usar um armazenamento em memória de chave-valor.

Embora os microservices ofereçam toda essa liberdade, novamente eles têm um custo. A operação de um grande número de armazenamento de dados tem um custo para o qual as ferramentas e práticas existentes não foram preparadas. No mundo digital moderno, armazenar dados de forma confiável não é suficiente. Os dados são úteis quando se transformam em insights e, para isso, precisam ser acessíveis de forma controlada. Especialistas em AI/ML, cientistas de dados e analistas de negócios precisam se aprofundar nos dados, mas os microservices focados em aplicações e seus padrões de acesso a dados não são projetados para essas demandas que exigem muita informação.

API e Data Gateways oferecem recursos semelhantes em diferentes camadas

Neste cenário, os data gateways podem ajudar. Um data gateway é como um API gateway, no entanto entende e atua na camada de dados físicos, e não na camada de rede. A seguir serão abordadas algumas áreas em que os data gateways diferem dos API gateways.

Abstração

Um API gateway pode ocultar a implementação de endpoints e ajudar a atualizar e reverter serviços sem afetar os consumidores do serviço. Da mesma forma, um data gateway pode ajudar a abstrair uma fonte de dados física, suas especificidades e ajudar a alterar, migrar, desativar, sem afetar os consumidores dos dados.

Segurança

Um gerenciador de API protege endpoints de recursos baseados em métodos HTTP. Um service mesh faz a proteção com base em conexões de rede. Mas nenhum deles pode entender e proteger os dados e o formato que está passando por eles. Um data gateway, por outro lado, entende as diferentes fontes de dados e o modelo de dados e atua sobre elas. Pode aplicar o role-based access control (RBAC) por linha e coluna de dados, filtrar, ofuscar e limpar os elementos de dados individuais sempre que necessário. Esse é um modelo de segurança mais refinado do que a segurança em rede ou no nível da API dos gateways de API.

Dimensionamento

Os API gateways podem fazer a descoberta de serviços, balancear a carga e ajudar no dimensionamento de serviços através de um orquestrador como o Kubernetes. Mas não podem escalar os dados. Os dados podem ser escalados apenas por meio de replicação e cache. Alguns bancos de dados podem replicar em ambientes cloud native, mas não em todos. Ferramentas criadas para fins específicos, como o Debezium, podem executar a captura de dados alterados dos logs de transações dos bancos de dados, e habilitar a replicação de dados para escalonamento e para outros casos de uso.

Um data gateway, por outro lado, pode acelerar o acesso a todos os tipos de fontes de dados através do armazenando em cache e do fornecimento de visualizações materializadas. Pode entender as consultas, otimizá-las com base nos recursos da fonte de dados e produzir o plano de execução com melhor desempenho. A combinação de visualizações materializadas e a natureza do fluxo da captura de dados alterados seria a melhor técnica de escalonamento de dados, mas ainda não há implementações cloud native disso.

Federação

No gerenciamento de API, a composição da resposta é uma técnica comum para agregar dados de vários sistemas diferentes. No que diz respeito a dados, a mesma técnica é referida como federação de dados heterogênea. Heterogeneidade é o grau de diferenciação em várias fontes de dados, como protocolos de rede, linguagens de consulta, recursos de consulta, modelos de dados, tratamento de erros, semântica de transações, etc. Um data gateway pode acomodar todas essas diferenças como uma camada de federação de dados integrada e transparente .

Schema-first

Os API gateways permitem o serviço contract-first e o desenvolvimento do cliente com especificações como OpenAPI. Os data gateways permitem o consumo de dados do schema-first com base no padrão SQL. Um esquema SQL para modelagem de dados é o equivalente ao OpenAPI das APIs.

Vários tipos de data gateways

Neste artigo, utiliza-se livremente os termos API e data gateways para se referir a um conjunto de recursos. Existem muitos tipos de API gateways, como gerenciadores de API, balanceadores de carga, service mesh, service registry, etc. É semelhante aos data gateways, onde variam desde enormes plataformas monolíticas de virtualização de dados que desejam fazer de tudo, até bibliotecas de federação de dados, ou desde a criação de serviços cloud específicos até ferramentas de consulta do usuário final.

Serão explorados os diferentes tipos de data gateways e analisados quais se encaixam na definição de "um cloud native data gateway". Um cloud native data gateway, significa que pertence à categoria de uma solução conteinerizada com Kubernetes. Seria um gateway de código aberto, usando padrões abertos, um componente que pode ser implantado em infraestruturas híbridas ou em múltiplos provedores cloud, trabalhar com diferentes fontes de dados, formatos de dados e aplicável a muitos casos de uso.

Plataformas clássicas de virtualização de dados

Na primeira categoria de data gateways estão as plataformas tradicionais de virtualização de dados, como Denodo e TIBCO/Composite. Essas plataformas de dados possuem muitos recursos e tendem a fazer de tudo, desde gerenciamento de API até gerenciamento de metadados, catalogação de dados, gerenciamento de ambiente, implantação, gerenciamento de configuração e outras funcionalidades. Do ponto de vista arquitetural, são muito parecidos com os antigos ESBs, mas para a camada de dados. É possível colocá-los em um contêiner, mas é difícil classificá-los na categoria cloud native.

Bancos de dados com recursos de federação de dados

Outra tendência emergente é o fato de que os bancos de dados, além de armazenar dados, também estão começando a atuar como gateways de federação de dados e permitindo acesso a dados externos.

Por exemplo, o PostgreSQL implementa a especificação ANSI SQL/MED para uma maneira padronizada de lidar com o acesso a objetos remotos a partir de bancos de dados SQL. Isso significa que armazenamentos de dados remotos, como SQL, NoSQL, Arquivo, LDAP, Web e Big Data, podem ser acessados ​​como se fossem tabelas no mesmo banco de dados PostgreSQL. SQL/MED significa Gerenciamento de dados externos e também é implementado pelo engine do MariaDB CONNECT, DB2, projeto Teiid (discutido abaixo) e alguns outros.

A partir do SQL Server 2019, é possível consultar fontes de dados externos sem mover ou copiar os dados. O mecanismo PolyBase da instância do SQL Server processa consultas Transact-SQL para acessar dados externos no SQL Server, Oracle, Teradata e MongoDB.

Pontes de dados GraphQL

Comparada à virtualização de dados tradicional, esta é uma nova categoria de gateways de dados focada no acesso rápido a dados baseados na Web. A parte comum em relação ao Hasura, Prisma, SpaceUpTech, é que eles se concentram no acesso a dados do GraphQL, oferecendo uma abstração leve em cima de algumas fontes de dados. Essa é uma categoria com rápido crescimento, especializada para permitir o desenvolvimento rápido baseado na Web de aplicações orientadas a dados, em vez de casos de uso de BI/AI/ML.

Data gateways de código aberto

O Apache Drill é um mecanismo de consulta SQL sem esquema para bancos de dados NoSQL e sistemas de arquivos. Oferece acesso JDBC e ODBC sobre fontes de dados que não suportam essas APIs, permitindo a consulta dos dados pelos usuários de negócios, analistas e cientistas de dados. Novamente, o direcionamento é ter acesso uniforme baseado em SQL em fontes de dados diferentes. Embora o Drill seja altamente escalável, depende do tipo de infraestrutura do Hadoop ou do Apache Zookeeper.

Teiid é um projeto patrocinado pela Red Hat. É um mecanismo de federação de dados maduro reescrito totalmente para o ecossistema Kubernetes. Utiliza a especificação SQL/MED para definir os modelos de dados virtuais e depende do modelo de Operador do Kubernetes para a construção, implantação e gerenciamento de seu runtime no Openshift. Uma vez implantado, o runtime pode ser escalado no Kubernetes como qualquer outra carga de trabalho stateless cloud native, e integrar-se a outros projetos cloud native. Por exemplo, pode-se usar o Keycloak para single sign-on (SSO) e segurança no acesso aos dados, o Infinispan para necessidades de cache distribuído, exportação de métricas e registro no Prometheus para monitoramento, o Jaeger para rastreamento e até mesmo o 3scale para gerenciamento de API. Mas ultimamente, o Teiid é executado como uma única aplicação Spring Boot, agindo como um proxy de dados e integrando-se a outros serviços de última geração no Openshift, em vez de tentar reinventar tudo do zero.

Visão geral da arquitetura do data gateway Teiid

No lado do cliente, o Teiid oferece o SQL padrão sobre APIs JDBC/ODBC e Odata. Usuários de negócio, analistas e cientistas de dados podem usar ferramentas padrão de BI/analítica, como Tableau, MicroStrategy, Spotfire, etc, para interagir com o Teiid. Os desenvolvedores podem aproveitar a API REST ou JDBC para microservices personalizados e cargas de trabalho serverless. Em ambos os casos, para os consumidores de dados, o Teiid aparece como um banco de dados PostgreSQL padrão acessado por seus protocolos JDBC ou ODBC, mas oferecendo abstrações adicionais e desacoplamento das fontes de dados físicas.

O PrestoDB é outro projeto popular de código aberto iniciado pelo Facebook. É um mecanismo de consulta SQL distribuído visando casos de uso de big data por meio de sua arquitetura de coordenador-trabalhador. O coordenador é responsável por analisar instruções, planejar consultas, gerenciar trabalhadores, buscar resultados dos trabalhadores e retornar os resultados finais ao cliente. O trabalhador é responsável por executar tarefas e processar dados. Recentemente, a comunidade PrestoDB dividiu e criou um fork chamado PrestoSQL que agora faz parte da The Linux Foundation. Embora seja um caminho comum e natural para muitos projetos de código aberto, infelizmente, neste caso, a semelhança nos nomes e em todos os outros artefatos voltados para a comunidade gera alguma confusão. Independentemente disso, as duas distribuições do Presto estão entre os projetos de código aberto mais populares nesse assunto.

Serviços cloud de data gateways hospedados

Com a mudança da infraestrutura para provedores cloud, a necessidade de data gateways não desaparece, mas aumenta. Aqui estão alguns serviços cloud de data gateway:

O AWS Athena é um serviço de consulta interativa baseado em ANSI SQL para analisar dados totalmente integrados ao Amazon S3. É baseado no PrestoDB e também suporta fontes de dados adicionais e recursos de federação. Outro serviço semelhante da Amazon é o AWS Redshift Spectrum. Ele se concentra na mesma funcionalidade, ou seja, na consulta de objetos S3 usando SQL. A principal diferença é que o Redshift Spectrum requer um cluster Redshift, enquanto o Athena é uma oferta serverless que não requer servidores. O Big Query é um serviço semelhante, mas do Google.

Essas ferramentas exigem uma mínima ou nenhuma configuração, podem acessar dados locais ou hospedados em provedores cloud e processar enormes conjuntos de dados. Mas acoplam a um único provedor cloud, pois não podem ser implantados em múltiplos provedores cloud ou localmente. Portanto, são ideais para consultas interativas, ao invés de atuar como frontend de dados híbridos para uso de outros serviços e ferramentas.

Proxy de dados de encapsulamento seguro

Com os data gateways hospedados em provedores cloud, surge a necessidade de acessar dados da infraestrutura local. Os dados têm gravidade e também podem ser afetados por requisitos regulatórios, impedindo que sejam movidos para um provedor cloud. Também pode ser uma decisão consciente manter o ativo mais valioso (seus dados) longe do acoplamento da cloud. Todos esses casos exigem acesso da cloud a dados locais. E os provedores cloud facilitam o acesso aos seus dados. O data Gateway On-Premises do Azure é um proxy que permite o acesso a repositórios de dados locais a partir do Barramento de Serviço do Azure.

No cenário oposto, acessar os armazenamentos de dados hospedados no cloud a partir de clientes locais também pode ser um desafio. O Cloud SQL Proxy do Google fornece acesso seguro às instâncias do Cloud SQL sem a necessidade de incluir endereços IP na lista de permissões ou configurar o SSL.

O projeto de código-fonte aberto patrocinado pela Red Hat, Skupper, adota a abordagem mais genérica para enfrentar esses desafios. O Skupper resolve os desafios de comunicação de vários clusters do Kubernetes por meio de uma rede virtual de camada 7, que oferece roteamento avançado e recursos de conectividade segura. Em vez de incorporar o Skupper no runtime do serviço de negócios, ele é executado como uma instância autônoma por namespace do Kubernetes e atua como um side-car compartilhado, capaz de prover um encapsulamento seguro para acesso a dados ou outra comunicação geral de serviço a serviço. É um proxy genérico de conectividade segura aplicável a muitos casos de uso no mundo da cloud híbrida.

Pool de conexões para cargas de trabalho serverless

O Serverless leva a decomposição de software um passo além dos microservices. Em vez de serviços divididos por contexto delimitado, o serverless é baseado no modelo de função em que cada operação tem vida curta e executa uma única operação. Essas construções granulares de software são extremamente escalonáveis ​​e flexíveis, mas têm um custo que não estava presente anteriormente. Acontece que o rápido dimensionamento de funções é um desafio para fontes de dados orientadas à conexão, como bancos de dados relacionais e brokers de mensagens. Como resultado, os provedores cloud oferecem proxies de dados transparentes como um serviço para gerenciar pool de conexões com eficiência. O Amazon RDS Proxy é um serviço que fica entre a aplicação e o banco de dados relacional para gerenciar com eficiência as conexões com o banco de dados e melhorar a escalabilidade.

Conclusão

As arquiteturas modernas cloud native combinadas com os princípios de microservices permitem a criação de aplicações independentes e altamente escalonáveis. A grande variedade de mecanismos de armazenamento de dados, serviços hospedados na cloud, protocolos e formatos de dados oferecem a flexibilidade máxima para o fornecimento de software em ritmo acelerado. Mas tudo isso tem um custo que se torna cada vez mais visível, com a necessidade de acesso uniforme a dados em tempo real de grupos de usuários emergentes, e com necessidades diferentes. Manter os dados dos microservices apenas para o próprio microservice, cria desafios que ainda não possuem boas respostas tecnológicas e arquiteturais. Os data gateways, combinados com as tecnologias cloud native, oferecem recursos semelhantes aos API gateways, porém para a camada de dados, que podem ajudar a enfrentar esses novos desafios. Os data gateways variam em especialização, mas tendem a se consolidar no fornecimento de acesso baseado em SQL uniforme, segurança aprimorada com as funções dos dados, cache e abstração em armazenamentos de dados físicos.

Os dados têm gravidade, exigem controle de acesso granular, são difíceis de dimensionar e de movimentar para dentro, fora ou entre infraestruturas cloud native. Ter um componente de data gateway como parte do arsenal de ferramentas cloud native, que seja híbrido, funcione em múltiplos provedores cloud e suporte diferentes casos de uso, está se tornando uma necessidade.

Sobre o autor

Bilgin Ibryam é gerente de produtos da Red Hat, comprometido e membro da Apache Software Foundation. Ele é um evangelista de código aberto, blogueiro, às vezes palestrante e autor dos livros Kubernetes Patterns e Camel Design Patterns. No seu dia-a-dia de trabalho, Bilgin gosta de ser mentor, codificar e levar os desenvolvedores a serem bem-sucedidos na criação de soluções de código aberto. Seu trabalho atual concentra-se em blockchain, sistemas distribuídos, microservices, devops e desenvolvimento de aplicações cloud native.