O tópico de hoje é algo que quase todo mundo já ouviu falar, mas quase ninguém sabe explicar. Serverless. O que é exatamente? Será que é realmente código rodando no nada, ou é algo muito maior? Deixar uma coisa clara. Servers não significa que não existem servidores. Significa que você não precisa pensar neles. E essa distinção muda tudo na forma como você cria software. Ao final deste episódio, você entenderá o que são as Azure Functions, como a precificação funciona e quando você deve usá-las. Vamos dividir isso em blocos fundamentais, começando pelo maior mito. O que serverless realmente significa? Vamos esclarecer alguns mitos logo de cara. O nome serverless é o pior termo de marketing que a Microsoft já inventou. Ele faz as pessoas pensarem que literalmente não há servidor envolvido. Isso não é verdade. Existem servidores. Você apenas nunca precisa tocar. Há 20 anos, se você quisesse rodar um código na internet e tinha que trabalhar muito, você alugava uma máquina virtual, instalava um sistema operacional, configurava um servidor web e implantava sua aplicação.

Depois passava todo fim de semana aplicando atualizações de segurança e garantindo que nada travasse às 3 da manhã. E tem um detalhe. Você pagava por aquele servidor e tivesse seu código rodando ou não. Ele ficava lá funcionando, queimando dinheiro enquanto você dormia. O serverless vira esse modelo de cabeça para baixo e escreve seu código, faz o upload e a plataforma cuida de todo o resto. O sistema operacional, patches de segurança, escalonamento e disponibilidade. Seu trabalho é apenas escrever a lógica que importa. Pense nisso como a diferença entre manter a cozinha de um restaurante e usar uma máquina de venda automática. Cozinha de um restaurante precisa de uma equipe completa, suprimentos constantes e manutenção. Custa dinheiro todo santo dia, mesmo que ninguém passe pela porta. Uma máquina de venda automática fica lá no canto sem fazer nada, até alguém apertar um botão. Então ela ganha vida, faz seu trabalho e volta a dormir.

Você só paga pela eletricidade quando ela está realmente funcionando. Isso é serverless em poucas palavras. Azure Functions é a versão da Microsoft para isso. Ela executa pequenos pedaços de código em resposta a eventos. Seu código fica dormente até que algo desperte, então ele roda, termina e volta a dormir. Então como esse código realmente se parece? O que são as Azure Functions? Uma função é um único pedaço de código que faz uma tarefa específica. Não é uma aplicação inteira com páginas de login, banco de dados e 20 telas. É uma tarefa focada. Pense nisso como interruptor de luz da sua casa, ou está desligado, ou ligado trabalhando, e depois desliga de novo. Um servidor web tradicional é o oposto, como deixar todas as luzes da casa acesas 24 horas por dia, 7 dias por semana, mesmo sem ninguém em casa. O Azure Functions oferece suporte a várias linguagens de programação diferentes. Você pode usar o que preferir, JavaScript, Python, Cshava, Java, PowerShell, PowerShell.

Mas existe uma resposta certa. Escolha a linguagem que você já conhece. Agora, vamos esclarecer uma confusão comum. O Function App não é a mesma coisa que uma função. O Function App é o container. Pense nisso como a caixa de ferramenta. Você cria um Function App, e dentro dessa caixa adiciona várias funções. Cada função é uma ferramenta separada que realiza sua própria tarefa. Você pode ter uma função que lida com registros de usuários, outra que processe imagens enviadas, e uma terceira que envia relatórios noturnos. Todas vivem na mesma caixa de ferramenta, mas funcionam de forma independente. Mais uma coisa sobre funções. Elas são stateless, sem estado por design. Isso significa que elas não lembram de nada entre as execuções. Se sua função processa um arquivo e termina, é isso. A próxima vez que rodar, ela começa do zero, sem memória da vez anterior. Isso parece uma limitação, mas na verdade é o recurso que as torna tão poderosa.

Como as funções não retém memória ou estado, o Azure pode subir 100 cópias da sua função instantaneamente quando o tráfego aumenta, e desligá-las tão rápido quanto quando o tráfego cai. É assim que você obtém escalabilidade sem pagar por servidores ociosos. Aqui está a pergunta. Se uma função fica lá parada sem fazer nada até que algo a desperte, o que realmente a desperta? É aí que entra os gatilhos. Gatilhos são o quando. Toda função deve ter exatamente um gatilho, e isso não é opcional. O gatilho é o evento que desperta a sua função. Sem ele, seu código fica parado lá sem fazer absolutamente nada. Pense nos gatilhos com uma campainha. Sua função está dentro de casa esperando. Ela poderia esperar para sempre. Nada acontece até que alguém toque a campainha. Então a função entra em ação, atende a porta, faz seu trabalho e volta a esperar. Existem quatro gatilhos que os iniciantes encontram com mais frequência.

O gatilho HTTP é o ponto de partida mais comum. Alguém acessa uma URL ou faz uma chamada de API, e sua função é disparada. É assim que você constrói APIs leves, sem precisar configurar um servidor web completo. Depois há o gatilho de temporizador timer que roda em uma dinâmica. Você define uma expressão Chrome, como executar a cada hora ou à meia-noite e todas as noites, e sua função é disparada exatamente nesses momentos. Perfeito para tarefas de manutenção, trabalhos de limpeza e geração de relatórios noturnos. O gatilho de blob é disparado quando um arquivo é carregado no armazenamento do azul. Digamos que alguém envia um PDF com uma pasta específica. O gatilho de blob detecta esse envio e executa sua função automaticamente. Isso é excelente para processamento de imagens, conversão de documentos e validação de arquivo. O gatilho de fila é disparado quando uma mensagem aparece em uma fila.

Filas são uma forma de desacoplar diferentes partes do seu sistema. Um serviço coloca uma mensagem em uma fila, e sua função a captura e processa quando estiver pronta. Isso evita que um serviço lento bloqueie todo o restante. Aqui está o ponto principal. Quando um gatilho é disparado, ele passa dados para a sua função automaticamente. Você não precisa fazer consultas nem verificar se algo aconteceu. O gatilho entrega tudo o que você precisa, e sua função apenas processa. Uma função sem gatilho é apenas um código parado sem fazer nada. O gatilho é o que lhe dá um propósito. Portanto, o gatilho diz a sua função quando executar. Mas de onde vêm os dados e para onde eles vão? É aí que entram as vinculações. Vinculações dados de entrada e dados de saída. As vinculações são uma maneira de dizer à sua função quais dados ler e para onde enviar resultados sem escrever código extra. Isso parece complicado, então deixe-me simplificar.

Dois tipos. As vinculações de entrada trazem dados para a sua função. As vinculações de saída enviam dados para fora. Sem vinculações, você teria que escrever código de SDK toda vez que quisesse falar com uma conta de armazenamento, banco de dados ou fila. Teria que gerenciar strings de conexão, tentativas de serializar dados e de serializar respostas. Isso é muito código repetitivo apenas para ler um arquivo. Com vinculações, você apenas declara o que precisa. Se diz que quer ler deste container de blob ou quer escrever nesta fila, o ambiente de execução cuida do resto. Ele abre a conexão, lê os dados e os passa para a sua função como um parâmetro. Quando sua função termina, ele pega o valor de retorno e o escreve onde você especificou. Pense nas vinculações com tubulações. Você conecta sua função a conta de armazenamento, banco de dados ou fila. Os dados fluem por essas tubulações automaticamente.

Sua função não precisa saber como as tubulações funcionam. Ela apenas recebe o que vem e envia o que precisa sair. Aqui está um exemplo concreto. Digamos que você tenha uma vinculação de entrada. Quando sua função inicia, ela lê automaticamente um arquivo de armazenamento de blobs e o entrega a você como um parâmetro. Você não escreve nenhum código de SDK de armazenamento. Você apenas recebe os dados desse processo. Outro exemplo, um binding de saída de fila. Sua função processa algo e, ao final, você retorna um valor. O runtime pega esse valor, serializa-o e o coloca na fila. Você não escreve nenhum código de fila. Você apenas retorna um valor. Binds são opcionais. Você pode ter zero, um ou muitos. Algumas funções precisam apenas de um gatilho sem nenhum binding. Outras podem ter três ou quatro bindings conectando a diferentes serviços. A combinação de gatilhos e bindings é o que torna os refunctions tão poderoso.

Você escreve a lógica de negócio, o código de tomada de decisão real. A plataforma cuida de toda a integração. Sua função permanece pequena, focada e fácil de entender. A história dos preços. O preço é o que mais surpreende os iniciantes. Para a maioria das pessoas, o plano de consumo é a escolha padrão. E você deve começar com ele 90% das vezes. Veja como funciona. Você paga apenas quando sua função realmente é executada. Quando ela está ociosa, você não paga nada. Zero, nem um centavo. Dois componentes compõem a fatura. Primeiro, o número de execuções. Quantas vezes sua função é disparada? Segundo, o tempo de execução medida em algo chamado GB segundos. Isso é basicamente quanto tempo sua função rodou multiplicada por quanto a memória ela usou. A cota gratuita é generosa. Você recebe um milhão de execuções por mês e 400 mil gigas segundos totalmente gratuitos. Para a maioria dos pequenos projetos, aplicativos de hobby e protótipos, você nunca pagará um centavo.

Nunca. Se você exceder a cota gratuita, as taxas ainda são incrivelmente baratas. 20 centavos por um milhão de execuções. Isso não é uma erva de digitação. 20 centavos por um milhão de execuções. Pense nisso com pagar pela eletricidade apenas quando você liga o interruptor. Não há taxa base mensal por ter afiação nas paredes. Você só paga pela energia que realmente usa. Agora existem outros planos. Flex Consumption é mais novo e oferece suporte à rede virtual. Premium mantém suas funções sempre ativas para que não haja atraso de custo. O Dedicated oferece capacidade fixa em um app service plan tradicional. Mas para começar, o plano Consumption é a escolha certa quase sempre. No entanto, a cota gratuita é compartilhada entre todos os seus Function Apps na mesma assinatura. Se você tiver 10 Function Apps, todos eles consomem o mesmo milhão de execuções gratuitas. Portanto, fique de olho nisso se você começar a criar mais do que alguns.

Preço é ótimo. Mas vamos tornar isso real com um exemplo concreto. Um cenário do mundo real. Imagine que você gerencia um site onde usuários fazem upload de fotos de perfil. Essas imagens são enormes, tipo 10 megabytes cada. Isso causa alguns problemas reais. Arquivos grandes custam mais para armazenar, deixam seu site lento sempre que alguém carrega uma página e frustram seus usuários que precisam esperar pelas fotos. Então você precisa de uma maneira de reduzir essas imagens automaticamente. Sem o Azure Functions, você teria que criar um worker de segundo plano do zero. Isso significa obter um servidor separado, configurar uma fila para gerenciar carga de trabalho e escrever código para lidar com todas as partes móveis. Isso é um monte de complexidade desnecessária para algo tão simples quanto reduzir uma imagem. Com o Azure Functions, tudo o que você precisa é um gatilho de blob e uma função.

Sem servidores para se preocupar. Deixe-me explicar como funciona. Um usuário faz o upload de uma foto pelo seu site e esse arquivo vai para o armazenamento de blob do azul. No momento em que chega, um gatilho de blob dispara automaticamente. Sua função desperta, executa o código de compressão e salva a versão menor de volta no armazenamento. Tudo isso acontece em segundos. O usuário nunca espera porque todo o processo ocorre nos bastidores de forma totalmente invisível. Que tal outro exemplo cotidiano? Enviar um e-mail de boas-vindas quando alguém se inscreve no seu serviço. Um gatilho HTTP captura a solicitação de inscrição do seu site. Sua função dispara, pega o endereço de e-mail do usuário, envia uma mensagem de boas-vindas pelo SendGrid e pronto. O usuário recebe o e-mail quase instantaneamente. Sem servidor de e-mail para configurar, sem fila de envio para gerenciar. Apenas uma função, um trabalho, concluído.

Esses são exatamente os trabalhos pelos quais o Azure Functions foi projetado. Tarefas pequenas, focadas e orientadas à venda. Não aplicativos massivos, não fluxos de trabalho complexos, apenas uma coisa feita bem e acionada por algo acontecendo em outro lugar. Quando usar o Azure Functions? Então, quando você deve recorrer a uma função e quando deve usar a outra coisa? De tal maneira rápida, decide. Pergunte a si mesmo se a tarefa é curta, se é orientada a eventos e se é sem estado. Se você respondeu sim para as três, o Azure Functions é provavelmente a ferramenta certa. Vamos começar com os bons casos, Ju. APIs e Webhooks são uma combinação perfeita. Você precisa de um endpoint leve que responda a uma solicitação HTTP, faça uma coisa e retorne um resultado. E é exatamente para isso que os gatilhos HTTP são feitos. Processamento de arquivos e imagens é outro grande exemplo. Um arquivo chega ao armazenamento, sua função dispara, transforma e salva o resultado, tudo sem um servidor.

Tarefas agendadas, como limpeza noturna ou geração de relatórios, funcionam muito bem com gatilhos de tempo. Transformação de dados para pipeline GTL também é comum. E as funções são a cola de integração perfeita, conectando dois serviços que não se comunicam naturalmente. Agora, vamos falar sobre quando as funções não são adequadas. Processos de longa duração são um problema, pois no plano de consumo as funções têm um limite de tempo e limite de 5 minutos por padrão, chegando a 10 se configurado. Chegando a 10 se configurar. Se o seu trabalho leva mais tempo que isso, você precisa de outra solução. Aplicações com estado e stateful são outra compatibilidade. Funções não lembram de nada entre as execuções. Se você precisa manter o estado da sessão ou acompanhar o progresso entre etapas, você está indo contra o design. Cargas de trabalho de computação pesada também não são indicados. Se você precisa de CPU sustentada por minutos ou horas, uma máquina virtual ou container é uma escolha melhor.

E fluxos de trabalho complexo, onde uma tarefa depende de outra, são melhor tratados por Durable Functions ou Logic Apps. Aqui está uma visão geral rápida da sua treinante. O Azure Logic Apps é a opção sem código para conectar serviços. Se você não precisa escrever código personalizado, o Logic Apps pode fazer o trabalho com design visual. O Azure App Service é para aplicações web completas que rodam 24x7. Se você precisa de um site completo ou uma API que esteja sempre ativa, essa é a sua ferramenta. O Azure Container Apps oferece micro-serviços em containers com mais controle sobre o tempo de execução. E as máquinas virtuais do Azure oferecem controle total sobre o sistema operacional se você precisar. E aqui está uma regra prática sim. Se você consegue descrever o trabalho em uma frase, provavelmente é um bom candidato para uma função. Compactar imagens quando são carregadas. Enviar um e-mail de boas-vindas quando alguém se cadastra.

Executar um trabalho de limpeza toda noite mesmo. Uma frase, um trabalho, uma função. Erros comuns de iniciantes para evitar. Agora, vamos falar sobre algumas coisas para ficar atento. Esses são os erros que fazem quase todo mundo tropeçar ao começar. Um erro comum de iniciante é pensar que as funções são sempre gratuitas. A concessão gratuita é generosa. Eu sei que um milhão de execuções parece muito. Mas se sua função viralizar ou for bombardeada por um bot, essas execuções somam rapidamente. Portanto, monitore seu uso, configure um alerta de orçamento no Azure e não tenha uma conta surpresa no final do mês. Outro erro é ignorar as inicializações a frígocos. A primeira vez que sua função é executada após ficar ociosa, ela demora mais. No plano de consumo, isso pode levar alguns segundos. Para a maioria dos casos de uso, se aceita. Mas, se você está criando uma API sensível à latência onde cada milissegundo importa, considere o plano premium ou habilite instâncias sempre prontas.

Então, há o erro de escrever funções que rodam por demais. O plano de consumo tem um tempo limite de 5 minutos por padrão, 10 minutos no máximo. Se sua função leva 15 minutos para processar um arquivo, ela será encerrada no meio do processo. Divida esse trabalho em partes menores ou use um plano de hospedagem diferente. Outro erro fácil de ignorar é não usar a implantação RunFromPackage. É uma mudança simples de configuração que melhora a code start e se torna as implantações mais confiáveis. Em vez de copiar arquivos individuais, você implanta um pacote zip. É apenas uma caixa de seleção do portal faça aí. Expor endpoints HTTP sem autenticação é outra amadilha. É fácil deixar uma função como anônima durante os testes e depois esquecer de protegê-la. Defina seu nível de autorização corretamente desde o início. Use chave de função ou de administrador. Deixa a porta aberta. Eu utilizar contas de armazenamento em vários aplicativos de função também é um problema.

No desenvolvimento, não há problema em compartilhar. Em produção, cada aplicativo de função deve ter sua própria contramenta. Caso contrário, você terá problemas de vizinho barulhento onde o tráfego de uma função atrasa a outra. E finalmente, não habilitar o Application Insights. Sem ele, você está voando a sério. Você não verá falhas, erros ou problemas de desempenho. Você não saberá se sua função está rodando por muito tempo ou falhando silenciosamente. Habilite o primeiro dia. Leva 30 segundos e economiza horas de depuração. A regra de ouro para tudo isso é manter suas funções pequenas, focadas e sem estado. Uma tarefa por função, nada mais? Então esse é o sistema. Wide Your Functions é uma computação sem servidor que executa pequenos trechos de código em resposta a eventos. Você só paga quando seu código executa. Gatilhos dizem a sua função quando despertar. Bindings a conectam aos dados necessários e o plano de consumo a mantém quase gratuita para pequenos projetos.

Sua melhor estratégia agora é criar uma função simples com gatilho HTTP no portal do Azure. Leva 5 minutos e não custa nada. Inscreva-se no Microsoft Knowledge Nuggets para mais explicações simples e compartilhe isso com alguém que vive perguntando o que significa serverless. Peral.