Azure

Sexto post da série. No anterior, automatizamos provisioning de clusters GPU. Agora entra a parte que começa depois do hardware pronto: como um modelo sai do “funciona no meu notebook” e vira algo que roda em produção com SLA. tl;dr: Modelo não é arquivo solto. Registre versão, valide em staging, publique com canary e deixe rollback pronto. O modelo que chegou sem certidão de nascimento Um data scientist manda uma mensagem no canal do time com um link pra um shared drive: “Aqui está o modelo. É um checkpoint PyTorch de 15 GB. Precisamos em produção até sexta.” ...

Quinto post da série. No anterior, entramos no detalhe da GPU. Agora é hora de automatizar o que fica ao redor dela. Entender GPU é metade do trabalho. Provisionar tudo isso de forma consistente, repetível e auditável é a outra metade. tl;dr: IaC em AI não é capricho. É o que evita SKU errado, drift, cluster caro esquecido e pipeline sem trilha de auditoria. O typo de $4.000 Imagina o cenário: você provisiona um cluster GPU manualmente em East US 2 pra um experimento de ML. AKS com node pool Standard_NC6s_v3, accelerated networking, drivers NVIDIA, taints corretos. Leva quase um dia, mas funciona. ...

Quarto post da série. No anterior, você viu quais VMs GPU provisionar e como conectar elas. Agora a ideia é olhar dentro da GPU pra entender o que acontece no silício. Não pra escrever CUDA kernel, mas pra ser um troubleshooter melhor e conversar com o time de ML sem ficar no modo adivinhação. tl;dr: O tamanho do checkpoint não diz quanta VRAM o treino vai consumir. Em GPU, pesos são só o começo. Gradientes, ativações e estado do otimizador é que costumam explodir a conta. ...

Terceiro post da série onde traduzo AI pra linguagem de quem vive infraestrutura. No post anterior, falamos do gargalo escondido de storage. Hoje a conversa é sobre compute. A diferença não está em comprar a GPU mais cara da prateleira. Está em escolher a GPU certa e ligar tudo do jeito certo. tl;dr: Em AI, escolher compute é escolher workload, memória e interconexão. GPU errada ou rede errada faz você pagar caro pra terminar mais devagar. ...

Esse é o segundo post da série onde traduzo o mundo de AI pra linguagem de engenheiros de infraestrutura. No primeiro post, mostrei que AI é só mais um workload e que suas habilidades de infra já te deixam bem mais perto desse mundo do que parece. Agora é hora de falar do gargalo que quase todo mundo descobre tarde demais: storage. tl;dr: GPU cara parada quase sempre significa dado chegando devagar. Pra treino de AI, storage e cache local decidem a utilização da GPU tanto quanto a placa que você comprou. ...

Esse é o primeiro post de uma série onde vou traduzir o mundo de AI pra linguagem que engenheiros de infraestrutura já falam. Se você é o tipo de profissional que configura VMs, monta pipelines de CI/CD e acorda de madrugada quando o Nagios dispara, esse conteúdo é pra você. A série é baseada no meu livro open-source AI for Infrastructure Professionals, adaptada e expandida aqui em português. tl;dr: AI não pede que você vire data scientist. Pede que você aplique o que já sabe de compute, rede, segurança, observabilidade e custos num workload novo. O jargão muda. Os fundamentos continuam. ...

Introdução: No âmbito da computação em nuvem, otimizar os custos é fundamental para empresas que utilizam o Microsoft Azure. O Azure oferece dois mecanismos principais de economia de custos: Azure Reservations e Savings Plans. Ambas as opções possuem vantagens, desvantagens e cenários de uso distintos. Neste guia abrangente, exploraremos esses recursos, penalidades e casos de uso ideais para capacitar você a tomar decisões informadas adaptadas às necessidades do seu negócio. Compreendendo as Reservas do Azure (Azure Reservations): As Reservas do Azure oferecem às empresas a oportunidade de se comprometerem com planos de um ou três anos para diversos produtos dentro do ecossistema do Azure. O compromisso envolve uma promessa de uso, permitindo descontos significativos de até 72% nos preços de pagamento conforme o uso. ...

Se você estiver desenvolvendo seus aplicativos nativos em nuvem, recomendo fortemente que você consulte este guia mesmo que não esteja usando Azure especificamente. Estilos de arquitetura N-tier: divide um aplicativo em camadas lógicas e camadas físicas Web-queue-worker: frontend e backend dissociados por mensagens assíncronas Microserviços: serviços funcionalmente decompostos que chamam uns aos outros por meio de APIs Arquitetura orientada a eventos: produtor/consumidor. Visão independente por subsistema Big data: divida um enorme conjunto de dados em pequenos pedaços. Processamento paralelo em datasets locais Big compute: alocação de dados para milhares de núcleos Escolhas tecnológicas Escolha do serviço de computação Escolha do serviço de armazenamento de dados Escolha do serviço de mensagens assíncronas Design da arquitetura Arquiteturas de referência: Cada arquitetura de referência inclui práticas recomendadas, juntamente com considerações sobre escalabilidade, disponibilidade, segurança, resiliência e outros aspectos do design Princípios de design: 10 princípios de design de alto nível que tornarão seu aplicativo mais escalonável, resiliente e gerenciável Padrões de design: Esses padrões de design são úteis para construir aplicativos confiáveis, escaláveis e seguros na nuvem Práticas recomendadas: abrangem diversas considerações de design, incluindo design de API, escalonamento automático, particionamento de dados, armazenamento em cache e assim por diante. Melhores práticas de segurança: descreva como garantir que a confidencialidade, integridade e disponibilidade da sua aplicação não sejam comprometidas por agentes mal-intencionados. Pilares de qualidade Microsoft Azure Well-Architected Framework Mais detalhes Conceitos básicos de arquitetura de aplicações

O Azure é uma excelente plataforma de computação em nuvem com muitos recursos e funcionalidades interessantes, sendo as opções para containers realmente incríveis. Porém uma coisa que percebo em muitos clientes hoje são dúvidas e desconhecimento sobre detalhes destas opções. Pensando nisso estou escrevendo esse artigo para esclarecer um pouco sobre este assunto. Atualmente, as opções mais interessantes para containers no Azure são oferecidas nas soluções PaaS, que serão o objetivo deste post. Logo, não irei entrar nos detalhes sobre uso de containers em IaaS por ser o modelo mais tradicional e possuir a mesma forma de implementação independente do cloud provider. ...

O objetivo deste artigo é descrever de forma detalhada como implementar a Stack ELK (Elasticsearch/Logstash/Kibana) no Azure. Introdução Este artigo é resultado de uma prova de conceito para mostrar a funcionalidade de implementação de toda a stack utilizando a ferramenta de linha de comando do Azure (az-cli) Arquitetura A ilustração abaixo se refere à arquitetura lógica implantada para provar o conceito. Esta arquitetura contempla um servidor de aplicação, o serviço de Redis do Azure, um servidor com o Logstash, um servidor com ElasticSearch e um servidor com o Kibana e serviço web (Nginx) instalados. ...