Pesquise “cloud native” no Google e você encontrará mais de 800 milhões de resultados. É evidente que “cloud native” é um termo importante – e As pessoas não têm muita clareza sobre o que isso realmente significa. Há algum tempo, em uma conversa com outra pessoa “do ramo”, eu disse: “Mas isso não é ‘cloud native’!” Ela assentiu com sabedoria, concordando. Claramente, isso significa alguma coisa, já que conseguimos chegar a um acordo sobre alguns conceitos complexos usando essa expressão abreviada, “cloud native”. Vamos nos aprofundar mais no assunto.
Para definir o que é “nativo da nuvem”, precisamos começar com uma pergunta mais simples:
O que é a nuvem?
O segredo está na desagregação
Há quase 50 anos — antes mesmo da fundação da Microsoft —, os estudantes de Harvard Bill Gates e Paul Allen escreveram um interpretador de BASIC para um dos primeiros microcomputadores do mundo, o MITS Altair 8080. Eles gravaram o programa inteiro em fita de papel (uma das primeiras formas de armazenamento) e voaram para o Novo México para mostrar à MITS o que haviam escrito.
Durante a descida para Albuquerque, Allen percebeu que não tinha como ler a fita de papel (necessária para que o interpretador BASIC pudesse carregá-la no Altair 8080). Allen escreveu rapidamente um programa para ler a fita de papel. Funcionou, e o resto é história.
Se você quiser saber o que significa “agregado” – esse é um ótimo exemplo. Tudo o que era necessário para executar o interpretador BASIC de Gates e Allen teve que ser escrito por eles mesmos – incluindo a rotina para ler o código da fita de papel e transferi-lo para a memória do sistema!
Passando agora para a computação em nuvem, onde o objetivo é desagregar completamente. Desagregar o quê? Bem… tudo. A capacidade de computação é separada de todos os outros recursos, de modo que você pode adquirir a quantidade de computação necessária independentemente dos demais recursos. O mesmo vale para armazenamento e rede.
Mas isso é apenas infraestrutura. A nuvem também desagrega o software. Enquanto Gates e Allen precisavam escrever cada linha de código de seu aplicativo, os aplicativos em nuvem de hoje utilizam “serviços” para lidar com tarefas específicas. Em vez de anos programando aplicativos enormes e monolíticos, os aplicativos em nuvem de hoje são construídos com centenas de linhas de código que conectam dezenas (ou centenas) de serviços em nuvem.
A nuvem é a extensão lógica da filosofia Unix de composibilidade, melhor expressa por Doug McElroy, o inventor do pipe do Unix: “Escreva programas que façam uma coisa e a façam bem. Escreva programas que funcionem em conjunto.”
Essa é a essência da nuvem. Mas por que desagregar? No nível mais básico, a desagregação proporciona elasticidade e agilidade.
Elasticidade
Os recursos necessários para qualquer carga de trabalho variam ao longo do tempo. Por exemplo, o filme de James Cameron, O filme “Avatar” ultrapassou os limites dos efeitos especiais. A renderização de um único quadro exigiu o equivalente a 3.000 vCPUs na nuvem durante uma hora. Como o filme “Avatar” foi filmado a 48 quadros por segundo e tem duração de 192 minutos, foram necessários mais de meio milhão de quadros para renderizar. Isso representa mais de 1,6 bilhão de horas de ciclos de CPU virtual.
O filme ficou em produção por 12 anos no total, mas, como acontece com todos os filmes, grande parte do trabalho final foi realizada pouco antes do lançamento. O Cloud proporcionou a flexibilidade de que a empresa responsável pelos efeitos especiais de *Avatar* precisava para concluir o trabalho. O produtor executivo de efeitos visuais, David Conley, observou que não teriam conseguido fazer isso sem a AWS.
A elasticidade se aplica à computação, ao armazenamento, à rede e a praticamente qualquer recurso necessário. A nuvem torna fácil e rápido aumentar e reduzir o uso conforme a necessidade.
Agilidade
Outra vantagem da nuvem é a agilidade em todos os sentidos da palavra. A nuvem permite:
Agilidade no desenvolvimento devido à arquitetura de serviços mencionada anteriormente. Os desenvolvedores utilizam uma ampla variedade de serviços e reduzem o tempo de programação de anos e milhões de linhas de código para semanas e milhares de linhas.
Vale ressaltar que essa nova “arquitetura de serviços” se beneficia do efeito de rede. Quanto mais cargas de trabalho utilizam serviços, mais terceiros se sentem motivados a desenvolver novos serviços. E quanto mais serviços existem, mais desenvolvedores se sentem motivados a utilizar serviços de terceiros. Esse círculo virtuoso acelerou a transição das práticas de codificação monolíticas para as arquiteturas de serviços.
Agilidade da infraestrutura, porque, em vez de comprar, instalar e gerenciar a infraestrutura, os usuários simplesmente solicitam o que precisam — quando precisam — por meio de solicitações simples. O termo “infraestrutura como código” se refere ao uso de um “código” simples para provisionar toda a infraestrutura necessária em minutos, em vez de semanas ou meses.
Agilidade econômica, porque você só utiliza o que precisa, quando precisa. A Avatar não precisou construir um enorme centro de dados de efeitos especiais e gerenciá-lo por 12 anos. Em vez disso, eles simplesmente ativaram o que precisavam quando precisavam.
Então, agora que entendemos o que é a nuvem, podemos discutir o que é necessário para ser verdadeiramente nativo da nuvem.
O que é “Cloud Native”?
A resposta mais simples é que um aplicativo nativo da nuvem interage com a nuvem por meio de nativo da nuvem primitivas. Por exemplo, um aplicativo nativo da nuvem chamaria diretamente os serviços de armazenamento nativos da Amazon AWS (S3, EBS, EFS, etc.). Esse princípio se aplica a todos os serviços em nuvem — computação, armazenamento, rede, etc.
Para aplicativos “nascidos na nuvem” (ou seja, projetados desde o início para rodar na nuvem e somente na nuvem), isso é bastante simples. Mas, para aplicativos que surgiram em um ambiente local, é necessário realizar um doloroso processo de refatoração. Observe que isso exige que o aplicativo seja totalmente desagregado de toda a infraestrutura — computação, armazenamento e rede.
O segundo requisito importante para ser verdadeiramente nativo da nuvem é ser gerenciado “como código”. Isso significa ser capaz de iniciar a aplicação com apenas algumas linhas de código, em contraste com o processo tradicional em ambiente local, no qual tudo é instalado e configurado manualmente ao longo de várias semanas.
Assim como na gravidez, não existe algo como “parcialmente nativo da nuvem”. Um aplicativo ou é nativo da nuvem ou não é. Se um aplicativo não se desagregar totalmente e não adotar a metodologia “as-code”, ele perde os benefícios de elasticidade e agilidade prometidos pela nuvem.
Existem soluções de armazenamento nativas da nuvem?
Antes de falarmos sobre soluções de armazenamento nativas da nuvem, vamos revisar os “elementos básicos” da nuvem no que diz respeito ao “armazenamento”.
Trata-se de armazenamento de objetos (Azure Blob / AWS S3). Essa é uma camada de persistência de dados incrivelmente acessível, escalável, disponível e durável, com excelente desempenho, conforme medido pela taxa de transferência. Sua desvantagem é que se trata de uma nova interface RESTful e que oferece apenas consistência eventual.
Depois, temos o que eu chamaria de uma “imitação de SAN para quem tem orçamento limitado”, ou seja, o EBS na AWS e o Managed Disk no Azure. Eles se apresentam como um “disco local”, são resilientes e, na maioria das vezes, funcionam exatamente como um disco comum em um servidor de armazenamento tradicional. Essas primitivas funcionam como o equivalente a um “disco local protegido” (exceto que não estão conectadas à instância de computação local). Elas apresentam características de desempenho moderadas e suportam “leituras/gravações aleatórias”, mas são caras.
E, por fim, há os SSDs NVMe vinculados à instância, que funcionam mais como uma extensão da DRAM, já que os dados nessas “unidades” não são mantidos após a reinicialização da instância; no entanto, eles são muito mais baratos do que a DRAM ou o “disco local protegido”, apresentando características de desempenho que se situam entre essas duas opções.
Até o momento, o setor de armazenamento tem resistido obstinadamente à nuvem. Os fornecedores tradicionais (Dell, NetApp) possuem uma quantidade excessiva de código específico para hardware (forte dependência da NVRAM, acoplamento estreito entre as camadas de resiliência de dados e de serviços de dados) para refatorar suas ofertas de modo a aproveitar os recursos nativos da nuvem.
E então surgiram a VAST e a Pure, que também optaram por uma pilha de armazenamento otimizada para hardware.
Da Pure’s armazenamento em nuvem em bloco Essa oferta é relevante, na medida em que utiliza primitivas nativas da nuvem para fornecer os serviços de dados em bloco tão desejados pelos clientes da Pure, E, ao mesmo tempo, é simplesmente lamentável! Quem, afinal, ainda usa SAN na nuvem? É de deixar qualquer um perplexo. E já que estamos falando nisso, tenho muita dificuldade em entender quem usa VMware na nuvem. Isso também é de enlouquecer!
Entre os provedores de armazenamento de última geração, é justamente a Weka.io que impressiona. Eles possuem uma arquitetura “nativa da nuvem” e utilizam o armazenamento de objetos na nuvem como sua camada de resiliência. Agora, se ao menos eles não tivessem a reputação de serem um participante de nicho no setor de HPC e de serem uma “Ferrari de vidro”…
Então, como diretor de tecnologia (CTO) da Qumulo, o que tenho a dizer sobre a oferta de nuvem da Qumulo?
Fiquem ligados.
Marquem a data em seus calendários: quinta-feira, 9 de novembro de 2023, e preparem-se para ficar de queixo caído 🙂