O caminho nativo da nuvem para dados em qualquer lugar

A arquitetura com o Kubernetes é a peça central indispensável que torna a análise de dados excepcionalmente flexível, executada em qualquer lugar no ponto de necessidade de negócios, e fazendo isso em escala e com alta simultaneidade, desempenho, eficiência e disponibilidade.

Milhares de empresas em verticais, desde serviços financeiros e seguros até manufatura e saúde, estão descobrindo que precisam de implantações de nuvem pública e privada, híbridas e de borda para melhor atender às suas necessidades de análise e gerenciamento de dados. Portanto, não é surpresa que o conceito de nuvem distribuída faça parte do amadurecimento da nuvem. Trazer data warehouses, data lakes e análises avançadas para uma arquitetura de nuvem distribuída é para onde os mercados estão indo. Estender essa arquitetura para abranger serviços de análise e gerenciamento de dados de nível superior naturalmente leva à ideia de uma nuvem de dados distribuídos . Dentro de uma nuvem de dados distribuídos, os data warehouses corporativos não serão usados ​​apenas para fornecer análises para algumas centenas de analistas de negócios ou cientistas de dados em uma empresa, mas poderão, em última análise, alimentar aplicativos analíticos em tempo real que são usados ​​diretamente por uma empresa. clientes que chegam a dezenas de milhares. Os dados estarão imediatamente acessíveis – e produzirão insights – em qualquer lugar.

Veja também: Tendências de adoção da nuvem de 2021 amplificadas em 2022

Explorando o destino

Cloud-native é um termo muito usado, mas tem um significado real quando a arquitetura de software é projetada desde o início para aproveitar os benefícios da nuvem distribuída. Um data warehouse nativo da nuvem totalmente realizado deve alavancar logicamente uma arquitetura de nuvem de dados distribuída. Em termos mais amplos, isso traz análises para os dados onde quer que estejam (e não o contrário), mitiga o risco de concentração, aumenta drasticamente a eficiência e inaugura a modernização para gastos controlados e uma vantagem competitiva.

Para colocar um ponto mais preciso sobre isso, uma tecnologia de gerenciamento e análise de dados nativa da nuvem deve exibir cinco características principais para se alinhar com o plano de nuvem de dados distribuídos:

• Um tempo de execução independente de plataforma que permite o provisionamento de dados e análises em qualquer lugar
• Uma experiência de usuário comum em qualquer lugar
• Recursos comuns de segurança e governança em qualquer destino de implantação
• Eficiência de custo e tecnologia em qualquer lugar, minimizando recursos e permitindo um forte gerenciamento de custos (FinOps) e proteções de gastos
• Um único plano de controle, unindo todas as implantações, nuvem pública, local e na borda da rede

Implantável no ponto de necessidade em qualquer lugar, um data warehouse nativo da nuvem totalmente realizado seguindo esse padrão também abstrairá a complexidade da infraestrutura de nuvem, local e de borda de rede dos usuários finais. O objetivo é liberá-los dos detalhes da infraestrutura e permitir que eles se concentrem na geração de valor da análise e no gerenciamento de dados, enquanto ainda transmitem o poder nativo da nuvem.

Escolhendo o guia certo

Então, como esse destino é alcançado? Kubernetes, a ferramenta de orquestração de contêineres de código aberto, fornece o caminho mais popular para operações nativas da nuvem. Embora a ideia de particionar cargas de trabalho no Unix exista desde a década de 1970, foi apenas cerca de uma década atrás que os contêineres foram amplamente implementados para tornar o desenvolvimento de aplicativos mais fácil, mais portátil e eficiente no uso de recursos. Mas implantar centenas ou milhares de aplicativos em uma vasta arquitetura de microsserviços provou ser extremamente complicado. Embora existam outras opções, o projeto Kubernetes de código aberto do Google, agora mantido pela Cloud Native Computing Foundation, ganhou destaque para resolver a orquestração de aplicativos de microsserviços, permitindo que os aplicativos sejam executados em infraestrutura genérica, monitorados e gerenciados de maneiras padrão e autenticados usando padrões abertos.

Isso é bom e bom para aplicativos. Mas e o mundo dos dados? A mesma orquestração de contêineres fundamental é necessária para data warehouses nativos de nuvem para oferecer elasticidade e flexibilidade de implantação em nuvens públicas e privadas, borda de rede, nuvens híbridas e totalmente distribuídas.

A rearquitetura nativa da nuvem para aplicativos da Web escaláveis ​​é comum, mas os bancos de dados, em sua maioria, acabaram de ser “elevados e transferidos” para o mundo nativo da nuvem. Colocar um banco de dados em um contêiner permite que ele seja executado em uma infraestrutura moderna, mas não oferece uma experiência que demonstre todos os benefícios da nuvem. O software ignora em grande parte o fato de que está sendo executado em um ambiente de contêiner, e operações como o gerenciamento de clusters elásticos precisam ser manuseadas desajeitadamente de fora do banco de dados manualmente, usando operadores e hackeando gráficos do Helm. Recursos como permitir que vários clusters de computação sob demanda elásticos compartilhem os mesmos dados subjacentes no armazenamento de objetos geralmente não estão disponíveis. Os usuários que buscam obter valor comercial de um data warehouse elástico baseado em nuvem não querem saber sobre gráficos, pods, nós ou arquivos de configuração do Helm. Eles querem apenas provisionar data warehouses, gerenciar clusters elásticos e obter insights de seus dados.

Fornecer uma interface SQL no Kubernetes para provisionar vários clusters elásticos sob demanda e ocultar as complexidades do Kubernetes de DBAs e usuários finais é a resposta.

Dessa forma, diferentes usuários podem ser atribuídos para executar cargas de trabalho em diferentes clusters de computação e o cluster de computação em uso pode ser alterado em tempo de execução por meio do SQL, sujeito a permissão. Os clusters podem ser configurados para suspender automaticamente após um período ocioso e voltar a funcionar sob demanda. Por exemplo, um cluster de computação separado pode ser criado para executar processos de ETL quando necessário, um para business intelligence (BI) ad-hoc e vários clusters de ciência de dados. Os clusters de computação podem ser expandidos online durante períodos de uso intenso ou desligados durante períodos de silêncio para economizar dinheiro. Os clusters podem ser criados para executar tarefas de relatório em lote diárias, semanais ou mensais que estão ativas apenas durante esses períodos de tempo. Tanto o tamanho dos nós no cluster de computação quanto o número de nós são controláveis ​​nesse modelo e os limites de consumo de recursos podem ser estabelecidos no nível da instância para previsibilidade. Da mesma forma, é possível configurar um sistema de réplica de baixo custo que recebe tráfego de replicação de uma instância primária de data warehouse, que pode ser ampliada sob demanda quando a réplica precisar ser usada.

Esse tipo de elasticidade é implementado não apenas pela integração profunda com o Kubernetes, mas usando o próprio SQL como a “interface do usuário” para criar, suspender, retomar e gerenciar clusters em vez de ferramentas de desenvolvedor. O Kubernetes é a fonte oficial da verdade para o estado de todos os clusters. Visualizações do sistema mostrando o estado dos clusters originam seus dados do Kubernetes usando suas APIs. Quando as instruções SQL de gerenciamento de cluster são inseridas, o data warehouse nativo da nuvem entra em contato com o Kubernetes para alterar o estado desejado de uma instância; O Kubernetes então implementa as mudanças necessárias. Se um nó no cluster não estiver íntegro, o Kubernetes colocará um substituto online.

Isso representa um relacionamento exclusivo e de dentro para fora com o Kubernetes:em vez de o Kubernetes ser a "interface do usuário" para direcionar o estado do cluster, o próprio banco de dados, que é gerenciado pelo Kubernetes, torna-se a interface do usuário. Essa arquitetura cria uma relação simbiótica que oferece uma experiência de nuvem única e totalmente realizada. O poder e a flexibilidade multiplataforma do Kubernetes ficam disponíveis para um data warehouse, conduzido inteiramente por meio de SQL.

À medida que mais dados são gerados e mais casos de uso implantados, é fácil para as empresas entrarem em um ciclo vicioso em que seu ecossistema fica cada vez mais enraizado em uma nuvem específica. Riscos sistêmicos podem surgir nessa única nuvem que apresenta muita exposição para infraestrutura crítica de TI em setores altamente regulamentados, como serviços financeiros e seguros. A arquitetura com o Kubernetes não é o único conceito central que dá vida a um data warehouse nativo da nuvem totalmente realizado. Não é o único componente de arquitetura alinhado com o padrão de nuvem de dados distribuídos. Mas é a peça central indispensável que torna a análise de dados excepcionalmente flexível, executada em qualquer lugar no ponto de necessidade de negócios - e fazendo isso em escala e com alta simultaneidade, desempenho, eficiência e disponibilidade. O resultado é que milhares de usuários em qualquer empresa, em diferentes linhas de negócios e regiões geográficas, podem tomar decisões extremamente rápidas e gerar valor a partir de análises em movimento quase em tempo real.