WEBVTT

00:00:00.000 --> 00:00:03.720
O tópico de hoje é algo que quase todo mundo já ouviu falar, mas quase ninguém sabe explicar.

00:00:04.260 --> 00:00:05.380
Serverless. O que é exatamente?

00:00:05.940 --> 00:00:08.340
Será que é realmente código rodando no nada, ou é algo muito maior?

00:00:08.900 --> 00:00:09.780
Deixar uma coisa clara.

00:00:10.380 --> 00:00:11.740
Servers não significa que não existem servidores.

00:00:12.120 --> 00:00:13.520
Significa que você não precisa pensar neles.

00:00:13.660 --> 00:00:16.020
E essa distinção muda tudo na forma como você cria software.

00:00:16.620 --> 00:00:19.100
Ao final deste episódio, você entenderá o que são as Azure Functions,

00:00:19.220 --> 00:00:21.260
como a precificação funciona e quando você deve usá-las.

00:00:21.920 --> 00:00:24.560
Vamos dividir isso em blocos fundamentais, começando pelo maior mito.

00:00:25.380 --> 00:00:26.820
O que serverless realmente significa?

00:00:27.380 --> 00:00:28.640
Vamos esclarecer alguns mitos logo de cara.

00:00:28.640 --> 00:00:32.220
O nome serverless é o pior termo de marketing que a Microsoft já inventou.

00:00:32.720 --> 00:00:35.020
Ele faz as pessoas pensarem que literalmente não há servidor envolvido.

00:00:35.340 --> 00:00:36.760
Isso não é verdade. Existem servidores.

00:00:37.240 --> 00:00:38.180
Você apenas nunca precisa tocar.

00:00:38.600 --> 00:00:42.000
Há 20 anos, se você quisesse rodar um código na internet e tinha que trabalhar muito,

00:00:42.800 --> 00:00:45.380
você alugava uma máquina virtual, instalava um sistema operacional,

00:00:45.520 --> 00:00:47.440
configurava um servidor web e implantava sua aplicação.

00:00:48.020 --> 00:00:50.420
Depois passava todo fim de semana aplicando atualizações de segurança

00:00:50.420 --> 00:00:52.160
e garantindo que nada travasse às 3 da manhã.

00:00:52.700 --> 00:00:53.220
E tem um detalhe.

00:00:53.880 --> 00:00:55.980
Você pagava por aquele servidor e tivesse seu código rodando ou não.

00:00:55.980 --> 00:00:58.820
Ele ficava lá funcionando, queimando dinheiro enquanto você dormia.

00:00:59.260 --> 00:01:02.620
O serverless vira esse modelo de cabeça para baixo e escreve seu código,

00:01:02.760 --> 00:01:04.820
faz o upload e a plataforma cuida de todo o resto.

00:01:05.320 --> 00:01:08.320
O sistema operacional, patches de segurança, escalonamento e disponibilidade.

00:01:08.960 --> 00:01:10.800
Seu trabalho é apenas escrever a lógica que importa.

00:01:11.400 --> 00:01:13.740
Pense nisso como a diferença entre manter a cozinha de um restaurante

00:01:13.740 --> 00:01:15.080
e usar uma máquina de venda automática.

00:01:15.680 --> 00:01:17.660
Cozinha de um restaurante precisa de uma equipe completa,

00:01:17.780 --> 00:01:18.920
suprimentos constantes e manutenção.

00:01:19.420 --> 00:01:22.120
Custa dinheiro todo santo dia, mesmo que ninguém passe pela porta.

00:01:22.120 --> 00:01:25.400
Uma máquina de venda automática fica lá no canto sem fazer nada,

00:01:25.460 --> 00:01:27.020
até alguém apertar um botão.

00:01:27.600 --> 00:01:29.580
Então ela ganha vida, faz seu trabalho e volta a dormir.

00:01:30.080 --> 00:01:32.080
Você só paga pela eletricidade quando ela está realmente funcionando.

00:01:32.480 --> 00:01:33.620
Isso é serverless em poucas palavras.

00:01:34.040 --> 00:01:35.640
Azure Functions é a versão da Microsoft para isso.

00:01:36.040 --> 00:01:38.240
Ela executa pequenos pedaços de código em resposta a eventos.

00:01:38.880 --> 00:01:40.900
Seu código fica dormente até que algo desperte,

00:01:40.980 --> 00:01:42.720
então ele roda, termina e volta a dormir.

00:01:43.260 --> 00:01:44.620
Então como esse código realmente se parece?

00:01:45.400 --> 00:01:46.280
O que são as Azure Functions?

00:01:46.280 --> 00:01:49.660
Uma função é um único pedaço de código que faz uma tarefa específica.

00:01:50.580 --> 00:01:53.580
Não é uma aplicação inteira com páginas de login, banco de dados e 20 telas.

00:01:54.440 --> 00:01:55.660
É uma tarefa focada.

00:01:56.240 --> 00:01:58.000
Pense nisso como interruptor de luz da sua casa,

00:01:58.060 --> 00:02:00.600
ou está desligado, ou ligado trabalhando, e depois desliga de novo.

00:02:01.700 --> 00:02:03.400
Um servidor web tradicional é o oposto,

00:02:03.480 --> 00:02:05.900
como deixar todas as luzes da casa acesas 24 horas por dia,

00:02:06.260 --> 00:02:07.920
7 dias por semana, mesmo sem ninguém em casa.

00:02:08.500 --> 00:02:11.280
O Azure Functions oferece suporte a várias linguagens de programação diferentes.

00:02:11.280 --> 00:02:15.880
Você pode usar o que preferir, JavaScript, Python, Cshava, Java, PowerShell, PowerShell.

00:02:15.880 --> 00:02:16.960
Mas existe uma resposta certa.

00:02:17.360 --> 00:02:18.440
Escolha a linguagem que você já conhece.

00:02:18.880 --> 00:02:20.480
Agora, vamos esclarecer uma confusão comum.

00:02:20.940 --> 00:02:22.680
O Function App não é a mesma coisa que uma função.

00:02:23.240 --> 00:02:24.480
O Function App é o container.

00:02:25.080 --> 00:02:26.080
Pense nisso como a caixa de ferramenta.

00:02:26.440 --> 00:02:29.760
Você cria um Function App, e dentro dessa caixa adiciona várias funções.

00:02:30.220 --> 00:02:32.440
Cada função é uma ferramenta separada que realiza sua própria tarefa.

00:02:32.720 --> 00:02:35.080
Você pode ter uma função que lida com registros de usuários,

00:02:35.220 --> 00:02:36.600
outra que processe imagens enviadas,

00:02:36.900 --> 00:02:38.440
e uma terceira que envia relatórios noturnos.

00:02:38.680 --> 00:02:41.280
Todas vivem na mesma caixa de ferramenta, mas funcionam de forma independente.

00:02:41.980 --> 00:02:42.960
Mais uma coisa sobre funções.

00:02:43.080 --> 00:02:44.460
Elas são stateless, sem estado por design.

00:02:44.460 --> 00:02:46.460
Isso significa que elas não lembram de nada entre as execuções.

00:02:46.720 --> 00:02:49.340
Se sua função processa um arquivo e termina, é isso.

00:02:49.880 --> 00:02:52.140
A próxima vez que rodar, ela começa do zero, sem memória da vez anterior.

00:02:52.600 --> 00:02:55.600
Isso parece uma limitação, mas na verdade é o recurso que as torna tão poderosa.

00:02:56.180 --> 00:02:58.000
Como as funções não retém memória ou estado,

00:02:58.380 --> 00:03:01.620
o Azure pode subir 100 cópias da sua função instantaneamente quando o tráfego aumenta,

00:03:01.940 --> 00:03:03.700
e desligá-las tão rápido quanto quando o tráfego cai.

00:03:04.060 --> 00:03:06.820
É assim que você obtém escalabilidade sem pagar por servidores ociosos.

00:03:07.100 --> 00:03:07.900
Aqui está a pergunta.

00:03:08.000 --> 00:03:10.780
Se uma função fica lá parada sem fazer nada até que algo a desperte,

00:03:10.860 --> 00:03:11.960
o que realmente a desperta?

00:03:12.460 --> 00:03:13.260
É aí que entra os gatilhos.

00:03:13.260 --> 00:03:14.660
Gatilhos são o quando.

00:03:15.440 --> 00:03:17.940
Toda função deve ter exatamente um gatilho, e isso não é opcional.

00:03:18.420 --> 00:03:20.260
O gatilho é o evento que desperta a sua função.

00:03:20.840 --> 00:03:23.420
Sem ele, seu código fica parado lá sem fazer absolutamente nada.

00:03:23.900 --> 00:03:25.080
Pense nos gatilhos com uma campainha.

00:03:25.440 --> 00:03:26.800
Sua função está dentro de casa esperando.

00:03:27.280 --> 00:03:28.140
Ela poderia esperar para sempre.

00:03:28.560 --> 00:03:30.200
Nada acontece até que alguém toque a campainha.

00:03:31.020 --> 00:03:34.340
Então a função entra em ação, atende a porta, faz seu trabalho e volta a esperar.

00:03:34.340 --> 00:03:37.520
Existem quatro gatilhos que os iniciantes encontram com mais frequência.

00:03:37.960 --> 00:03:40.100
O gatilho HTTP é o ponto de partida mais comum.

00:03:40.900 --> 00:03:43.900
Alguém acessa uma URL ou faz uma chamada de API, e sua função é disparada.

00:03:44.380 --> 00:03:47.500
É assim que você constrói APIs leves, sem precisar configurar um servidor web completo.

00:03:48.180 --> 00:03:50.520
Depois há o gatilho de temporizador timer que roda em uma dinâmica.

00:03:50.860 --> 00:03:54.880
Você define uma expressão Chrome, como executar a cada hora ou à meia-noite e todas as noites,

00:03:55.380 --> 00:03:57.420
e sua função é disparada exatamente nesses momentos.

00:03:57.420 --> 00:04:01.800
Perfeito para tarefas de manutenção, trabalhos de limpeza e geração de relatórios noturnos.

00:04:02.300 --> 00:04:05.120
O gatilho de blob é disparado quando um arquivo é carregado no armazenamento do azul.

00:04:05.560 --> 00:04:07.520
Digamos que alguém envia um PDF com uma pasta específica.

00:04:08.080 --> 00:04:10.980
O gatilho de blob detecta esse envio e executa sua função automaticamente.

00:04:11.400 --> 00:04:14.820
Isso é excelente para processamento de imagens, conversão de documentos e validação de arquivo.

00:04:15.220 --> 00:04:17.700
O gatilho de fila é disparado quando uma mensagem aparece em uma fila.

00:04:18.260 --> 00:04:20.380
Filas são uma forma de desacoplar diferentes partes do seu sistema.

00:04:20.880 --> 00:04:25.100
Um serviço coloca uma mensagem em uma fila, e sua função a captura e processa quando estiver pronta.

00:04:25.100 --> 00:04:27.960
Isso evita que um serviço lento bloqueie todo o restante.

00:04:28.700 --> 00:04:29.420
Aqui está o ponto principal.

00:04:30.080 --> 00:04:33.140
Quando um gatilho é disparado, ele passa dados para a sua função automaticamente.

00:04:33.920 --> 00:04:35.880
Você não precisa fazer consultas nem verificar se algo aconteceu.

00:04:36.400 --> 00:04:39.260
O gatilho entrega tudo o que você precisa, e sua função apenas processa.

00:04:39.680 --> 00:04:42.280
Uma função sem gatilho é apenas um código parado sem fazer nada.

00:04:42.840 --> 00:04:44.080
O gatilho é o que lhe dá um propósito.

00:04:44.520 --> 00:04:46.280
Portanto, o gatilho diz a sua função quando executar.

00:04:46.840 --> 00:04:48.540
Mas de onde vêm os dados e para onde eles vão?

00:04:49.000 --> 00:04:49.920
É aí que entram as vinculações.

00:04:51.180 --> 00:04:52.680
Vinculações dados de entrada e dados de saída.

00:04:52.680 --> 00:04:56.080
As vinculações são uma maneira de dizer à sua função quais dados ler

00:04:56.080 --> 00:04:58.380
e para onde enviar resultados sem escrever código extra.

00:04:59.060 --> 00:05:00.520
Isso parece complicado, então deixe-me simplificar.

00:05:00.960 --> 00:05:01.420
Dois tipos.

00:05:01.800 --> 00:05:03.560
As vinculações de entrada trazem dados para a sua função.

00:05:03.960 --> 00:05:05.800
As vinculações de saída enviam dados para fora.

00:05:06.360 --> 00:05:08.360
Sem vinculações, você teria que escrever código de SDK

00:05:08.360 --> 00:05:11.400
toda vez que quisesse falar com uma conta de armazenamento, banco de dados ou fila.

00:05:12.040 --> 00:05:13.880
Teria que gerenciar strings de conexão,

00:05:14.300 --> 00:05:16.860
tentativas de serializar dados e de serializar respostas.

00:05:17.240 --> 00:05:18.900
Isso é muito código repetitivo apenas para ler um arquivo.

00:05:19.260 --> 00:05:21.060
Com vinculações, você apenas declara o que precisa.

00:05:21.060 --> 00:05:23.080
Se diz que quer ler deste container de blob

00:05:23.080 --> 00:05:25.120
ou quer escrever nesta fila,

00:05:25.640 --> 00:05:26.780
o ambiente de execução cuida do resto.

00:05:27.080 --> 00:05:30.600
Ele abre a conexão, lê os dados e os passa para a sua função como um parâmetro.

00:05:31.380 --> 00:05:34.980
Quando sua função termina, ele pega o valor de retorno e o escreve onde você especificou.

00:05:35.680 --> 00:05:37.040
Pense nas vinculações com tubulações.

00:05:37.540 --> 00:05:40.540
Você conecta sua função a conta de armazenamento, banco de dados ou fila.

00:05:40.760 --> 00:05:42.540
Os dados fluem por essas tubulações automaticamente.

00:05:43.400 --> 00:05:45.240
Sua função não precisa saber como as tubulações funcionam.

00:05:45.660 --> 00:05:47.780
Ela apenas recebe o que vem e envia o que precisa sair.

00:05:48.400 --> 00:05:49.340
Aqui está um exemplo concreto.

00:05:49.340 --> 00:05:51.000
Digamos que você tenha uma vinculação de entrada.

00:05:51.320 --> 00:05:54.600
Quando sua função inicia, ela lê automaticamente um arquivo de armazenamento de blobs

00:05:54.600 --> 00:05:55.880
e o entrega a você como um parâmetro.

00:05:56.120 --> 00:05:57.640
Você não escreve nenhum código de SDK de armazenamento.

00:05:58.060 --> 00:05:59.320
Você apenas recebe os dados desse processo.

00:05:59.800 --> 00:06:01.140
Outro exemplo, um binding de saída de fila.

00:06:01.660 --> 00:06:04.380
Sua função processa algo e, ao final, você retorna um valor.

00:06:04.980 --> 00:06:08.120
O runtime pega esse valor, serializa-o e o coloca na fila.

00:06:08.640 --> 00:06:09.780
Você não escreve nenhum código de fila.

00:06:09.960 --> 00:06:10.740
Você apenas retorna um valor.

00:06:11.160 --> 00:06:11.880
Binds são opcionais.

00:06:12.320 --> 00:06:13.720
Você pode ter zero, um ou muitos.

00:06:13.720 --> 00:06:16.800
Algumas funções precisam apenas de um gatilho sem nenhum binding.

00:06:17.540 --> 00:06:20.140
Outras podem ter três ou quatro bindings conectando a diferentes serviços.

00:06:20.840 --> 00:06:23.700
A combinação de gatilhos e bindings é o que torna os refunctions tão poderoso.

00:06:24.300 --> 00:06:26.880
Você escreve a lógica de negócio, o código de tomada de decisão real.

00:06:27.560 --> 00:06:29.040
A plataforma cuida de toda a integração.

00:06:29.580 --> 00:06:32.160
Sua função permanece pequena, focada e fácil de entender.

00:06:33.940 --> 00:06:34.760
A história dos preços.

00:06:35.180 --> 00:06:36.700
O preço é o que mais surpreende os iniciantes.

00:06:37.380 --> 00:06:39.520
Para a maioria das pessoas, o plano de consumo é a escolha padrão.

00:06:39.660 --> 00:06:41.660
E você deve começar com ele 90% das vezes.

00:06:41.660 --> 00:06:42.840
Veja como funciona.

00:06:43.340 --> 00:06:45.180
Você paga apenas quando sua função realmente é executada.

00:06:45.680 --> 00:06:47.020
Quando ela está ociosa, você não paga nada.

00:06:47.340 --> 00:06:48.260
Zero, nem um centavo.

00:06:49.100 --> 00:06:50.320
Dois componentes compõem a fatura.

00:06:50.860 --> 00:06:51.920
Primeiro, o número de execuções.

00:06:52.020 --> 00:06:53.400
Quantas vezes sua função é disparada?

00:06:54.300 --> 00:06:57.420
Segundo, o tempo de execução medida em algo chamado GB segundos.

00:06:58.000 --> 00:07:01.180
Isso é basicamente quanto tempo sua função rodou multiplicada por quanto a memória ela usou.

00:07:01.520 --> 00:07:02.520
A cota gratuita é generosa.

00:07:02.920 --> 00:07:06.840
Você recebe um milhão de execuções por mês e 400 mil gigas segundos totalmente gratuitos.

00:07:07.300 --> 00:07:11.220
Para a maioria dos pequenos projetos, aplicativos de hobby e protótipos, você nunca pagará um centavo.

00:07:11.660 --> 00:07:11.900
Nunca.

00:07:12.640 --> 00:07:15.140
Se você exceder a cota gratuita, as taxas ainda são incrivelmente baratas.

00:07:15.380 --> 00:07:16.640
20 centavos por um milhão de execuções.

00:07:16.900 --> 00:07:17.740
Isso não é uma erva de digitação.

00:07:17.940 --> 00:07:19.260
20 centavos por um milhão de execuções.

00:07:19.540 --> 00:07:22.260
Pense nisso com pagar pela eletricidade apenas quando você liga o interruptor.

00:07:22.840 --> 00:07:25.020
Não há taxa base mensal por ter afiação nas paredes.

00:07:25.700 --> 00:07:27.260
Você só paga pela energia que realmente usa.

00:07:27.800 --> 00:07:28.680
Agora existem outros planos.

00:07:29.340 --> 00:07:31.520
Flex Consumption é mais novo e oferece suporte à rede virtual.

00:07:31.880 --> 00:07:34.720
Premium mantém suas funções sempre ativas para que não haja atraso de custo.

00:07:34.720 --> 00:07:38.300
O Dedicated oferece capacidade fixa em um app service plan tradicional.

00:07:38.980 --> 00:07:41.380
Mas para começar, o plano Consumption é a escolha certa quase sempre.

00:07:41.840 --> 00:07:45.920
No entanto, a cota gratuita é compartilhada entre todos os seus Function Apps na mesma assinatura.

00:07:46.400 --> 00:07:49.820
Se você tiver 10 Function Apps, todos eles consomem o mesmo milhão de execuções gratuitas.

00:07:50.320 --> 00:07:52.480
Portanto, fique de olho nisso se você começar a criar mais do que alguns.

00:07:53.080 --> 00:07:53.800
Preço é ótimo.

00:07:54.240 --> 00:07:56.060
Mas vamos tornar isso real com um exemplo concreto.

00:07:56.720 --> 00:07:57.780
Um cenário do mundo real.

00:07:58.220 --> 00:08:00.920
Imagine que você gerencia um site onde usuários fazem upload de fotos de perfil.

00:08:00.920 --> 00:08:03.360
Essas imagens são enormes, tipo 10 megabytes cada.

00:08:04.060 --> 00:08:05.340
Isso causa alguns problemas reais.

00:08:05.900 --> 00:08:09.920
Arquivos grandes custam mais para armazenar, deixam seu site lento sempre que alguém carrega uma página

00:08:09.920 --> 00:08:12.160
e frustram seus usuários que precisam esperar pelas fotos.

00:08:12.880 --> 00:08:15.700
Então você precisa de uma maneira de reduzir essas imagens automaticamente.

00:08:16.280 --> 00:08:19.300
Sem o Azure Functions, você teria que criar um worker de segundo plano do zero.

00:08:19.900 --> 00:08:23.600
Isso significa obter um servidor separado, configurar uma fila para gerenciar carga de trabalho

00:08:23.600 --> 00:08:25.600
e escrever código para lidar com todas as partes móveis.

00:08:26.000 --> 00:08:29.040
Isso é um monte de complexidade desnecessária para algo tão simples quanto reduzir uma imagem.

00:08:29.040 --> 00:08:33.000
Com o Azure Functions, tudo o que você precisa é um gatilho de blob e uma função.

00:08:33.760 --> 00:08:35.000
Sem servidores para se preocupar.

00:08:35.320 --> 00:08:36.440
Deixe-me explicar como funciona.

00:08:37.000 --> 00:08:40.760
Um usuário faz o upload de uma foto pelo seu site e esse arquivo vai para o armazenamento de blob do azul.

00:08:41.180 --> 00:08:43.300
No momento em que chega, um gatilho de blob dispara automaticamente.

00:08:43.780 --> 00:08:47.940
Sua função desperta, executa o código de compressão e salva a versão menor de volta no armazenamento.

00:08:48.580 --> 00:08:49.680
Tudo isso acontece em segundos.

00:08:50.260 --> 00:08:54.100
O usuário nunca espera porque todo o processo ocorre nos bastidores de forma totalmente invisível.

00:08:54.960 --> 00:08:56.080
Que tal outro exemplo cotidiano?

00:08:56.220 --> 00:08:58.700
Enviar um e-mail de boas-vindas quando alguém se inscreve no seu serviço.

00:08:59.040 --> 00:09:01.880
Um gatilho HTTP captura a solicitação de inscrição do seu site.

00:09:02.380 --> 00:09:06.760
Sua função dispara, pega o endereço de e-mail do usuário, envia uma mensagem de boas-vindas pelo SendGrid e pronto.

00:09:07.260 --> 00:09:08.780
O usuário recebe o e-mail quase instantaneamente.

00:09:09.280 --> 00:09:11.800
Sem servidor de e-mail para configurar, sem fila de envio para gerenciar.

00:09:11.980 --> 00:09:13.820
Apenas uma função, um trabalho, concluído.

00:09:14.120 --> 00:09:16.780
Esses são exatamente os trabalhos pelos quais o Azure Functions foi projetado.

00:09:16.960 --> 00:09:18.680
Tarefas pequenas, focadas e orientadas à venda.

00:09:19.020 --> 00:09:24.220
Não aplicativos massivos, não fluxos de trabalho complexos, apenas uma coisa feita bem e acionada por algo acontecendo em outro lugar.

00:09:24.940 --> 00:09:26.160
Quando usar o Azure Functions?

00:09:26.160 --> 00:09:29.580
Então, quando você deve recorrer a uma função e quando deve usar a outra coisa?

00:09:30.260 --> 00:09:31.240
De tal maneira rápida, decide.

00:09:31.740 --> 00:09:35.360
Pergunte a si mesmo se a tarefa é curta, se é orientada a eventos e se é sem estado.

00:09:36.240 --> 00:09:39.500
Se você respondeu sim para as três, o Azure Functions é provavelmente a ferramenta certa.

00:09:40.240 --> 00:09:41.380
Vamos começar com os bons casos, Ju.

00:09:41.920 --> 00:09:43.580
APIs e Webhooks são uma combinação perfeita.

00:09:44.260 --> 00:09:49.180
Você precisa de um endpoint leve que responda a uma solicitação HTTP, faça uma coisa e retorne um resultado.

00:09:49.340 --> 00:09:51.420
E é exatamente para isso que os gatilhos HTTP são feitos.

00:09:51.420 --> 00:09:54.020
Processamento de arquivos e imagens é outro grande exemplo.

00:09:54.640 --> 00:09:59.040
Um arquivo chega ao armazenamento, sua função dispara, transforma e salva o resultado, tudo sem um servidor.

00:09:59.880 --> 00:10:04.040
Tarefas agendadas, como limpeza noturna ou geração de relatórios, funcionam muito bem com gatilhos de tempo.

00:10:05.220 --> 00:10:07.360
Transformação de dados para pipeline GTL também é comum.

00:10:08.140 --> 00:10:12.720
E as funções são a cola de integração perfeita, conectando dois serviços que não se comunicam naturalmente.

00:10:13.380 --> 00:10:15.280
Agora, vamos falar sobre quando as funções não são adequadas.

00:10:15.280 --> 00:10:22.900
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.

00:10:23.020 --> 00:10:24.020
Chegando a 10 se configurar.

00:10:24.140 --> 00:10:26.260
Se o seu trabalho leva mais tempo que isso, você precisa de outra solução.

00:10:26.720 --> 00:10:28.480
Aplicações com estado e stateful são outra compatibilidade.

00:10:29.040 --> 00:10:30.740
Funções não lembram de nada entre as execuções.

00:10:31.440 --> 00:10:35.300
Se você precisa manter o estado da sessão ou acompanhar o progresso entre etapas, você está indo contra o design.

00:10:35.800 --> 00:10:37.660
Cargas de trabalho de computação pesada também não são indicados.

00:10:37.660 --> 00:10:42.280
Se você precisa de CPU sustentada por minutos ou horas, uma máquina virtual ou container é uma escolha melhor.

00:10:42.280 --> 00:10:47.860
E fluxos de trabalho complexo, onde uma tarefa depende de outra, são melhor tratados por Durable Functions ou Logic Apps.

00:10:48.360 --> 00:10:50.060
Aqui está uma visão geral rápida da sua treinante.

00:10:50.540 --> 00:10:53.200
O Azure Logic Apps é a opção sem código para conectar serviços.

00:10:53.640 --> 00:10:57.040
Se você não precisa escrever código personalizado, o Logic Apps pode fazer o trabalho com design visual.

00:10:57.680 --> 00:11:00.740
O Azure App Service é para aplicações web completas que rodam 24x7.

00:11:01.460 --> 00:11:04.380
Se você precisa de um site completo ou uma API que esteja sempre ativa, essa é a sua ferramenta.

00:11:04.980 --> 00:11:08.700
O Azure Container Apps oferece micro-serviços em containers com mais controle sobre o tempo de execução.

00:11:08.700 --> 00:11:12.580
E as máquinas virtuais do Azure oferecem controle total sobre o sistema operacional se você precisar.

00:11:12.980 --> 00:11:14.140
E aqui está uma regra prática sim.

00:11:14.540 --> 00:11:18.520
Se você consegue descrever o trabalho em uma frase, provavelmente é um bom candidato para uma função.

00:11:19.520 --> 00:11:20.940
Compactar imagens quando são carregadas.

00:11:21.480 --> 00:11:23.300
Enviar um e-mail de boas-vindas quando alguém se cadastra.

00:11:24.020 --> 00:11:25.620
Executar um trabalho de limpeza toda noite mesmo.

00:11:26.360 --> 00:11:27.800
Uma frase, um trabalho, uma função.

00:11:28.920 --> 00:11:30.200
Erros comuns de iniciantes para evitar.

00:11:30.840 --> 00:11:32.500
Agora, vamos falar sobre algumas coisas para ficar atento.

00:11:33.100 --> 00:11:35.480
Esses são os erros que fazem quase todo mundo tropeçar ao começar.

00:11:35.480 --> 00:11:38.800
Um erro comum de iniciante é pensar que as funções são sempre gratuitas.

00:11:39.300 --> 00:11:40.600
A concessão gratuita é generosa.

00:11:40.700 --> 00:11:42.220
Eu sei que um milhão de execuções parece muito.

00:11:42.860 --> 00:11:47.300
Mas se sua função viralizar ou for bombardeada por um bot, essas execuções somam rapidamente.

00:11:47.900 --> 00:11:52.340
Portanto, monitore seu uso, configure um alerta de orçamento no Azure e não tenha uma conta surpresa no final do mês.

00:11:52.760 --> 00:11:54.560
Outro erro é ignorar as inicializações a frígocos.

00:11:54.980 --> 00:11:57.800
A primeira vez que sua função é executada após ficar ociosa, ela demora mais.

00:11:58.240 --> 00:11:59.960
No plano de consumo, isso pode levar alguns segundos.

00:12:00.360 --> 00:12:01.560
Para a maioria dos casos de uso, se aceita.

00:12:01.560 --> 00:12:05.380
Mas, se você está criando uma API sensível à latência onde cada milissegundo importa,

00:12:05.500 --> 00:12:08.120
considere o plano premium ou habilite instâncias sempre prontas.

00:12:09.060 --> 00:12:11.020
Então, há o erro de escrever funções que rodam por demais.

00:12:11.740 --> 00:12:14.940
O plano de consumo tem um tempo limite de 5 minutos por padrão, 10 minutos no máximo.

00:12:15.800 --> 00:12:19.860
Se sua função leva 15 minutos para processar um arquivo, ela será encerrada no meio do processo.

00:12:20.540 --> 00:12:23.060
Divida esse trabalho em partes menores ou use um plano de hospedagem diferente.

00:12:23.620 --> 00:12:26.620
Outro erro fácil de ignorar é não usar a implantação RunFromPackage.

00:12:26.620 --> 00:12:31.060
É uma mudança simples de configuração que melhora a code start e se torna as implantações mais confiáveis.

00:12:31.800 --> 00:12:34.840
Em vez de copiar arquivos individuais, você implanta um pacote zip.

00:12:35.340 --> 00:12:37.040
É apenas uma caixa de seleção do portal faça aí.

00:12:37.500 --> 00:12:40.320
Expor endpoints HTTP sem autenticação é outra amadilha.

00:12:40.880 --> 00:12:44.560
É fácil deixar uma função como anônima durante os testes e depois esquecer de protegê-la.

00:12:45.100 --> 00:12:47.000
Defina seu nível de autorização corretamente desde o início.

00:12:47.360 --> 00:12:48.520
Use chave de função ou de administrador.

00:12:48.880 --> 00:12:49.620
Deixa a porta aberta.

00:12:50.020 --> 00:12:52.840
Eu utilizar contas de armazenamento em vários aplicativos de função também é um problema.

00:12:53.100 --> 00:12:54.560
No desenvolvimento, não há problema em compartilhar.

00:12:54.560 --> 00:12:57.460
Em produção, cada aplicativo de função deve ter sua própria contramenta.

00:12:58.040 --> 00:13:01.640
Caso contrário, você terá problemas de vizinho barulhento onde o tráfego de uma função atrasa a outra.

00:13:02.220 --> 00:13:04.080
E finalmente, não habilitar o Application Insights.

00:13:04.580 --> 00:13:05.620
Sem ele, você está voando a sério.

00:13:06.000 --> 00:13:08.220
Você não verá falhas, erros ou problemas de desempenho.

00:13:08.620 --> 00:13:11.460
Você não saberá se sua função está rodando por muito tempo ou falhando silenciosamente.

00:13:11.820 --> 00:13:12.640
Habilite o primeiro dia.

00:13:13.100 --> 00:13:15.080
Leva 30 segundos e economiza horas de depuração.

00:13:15.720 --> 00:13:19.180
A regra de ouro para tudo isso é manter suas funções pequenas, focadas e sem estado.

00:13:19.900 --> 00:13:21.440
Uma tarefa por função, nada mais?

00:13:21.980 --> 00:13:22.700
Então esse é o sistema.

00:13:22.700 --> 00:13:26.980
Wide Your Functions é uma computação sem servidor que executa pequenos trechos de código em resposta a eventos.

00:13:27.360 --> 00:13:28.780
Você só paga quando seu código executa.

00:13:29.160 --> 00:13:31.100
Gatilhos dizem a sua função quando despertar.

00:13:31.260 --> 00:13:35.660
Bindings a conectam aos dados necessários e o plano de consumo a mantém quase gratuita para pequenos projetos.

00:13:36.160 --> 00:13:40.200
Sua melhor estratégia agora é criar uma função simples com gatilho HTTP no portal do Azure.

00:13:41.020 --> 00:13:42.320
Leva 5 minutos e não custa nada.

00:13:42.320 --> 00:13:46.640
Inscreva-se no Microsoft Knowledge Nuggets para mais explicações simples e compartilhe isso

00:13:46.640 --> 00:13:48.520
com alguém que vive perguntando o que significa serverless.

00:13:49.260 --> 00:13:49.460
Peral.

00:13:49.460 --> 00:13:49.520
Peral.