Latest / We The People, in Tech or Not: O Debate / O Azure SQL Hyperscale não é só para bancos de dados enormes

Transcript

O Azure SQL Hyperscale não é só para bancos de dados enormes · We The People, in Tech or Not: O Debate

• 0:00
  We, the People in Tech or Not, o debate. We, the People in Tech or Not. Bem-vindo ao We, the People in Tech or Not, o debate.
• 0:09
  Ah, e antes da gente mergulhar no assunto, eu preciso deixar claro que este é um podcast gerado por inteligência artificial. Uhum. É importante avisar isso.
• 0:17
  Sim, e ele é baseado num post super detalhado da newsletter We, the People in Tech or Not, que é escrita pelo Alex Rosa.
• 0:24
  O nosso objetivo aqui, como sempre, é ajudar você a aprender novas formas de explicar temas técnicos. Exatamente.
• 0:30
  Desde aquela pessoa que é totalmente iniciante e não trabalha com tecnologia, até o nível de um engenheiro especialista. Isso aí. E hoje a gente vai falar sobre o Azure SQL Hyperscale.
• 0:40
  E olha, o primeiro passo é a gente desmistificar logo de cara o maior mal-entendido sobre ele: o próprio nome, sabe? Ah, a palavra hyperscale.
• 0:48
  Sim, a palavra hyperscale dá aquela impressão de ser uma ferramenta colossal, tipo algo restrito só pra multinacionais com petabytes de informação, né?
• 0:57
  Pois é, a gente vê muita equipe de engenharia descartando o serviço, falando: "Ah, não somos grandes o suficiente pra isso." Exato. Mas como a documentação que o autor traz no texto esclarece, isso é um mito total.
• 1:09
  O serviço atende qualquer tipo de carga de trabalho, seja transacional, analítica ou mista. E adivinha onde ele começa? Com apenas 10 GB de tamanho. 10 GB. Nossa, é um ponto de partida surpreendentemente baixo, concordo.
• 1:23
  E bom, é um prazer tá aqui pra debatermos isso hoje. O prazer é todo meu. Bom, a minha posição aqui é bem clara. Eu defendo que o verdadeiro poder do hyperscale não tá no limite teórico dele de 128 TB.
• 1:35
  Hum, tá na arquitetura, né? Exatamente. A forma como os dados são processados e armazenados é, do ponto de vista de engenharia, brilhante. Traz benefícios práticos imensos, até pros menores aplicativos.
• 1:47
  Bom, essa é uma perspectiva técnica bem otimista. Só que eu abordo esse tema de um ângulo um pouco diferente. Eu vou colocar aqui o chapéu do gestor, sabe?
• 1:56
  Aquele leitor inteligente que não tá lá escrevendo código no dia a dia, mas que responde pelo orçamento, que foca no risco do negócio. Certo, o cético da mesa. Sim, eu mesmo.
• 2:07
  E sob essa ótica, o hyperscale levanta umas bandeiras vermelhas bem significativas.
• 2:13
  Adotar essa tecnologia envolve mudanças comerciais profundas, regras de licenciamento bem complexas e um risco que o texto chama de porta de mão única.
• 2:22
  Então a minha dúvida é: isso realmente vale a pena pro meu negócio ou é um exagero técnico? Olha, é um questionamento super justo.
• 2:30
  Mas pra gente entender se o benefício supera o risco, a gente precisa olhar pra como o hyperscale funciona. E o texto original usa uma analogia de restaurante que é maravilhosa pra explicar isso.
• 2:39
  Ah, a analogia da cozinha e da despensa. Essa mesma.
• 2:42
  Num banco de dados tradicional, a cozinha, que é o nosso processamento, a CPU, e a despensa, que é o armazenamento, os discos, ficam amarrados na mesma sala, no mesmo servidor físico. Uhum. Tudo no mesmo lugar. Exato.
• 2:55
  Aí se o seu aplicativo faz sucesso e você precisa de uma cozinha maior pra processar mais pedidos, você tem que mover o servidor inteiro.
• 3:02
  Você precisa literalmente pegar toda a despensa, empacotar todas as caixas e mudar pra um prédio novo. É lento e ineficiente. Tá, e no hyperscale? No hyperscale, a arquitetura separa tudo.
• 3:13
  A despensa agora é um prédio gigantesco e independente. Se a sua cozinha precisar de mais fogões, você adiciona poder de processamento em minutos, sem precisar mover um único megabyte da despensa.
• 3:23
  Olha, a analogia é excelente. Ela ilustra bem a separação. Só que ela também me faz pensar numa falha óbvia aí: a latência. Como assim?
• 3:31
  Ué, se a despensa tá num prédio totalmente separado, os cozinheiros não teriam que ficar esperando os ingredientes chegarem?
• 3:38
  Porque em banco de dados, milissegundos de espera no disco destroem a performance de qualquer aplicativo. Ah, você tocou num ponto crucial.
• 3:45
  Mas é exatamente esse o desafio que o hyperscale resolveu com um componente chamado page servers, ou servidores de página. Tá, e como eles funcionam na prática?
• 3:55
  Imagina que eles são uma frota de elevadores de carga super-rápidos e despensas locais menores. O hyperscale não deixa a cozinha esperando.
• 4:04
  Ele mantém os dados mais acessados na memória do servidor principal e usa SSDs locais como um cache. Então os ingredientes mais usados ficam ali perto do fogão. Exato.
• 4:14
  Os page servers ficam no Azure, gerenciando o armazenamento pesado na nuvem, entregando os blocos de dados de forma distribuída. Você ganha a elasticidade de uma despensa infinita, mas mantém a velocidade.
• 4:26
  E essa separação resolve dores reais, tipo a lentidão de backups. É, backups sempre foram um gargalo horrível de processamento. Nossa, sim. No modelo antigo, fazer o backup exige que o sistema leia tudo do disco.
• 4:38
  É como forçar a equipe da cozinha a parar de cozinhar no meio do jantar pra ir contar pacote de arroz na despensa. Sim, trava tudo. Mas como o hyperscale isola o armazenamento, o backup é baseado em snapshots.
• 4:50
  Ele tira uma foto instantânea da despensa. A cozinha nem fica sabendo que o backup aconteceu. E restaurar terabytes leva só uns minutos.
• 4:58
  Ok, do ponto de vista de operação, eu admito que essa agilidade de restauração é fantástica. Só que essa mesma arquitetura traz umas coisas que me parecem complexidade desnecessária pra maioria das empresas.
• 5:09
  Você diz as réplicas. Isso, as réplicas nomeadas. Mas elas são geniais. O hyperscale deixa você criar até 30 cozinhas extras conectadas na mesma despensa.
• 5:19
  Se a empresa tem relatórios pesados de fim de mês que deixam o sistema lento, você cria uma cozinha extra que só lê os dados. O relatório roda lá, sem atrapalhar os usuários do aplicativo. Tá, soa incrível na teoria.
• 5:29
  Mas vamos ser bem pragmáticos aqui. Um aplicativo pequeno de 10 GB realmente precisa de 30 réplicas de leitura? Parece que a gente tá usando uma bazuca pra matar uma mosca.
• 5:40
  E pior, isso ignora a realidade da infraestrutura tradicional de muitas empresas. A que recursos você tá se referindo exatamente? Recursos de nível de instância.
• 5:49
  Grande parte das empresas depende do SQL Server Agent, por exemplo, que gerencia tarefas automatizadas, ou do Database Email pra mandar e-mail direto do banco, ou consultas entre vários bancos diferentes.
• 6:02
  É, o hyperscale realmente foca no banco isolado. Exatamente. Ele não serve pra essas coisas porque ele não te dá o servidor completo, ele foca num banco só.
• 6:11
  Nesses cenários, o Azure SQL Managed Instance é a escolha muito mais lógica. Ele foi feito pra migrar essas cargas de trabalho antigas sem dor de cabeça, suportando até 100 bancos e vai chegar a 500 na próxima geração.
• 6:24
  Se eu quero previsibilidade e segurança, eu vou pro Managed Instance, não pro Hyperscale.
• 6:30
  Olha, eu concordo totalmente que se o seu ecossistema é dependente de coisas como o SQL Server Agent, o Hyperscale não vai te atender agora. O próprio autor do post deixa isso claro.
• 6:41
  O Managed Instance é ótimo pra modernizar sistemas legados sem reescrever nada. Sim, ele não exige quebrar a cabeça. Só que forçar a empresa a usar um banco isolado no Hyperscale impulsiona práticas melhores de nuvem.
• 6:53
  Você passa a usar Azure Logic Apps ou Functions no lugar do velho SQL Agent. Dá trabalho no começo? Dá, mas destrava uma elasticidade que o Managed Instance não chega nem perto de ter.
• 7:04
  E essa elasticidade impacta direto nos custos, que eu sei que é o seu maior medo. Bom, já que você tocou no ponto financeiro, vamo falar a verdade aqui.
• 7:12
  O custo real do Hyperscale é uma dor de cabeça pro gestor, especialmente pelo fator licenciamento. Você tá falando da mudança de dezembro de 2023? Sim. Eles mudaram as regras no meio do jogo.
• 7:25
  O preço base do Hyperscale não inclui mais a licença do SQL Server. E o tal do benefício híbrido, o Azure Hybrid Benefit, não se aplica a novos bancos de dados lá.
• 7:35
  O preço do processamento caiu bastante com essa separação, vale lembrar. Pode até ter caído, mas bagunçou a contabilidade.
• 7:43
  Imagina você alugar um carro na nuvem e a locadora diz: "Ah, o chassi tá mais barato, mas o motor a gente cobra por fora e não aceita mais o seu cupom de desconto antigo."
• 7:52
  Gerenciar licenças da Microsoft já é um terror de regras rígidas, contratos de Software Assurance, limites de 180 dias de uso duplo.
• 8:01
  Essas regras se aplicam estritamente ao Managed Instance, mas no Hyperscale, virou um cenário confuso de preços que o gestor tem que decifrar.
• 8:09
  Eu não vou ignorar esse argumento do custo porque ele é real e assusta, mas o grande contraponto a essa mudança de licença é a elasticidade do modelo serverless ou sem servidor fixo. Como isso compensa a licença?
• 8:21
  Pensa comigo. No modelo tradicional do Managed Instance, se você tem picos de acesso no fim do mês, você é obrigado a pagar por um servidor gigante o mês inteiro.
• 8:29
  Ele fica lá, ocioso, jogando o dinheiro da licença no lixo. No Hyperscale Serverless, a cozinha cresce e diminui sozinha, baseada na demanda, em minutos. Então ele escala a CPU automaticamente. Exato.
• 8:41
  E o melhor, você é cobrado por segundo de processamento. Se não tem acesso nenhum, ele pode até pausar a computação e você paga quase nada, só o armazenamento.
• 8:49
  A economia de não ter recurso ocioso compensa de longe essa questão da licença desmembrada. Você só paga o que usa. Pagar por segundo é o sonho de qualquer gestor financeiro, não vou negar.
• 9:00
  Só que o serverless troca a ineficiência pela imprevisibilidade total. E se um desenvolvedor solta uma consulta mal feita no sistema?
• 9:09
  O banco vai escalar até o infinito pra tentar processar e a empresa vai pagar essa conta por segundo. No fim do mês, a fatura é um pesadelo. Mas aí é só configurar os limites máximos, né?
• 9:19
  Você pode definir um teto, tipo, escale até no máximo 16 núcleos. Você não deixa a conta estourar. Ajuda, com certeza.
• 9:27
  Mas, sinceramente, essa imprevisibilidade não é nada comparada ao contra-argumento mais forte que o texto do Alex traz. O golpe mais duro de todos. Ah, a porta de mão única. Exatamente. A trava de saída.
• 9:41
  Imagina que eu sou o gestor, resolvo apostar no Hyperscale e descubro que não era bem o que eu precisava.
• 9:47
  Se eu criar um banco direto lá, eu não posso só mudar uma configuração e voltar pra uma camada mais simples, como a General Purpose. É, o sistema não deixa você rebaixar nativamente. Pois é.
• 9:58
  E se eu pego um banco que já existe e converto ele pro Hyperscale? Eu tenho uma janela minúscula de 45 dias pra me arrepender. Deu 46 dias, a porta fecha, cabou.
• 10:09
  O sistema apaga os arquivos que deixariam você voltar de forma automática. E aí, a única saída é exportar todos os seus dados manualmente, arquivos bacpac pesadíssimos, e carregar tudo num banco novo.
• 10:22
  Isso é custoso, demora uma eternidade e o risco de perder dados de produção de uma empresa é altíssimo. Sinceramente, é uma armadilha operacional. Olha, eu concordo totalmente com você nisso.
• 10:34
  É o maior risco do Hyperscale, sem dúvida. E a explicação técnica pra isso é que lembra que o armazenamento foi fragmentado naqueles page servers? Sim, os elevadores de carga.
• 10:46
  Pois é, os dados foram divididos em pedaços de um gigabyte e espalhados na nuvem.
• 10:51
  Depois de 45 dias operando assim, não tem como a Microsoft simplesmente apertar um botão e colar todos os caquinhos de volta num arquivo legado.
• 10:59
  Mas é exatamente por isso que o conselho principal do autor do post é tão genial. Testar antes de casar com o serviço. Perfeito. Ele diz que é essencial você escrever o motivo de tá escolhendo o Hyperscale.
• 11:11
  Você não muda seu banco de produção amanhã de manhã às cegas. O Alex Rosa mesmo, no post, conta que tá montando um laboratório de 30 dias só pra isso. Pra colocar a carga real de trabalho e ver se a conta fecha.
• 11:23
  Sim, testar o custo real, ver como a performance de CPU escala na prática e comparar lado a lado com um Managed Instance. Tudo isso antes de passar pela tal porta de mão única. É mitigação de risco puro.
• 11:35
  Bom, sendo bem honesto, eu tenho que concordar que uma simulação dessas, um laboratório de 30 dias com dados empíricos, é a forma correta de tomar essa decisão.
• 11:44
  E resumindo o nosso embate aqui, acho que nós dois concordamos num ponto central, né? Que a arquitetura é incrível. Sim, a ideia de separar a cozinha da despensa é tecnicamente brilhante.
• 11:54
  Quebra aquele mito antigo de que o Hyperscale é só pra quem faz big data. Resolveu dores crônicas como backups demorados e relatórios lentos de uma forma muito elegante.
• 12:04
  Com certeza, ele entrega uma agilidade que era ficção científica há uns anos. Só que, e aqui eu mantenho minha postura como gestor, a decisão final depende inteiramente do contexto atual de cada empresa.
• 12:15
  Se a sua empresa ainda tá muito presa a rotinas antigas, que dependem do SQL Agent, ou se tem contratos de licenciamento muito específicos que não compensam a perda do benefício híbrido, o Hyperscale simplesmente não é pra você.
• 12:28
  Nesses casos, o Managed Instance continua sendo a melhor pedida. É uma avaliação justíssima. A inovação tecnológica não anula o contexto do negócio.
• 12:36
  Então o nosso próximo passo prático pra você que tá nos ouvindo é: faça como o autor do texto.
• 12:41
  Monte um ambiente de laboratório, rode a sua carga de trabalho específica lá dentro, observe a conta no fim do mês no modelo serverless e tome uma decisão baseada nos seus números, não no hype. Exatamente.
• 12:53
  Dados reais, sempre. E pra entender as minúcias dessa arquitetura e como montar esse laboratório na prática, nós convidamos todos vocês a lerem o post completo.
• 13:01
  É totalmente gratuito e tá disponível lá no InTechOrNot.com. Anotem aí, InTechOrNot.com. E só um aviso rápido: o texto no site tá escrito em inglês, ok?
• 13:14
  Obrigado por acompanhar este debate inspirado na newsletter We the People, InTech or Not. Até a próxima.