O que é “Cloud-Native” data e por que isso é importante?

Você provavelmente ouviu falar sobre "aplicações cloud-native". Esse termo refere-se a software desenvolvido para mudança, escala, resiliência e capacidade de gerenciamento. Muitas vezes é equiparado a microserviços e recipientes, mas esses não são necessários. Seja executado em nuvens públicas ou privadas, uma aplicação cloud-native aproveita a elasticidade e a automação oferecidas pela plataforma do host.

Mas quais são as implicações para os recursos de dados em que essas aplicações dependem? Enquanto as aplicações cloud-native possuem planos como os critérios de doze fatores para orientar o design, seus serviços de dados não.

Abaixo, analisaremos dez características de dados cloud-native e por que cada um ajuda você a oferecer um software melhor. Com certeza, você não pode e nem quer, e nem precisa, seguir todos os pontos. Mas estas características devem dar-lhe uma sensação do que mais importa ao coletar, armazenar e recuperar dados em sistemas modernos.

#1 - Dados cloud-native são ... armazenados de várias formas.

Quinze anos atrás, onde você armazenava seus dados? Com toda a probabilidade, você tinha um sistema de arquivos local ou conectado à rede e um banco de dados relacional para trabalhar. Você coloca conteúdo binário no armazenamento de arquivos e dados transacionais em um banco de dados normalizado. Era isso. Hoje, seus dados cloud-native são moldados de maneiras diferentes e residem em vários lugares.

As opções parecem infinitas. Os dados cloud-native podem estar em um registro de eventos, banco de dados relacional, documento ou armazenamento do tipo chave-valor, armazenamento de objetos, armazenamento em rede, cache ou armazenamento a frio. A escolha ideal depende da situação. Devemos armazenar arquivos de mídia onde a durabilidade é importante? Devemos utilizar o armazenamento de objetos. Salvar dados transacionais não utilizados por uma duração requerida por compliance? Guardar em armazenamento a frio. Servir informações do catálogo de produtos para uma propriedade da web de alto tráfego? Devemos olhar para um cache ou para um armazenamento do tipo chave-valor orientado para leitura. Considerações para latência, desempenho de leitura, durabilidade e similares, ajudarão você a reduzir suas escolhas.

Esteja ciente que, em sistemas cloud-native, o log unificado geralmente se torna o sistema de registro. As visualizações materializadas mostram uma representação desses dados para um determinado propósito. Esta é uma maneira diferente de pensar no armazenamento de dados, e para muitos, transforma a idéia de um banco de dados de dentro para fora! O log unificado mantém transações individuais de suas várias entradas. Esses itens podem se inflar em objetos ou registros em seus aplicativos ou cache. Esta pode ser uma nova maneira de armazenar dados, mas provou ser uma excelente solução em escala.

Dito isto, você não precisa jogar fora o seu banco de dados relacional confiável. Em vez disso, reavalie como você o usa. Por exemplo, se você estiver usando seu banco de dados relacional para o estado da sessão do aplicativo, considere introduzir algo como o Redis e familiarizar-se com armazenamento de chave-valor.

Ao mesmo tempo, introduza bases de dados relacionais modernas, como o Google Cloud Spanner, que são projetados para a resiliência geográfica e o desempenho à escala da nuvem sob demanda. Ou dê boas vindas à bancos de dados NoSQL otimizados para pesquisas rápidas e alta disponibilidade. O armazenamento de objetos é um serviço fácil para começar. Afaste-se das dependências do sistema de arquivos (locais), quando possível e recrie as aplicações para usar o armazenamento externo em vez disso.

#2 - Dados cloud-native são ... independentes de esquemas fixos.

Pode se observar que aplicações e serviços cloud-native trabalham com dados em um formato JSON. Dito isto, também pode-se utilizar buffers de protocolo ou XML clássico para estruturar seus dados. Independentemente disso, as aplicações cloud-native priorizam a adaptabilidade. Isso significa facilitar a adaptação às mudanças. Isso é difícil de fazer se você precisar alterar constantemente a estrutura da tabela ou regenerar tipos de classes quando a forma dos seus dados muda.

Para o ponto acima, não tenha medo de diversificar suas opções de armazenamento. Se você precisar que todos os dados estejam em conformidade com um esquema fixo e encaixe cuidadosamente nas colunas do SQL Server, você estará desnecessariamente restringindo-se. Considere reduzir o uso intenso de ORMs e de classes tipadas que dificultam as mudanças.

Se a preferência é utilizar schemas de dados estruturados, considere usar um de serviço bem projetado na frente do banco de dados (um service facade). Para adicionar novos recursos ou manipular alterações de dados, você pode versionar a API.

#3 - Dados cloud-native são ... duplicados.

Qual é a coisa que nos ensinaram ao aprendermos engenharia de software? Não cometa repetições. É uma orientação valiosa, mas ao olhar para os dados em suas aplicações cloud-native, eles podem não serem mantidos em um mesmo lugar.

Você encontrará uma resiliência excelente em bancos de dados de nuvem pública. Serviços como o Amazon RDS facilitam a criação de read-réplicas atualizadas de forma assíncrona. O banco de dados Microsoft Azure SQL suporta a distribuição geográfica. Os dados são dominados em um só lugar, mas duplicados em outro lugar. Ao trabalhar com bancos de dados de estilo NoSQL, não existe um servidor "mestre" que armazene tudo; Os dados são replicados em um circuito de máquinas. Isso proporciona resiliência, mas muitas vezes sacrifica consistência para que isso aconteça.

À medida que você introduz um armazenamento em cache mais vigoroso, você se encontrará fazendo as leituras e escritas. Você pode escrever por trás do sistema de registro, mas novamente, os mesmos dados estarão espalhados. O cache em si é uma forma de duplicação de dados e esta cópia oferece melhor desempenho e resiliência de aplicativos.

Os dados geralmente correm de um sistema de borda para os sistemas internos. Esses dados podem se mover intactos de dispositivos, via gateways de nuvem, aplicações e armazenamento de dados. Ou, esses dados podem ser salvos, filtrados ou agregados à medida que eles são processados. Esses dados podem não desaparecer desses estágios intermediários. Podem ser utilizados mais tarde para comparação ou cálculo.

Embora o "sistema de registro" seja muito importante, seus dados cloud-native podem ser duplicados muitas vezes para processamento, armazenamento em cache e por fins de armazenamento em múltiplas nuvens.

#4 - Dados cloud-native é ... integrados através de interfaces de serviço.

Dê uma olhada na documentação dos bancos de dados cloud-first, como o Google Cloud Spanner ou o Amazon DynamoDB. Alguma coisa em comum? As APIs são baseadas em web services (REST). Sem drivers, sem endereços IP fixos. Para sermos justos, esses mesmos provedores de nuvem oferecem bancos de dados relacionais tradicionais (por exemplo, Google Cloud SQL, Amazon RDS) que usam clientes, drivers e nomes de host padrões para interagir com o banco de dados. Mas você vê uma tendência de acesso apenas a camada de dados através de APIs de serviço, sem acesso a camada abaixo, servidores e esquemas de dados bruto. Quando você extrai dados da Salesforce.com, você não tem nenhuma opção para acessar o banco de dados Oracle subjacente. Em vez disso, você passa por uma API de serviços cuidadosamente projetada que rege o uso e o formato dos dados.

Existe uma nova safra de plataformas de integração que atendem aos endpoints da nuvem. A Microsoft oferece Logic Apps, a Dell oferece o Dell Boomi, e há ainda mais ferramentas amigáveis para o consumidor, como o IFTTT. O que todos têm em comum é que eles se conectam a uma série de diferentes sistemas de nuvem e os integram por meio de interfaces de serviço. Ao projetar sua estratégia de dados cloud-native, pense em como disponibilizar os endpoints de dados em suas aplicações.

#5 - Dados cloud-native são ... orientados a self-service.

Pode-se argumentar que a principal razão pela qual a computação em nuvem decolou uma dúzia de anos atrás é devido a sua natureza Self-service. Os desenvolvedores empresariais não são mais mantidos reféns por regras corporativas arcaicas para aquisição de hardware. E as startups não precisaram fazer grandes investimentos de capital para experimentar idéias empresariais.

Uma plataforma de dados cloud-native suporta provisionamento on-demand e configuração Self-service. Isso não é negociável. Qual é o objetivo de ter aplicações cloud-native que são continuamente implantados e escalam em alguns instantes, se o armazenamento de dados correspondente não puder continuar? Não, os dados cloud-native são armazenados em bancos de dados, caches e armazenamento de arquivos que podem ser provisionados com facilidade e dimensionados automaticamente ou com chamadas de API simples. Carregar ou exportar dados é realizado por meio de chamadas de APIs. Não podemos ignorar a necessidade de políticas compartilhadas de identidade, acesso e armazenamento, mas estas devem ser parte do provisionamento automatizado ou capazes de serem auditadas após o fato.

Enquanto a nuvem pública subiu a barra para armazenamento de dados cloud-native, não é impossível obter esses recursos on-premises também. Se assumirmos que a operação "cloud-native" significa software-run-by-software, qualquer produto de dados no modelo on-premises deve funcionar como uma plataforma.

#6 - Dados cloud-native são ... isolados de outros tenants.

Por razões de desempenho, agilidade e segurança, os dados cloud-native não são ocultos em uma única instância compartilhada.

Estamos todos acostumados a criar grandes instâncias de banco de dados projetadas para armazenar todas as coisas. Mas a capacidade compartilhada - independentemente de quanto - é perigosa. Aplicações problemáticas têm um efeito em cascata em todas os outras. Todos os tenants estão presos com a mesma janela de atualização de software e estratégia de recuperação de desastres. Do ponto de vista de segurança, é a forma correta de adicionar usuários com permissões em objetos de banco de dados específicos. Mas à medida que o número de tenants cresce, você acaba com uma rede de regras de controle de acesso que pode levar a permissões elevadas para aqueles que não precisam disso.

Dados cloud-native suportam instâncias de banco de dados por tenant. Seja em uma plataforma de nuvem compartilhada ou on-premises, esses bancos de dados são alocados para serviços e aplicações, não para empresas inteiras. Isso significa que as equipes têm controle sobre quando e como suas atualizações acontecem, a capacidade de escala e quem tem acesso exatamente. Esses micro bancos de dados oferecem maior agilidade, pois cada equipe pode escolher um motor de banco de dados e o modelo de implantação que fazem mais sentido para sua aplicação ou serviço.

#7 - Dados cloud-native são ... plataformas gerenciadas on-premises

Cloud-native: é um software executado por software. As plataformas são a peça crítica, especialmente para bancos de dados. E trata-se daa única forma de se gerenciar efetivamente um conjunto crescente de instâncias de banco de dados.

O que uma plataforma de banco de dados gerenciada oferece a você? Primeiro, estamos falando de instalação e configuração. Não importa mais fazer uma instalação manual cuidadosa do Microsoft SQL Server em um cluster. Isso é propenso a erros e demorado. Os desenvolvedores e as equipes de aplicação precisam clicar em um botão ou fazer uma chamada de API para obter uma instância de banco de dados configurada corretamente onde quiserem.

A segunda coisa que uma plataforma gerenciada oferece a você é gerenciamento do "dia 2". Isso significa monitoramento interno, dimensionamento de infraestrutura, patches, atualizações de versões e recuperação de failover. Precisa de uma réplica de leitura? Demora alguns minutos usando o Amazon RDS. Precisa de alta disponibilidade? O Microsoft Azure Cosmos DB lida com a falha do nó (ou região) sem exigir alterações de código. Estes não são apenas recursos legais de se ter. Eles representam a forma como as empresas líderes armazenam e acessam dados cloud-native.

#8 - Dados cloud-native são ... não tenha medo de escalar (para fora)

Além de pensar "flexibilidade" quando você ouve a palavra "nuvem", você também provavelmente pensa na palavra "escala". A Internet está cheia de histórias de empresas da web e startups processando bilhões e trilhões de data points. Embora você não enfrente esse nível de escala hoje, você deveria estar planejando isso. E, assim como aplicações cloud-native, suas capacidades de dados devem se concentrar em scale out e não scale up.

Os dispositivos descartam quantidades de dados sem precedentes. O hardware e software em seus data centers emitem informações de diagnóstico. Os serviços na nuvem agora descarregam com entusiasmo os eventos quando as coisas acontecem. Aplicações empresariais geram e consomem todo tipo de dados. À medida que você abraça uma abordagem de dados cloud-native, você aprende a esperar volumes crescentes de dados.

Você é confrontado com mais dados, vindo mais rapidamente. Os dados cloud-native voam através de sistemas de mensagens ou eventos em tempo real e são armazenados em uma escala de petabytes. Para tornar isso realidade, você precisa garantir que seu middleware de mensagens seja projetado para explosões e disponibilidade sempre disponível. Tradicionalmente, isso significava provisionar clusters gigantes adiantado. Em um mundo cloud-native, sua plataforma subjacente deve escalar a camada de mensagens conforme a demanda ditar.

Os bancos de dados (e os microserviços de dados) devem ser capazes de absorver atualizações constantes de lotes pequenos e grandes. Isso pode afetar a forma como você projetou um schema RDBMS ou sua escolha de uma opção sem schema para cargas de trabalho intensivas. Em vez de usar uma instância grande de banco de dados única, você deve considerar bancos de dados que também escalam para mais instâncias. Reduzir os seus bancos de dados pode vir como trocas transacionais, mas, em troca, você obtém uma melhor agilidade. Isso significa começar com instâncias menores e prontidão para falhas inevitáveis na instância (e no site!).

#9 - Dados cloud-native são ... frequentemente usados e descartados.

Purgar dados pode ser um obstáculo mental para superar. Nós gostamos de armazenar dados "just in case". Mas enquanto os dados cloud-native são amigáveis à escala (veja acima), também é sobre o uso temporário.

Com certeza, uma grande quantidade de seus dados cloud-native é persistente indefinidamente. No entanto, você notará que uma quantidade crescente de dados é processada (em algum lugar) e descartada. Talvez seja agregado nas arestas e um evento com um resumo é transmitido para um sistema on-premises. Ou é usado em uma janela sensível ao tempo para procurar anomalias de desempenho do servidor e excluído depois. E poderia ser por exemplo recomendações de compras em tempo real geradas por um modelo de aprendizado de máquina e removidas quando o comprador sair do site.

Não sinta a necessidade de armazenar tudo. Reconheça que agora você está lidando com dados mais transitórios do que nunca, e é preciso descobrir a vida útil necessária antes de planejar seu meio de armazenamento.

#10 - Dados cloud-native são ... analisados em tempo real e em lote.

O streaming de dados é gigante, mas uma pesquisa do Gartner aponta que 85% das empresas ainda favorecem as técnicas orientadas para processamento em batch. Esse número diminuirá ao longo do tempo, mas os dados cloud-native precisam de ciclos de processamento em tempo real e batch.

Os motores de transmissão baseados em nuvem, como o AWS Kinesis ou o Azure Event Hubs, tornam simples processar um conjunto ilimitado de eventos. Os clientes usam esses mecanismos para detectar fraudes, atualizar preços ou revelar problemas de desempenho para usuários. Mas esses motores também bombearam dados em data warehouses onde a análise mais sofisticada ocorre em batch. Há um espaço para análises pontuais e análise mais pensativa com os mesmos dados.

Resumo

Estamos ainda nos passos iniciais para identificar o que são dados cloud-native. Como traremos dados legados em aplicativos cloud-native? Qual é a abordagem certa para lidar com as necessidades de dados multi-cloud? Onde o lock-in e a portabilidade entram? Ainda não há respostas para todas essas questões, mas este artigo teve a intenção de prover uma primeira impressão em como os conceitos cloud-native se aplicam ao mundo dos dados. Nos próximos meses e anos, suspeito que gastaremos significativamente mais tempo explorando essa área de foco.

Sobre o Autor