Computação sem servidor
Nos primórdios da computação na cloud, os fornecedores de serviços cloud, como a Amazon e a Microsoft, concentravam-se em oferecer uma grande variedade de serviços IaaS aos seus clientes. Isto impulsionava o crescimento de clouds públicas, ao permitir aos clientes mudar facilmente as cargas de trabalho executadas no local em servidores físicos ou em máquinas virtuais para máquinas virtuais na cloud. No entanto, com o IaaS veio a responsabilidade. Uma organização que cria uma VM na cloud também assume a responsabilidade de manter o que está dentro da VM: o sistema operativo, os runtimes necessários, as aplicações que utilizam esses runtimes, etc.
O PaaS muda parte dessa responsabilidade para o fornecedor de serviços cloud e impulsiona ainda mais investimentos na cloud. Com serviços como o AWS Elastic Beanstalk e o Serviço de Aplicações do Azure, os clientes podem aprovisionar servidores Web virtuais com runtimes populares, como Java, Node.js e Microsoft .NET, e fazer com que o software seja executado em minutos. Embora as máquinas virtuais façam o trabalho pesado em segundo plano, a sua presença é amplamente abstrata. O PaaS permite aos clientes concentrarem-se nas aplicações que escrevem para resolver problemas empresariais, em vez de gastar ciclos a gerir VMs e a manter as plataformas corrigidas e atualizadas.
A computação sem servidor é uma inovação relativamente recente na computação na cloud que utiliza ainda mais essas abstrações. Imagine que a sua organização escreve e mantém código que executa cópias de segurança noturnas de dados fundamentais e execuções de faturação semanais ou transmite um pagamento eletrónico sempre que é carregada uma fatura para o armazenamento na cloud. Neste caso, o objetivo geral é executar o código no momento apropriado. Tudo o resto é secundário, incluindo onde o código está armazenado e como e onde é executado.
Pode adotar uma abordagem IaaS ao criar uma ou mais VMs para executar o seu código e instalar as plataformas e bibliotecas necessárias. Pode aprovisionar uma instância do Elastic Beanstalk ou do Serviço de Aplicações e alojar o código aí. Também pode utilizar um runtime de função, como o AWS Lambda ou as Funções do Azure, para executar o seu código sempre que quiser, sem considerar onde ou como está alojado. O AWS Lambda e as Funções do Azure são exemplos de computação sem servidor (especificamente, de funções sem servidor), tal como o Google Cloud Functions. Os três representam o próximo passo na evolução natural da computação na cloud desde o IaaS, em que o utilizador tem a responsabilidade de tudo, à abordagem sem servidor, em que se concentra nas ações que pretende executar (o código que pretende executar) na cloud e permite ao fornecedor de serviços cloud gerir tudo o resto.
As funções sem servidor executadas pelos runtimes de função na cloud são a forma mais comum de computação sem servidor, mas não são a única. A Amazon, a Microsoft e a Google oferecem versões sem servidor de alguns dos respetivos serviços PaaS, incluindo bases de dados sem servidor. Alguns fornecedores suportam fluxos de trabalho sem servidor, que lhe permitem definir fluxos de trabalho empresariais na cloud e executá-los em resposta a eventos externos, como faturas carregadas para o armazenamento na cloud, temporizadores acionados em intervalos especificados ou e-mails recebidos numa caixa de entrada, muitas vezes sem escrever uma única linha de código. Por fim, muitos dos serviços de contentor oferecidos pelos fornecedores de serviços cloud, incluindo o Azure Container Instances e o AWS Elastic Container Service, são elegíveis como exemplos de computação sem servidor, pois permitem executar contentores na cloud durante a abstração da infraestrutura subjacente.
Benefícios da computação sem servidor
A computação sem servidor oferece três benefícios principais às organizações que tiram partido da computação na cloud:
Custos de computação mais baixos: os clientes normalmente pagam taxas mensais por máquinas virtuais IaaS e serviços PaaS, como o Elastic Beanstalk e o Serviço de Aplicativo do Azure. A faturação continua mesmo que os serviços estejam inativos. No entanto, a maioria dos serviços de computação sem servidor suporta preços de consumo, em que é cobrado apenas pelo tempo de execução do código. Imagine que dedica uma VM de 100 dólares por mês a executar código que realiza uma cópia de segurança noturna de dados fundamentais e que o código é executado durante 30 minutos por noite. Está a pagar 100 dólares por mês para executar código para 1/48ª parte de um mês ou menos de um dia. Implementar o mesmo código como uma função sem servidor pode custar um pouco mais do que alguns dólares por mês. Com os preços de consumo, não paga pelo tempo de inatividade.
Escalabilidade automática: os provedores de nuvem oferecem mecanismos para dimensionar serviços IaaS em produtos como o AWS Auto Scaling e conjuntos de dimensionamento de máquinas virtuais no Azure. Também fornecem opções de dimensionamento manual e automático para serviços PaaS. Porém, mesmo que o dimensionamento seja executado automaticamente, um administrador de cloud tem de ativar o dimensionamento automático e configurá-lo para que o fornecedor de cloud saiba como e quando o dimensionamento deve ocorrer. Uma das considerações subjacentes que os administradores têm de ter em conta é que, como paga por instâncias individuais de serviços IaaS e PaaS, quer configurar o serviço para dimensionar o suficiente enquanto não estiver a dimensionar muito. A computação sem servidor oferece a opção de aumentar horizontalmente de forma transparente e automática para satisfazer o aumento da procura e reduzir horizontalmente quando a procura diminuir. Um administrador de cloud normalmente não realiza nenhuma configuração além da ativação desta opção no serviço. Se receber cem pedidos ao mesmo tempo para executar uma função sem servidor, o fornecedor de serviços cloud garantirá que os pedidos podem ser executados em paralelo (ou na maioria em paralelo). O custo não é afetado porque, com preços de consumo, executar uma função cem vezes tem o mesmo preço, independentemente de a execução ser em série ou em paralelo.
Custos administrativos reduzidos: o Serverless permite que você se concentre na execução de código e fluxos de trabalho enquanto transfere a responsabilidade por todo o resto, incluindo a manutenção da plataforma subjacente, para o provedor de serviços de nuvem.
A computação sem servidor também tem desvantagens. Algumas das limitações a considerar incluem:
Alguns runtimes de função impõem um limite na quantidade de tempo que uma função tem permissão para ser executada.
Alguns runtimes de função não garantem que uma função seja executada imediatamente, a menos que esteja disposto a pagar mais para que isso aconteça. Com as Funções do Azure configuradas para utilizar preços baseados no consumo, por exemplo, uma função pode não ser executada durante um máximo de 10 minutos depois de ser acionada. Isso pode não ser um problema para um backup noturno; Você provavelmente não se importa se o backup é executado à 1h00 ou 1h10. Mas pode ser um divisor de águas para funções que são críticas em termos de tempo - funções que devem ser executadas em tempo real (ou quase em tempo real).
Geralmente, as funções sem servidor não têm estado, ou seja, não podem armazenar dados internamente e esperar que persistam entre uma invocação de função e a seguinte. Podem utilizar serviços de armazenamento na cloud externos, como o Amazon S3 e o Armazenamento do Azure, para manter dados entre chamadas, mas isto torna o código da função mais complexo.
Alguns fornecedores de serviços cloud suportam funções com estado (o Azure chama-as de "funções duráveis"), mas as funções que mantêm o estado são uma adição relativamente recente à computação sem servidor e não são suportadas universalmente.
Funções sem servidor
O exemplo mais comum de computação sem servidor são as funções sem servidor. O utilizador carrega o código para a cloud e indica quando deve ser executado. O código pode ser escrito em uma variedade de linguagens, incluindo Java e C#.
A Figura 11 lista as linguagens de programação suportadas por funções sem servidor no Azure, AWS e GCP no momento da redação deste artigo:
| Idioma | Funções do Azure | AWS Lambda | Google Cloud Functions |
|---|---|---|---|
| C# | x | x | |
| F# | x | ||
| Go | x | x | |
| Java | x | x | |
| JavaScript (Node.js) | x | x | x |
| PowerShell | x | x | |
| Python | x | x | x |
| Ruby | x | ||
| TypeScript | x |
Figura 11: Linguagens de programação suportadas por tempos de execução populares de função sem servidor.
Quando cria uma função e fornece o código que esta executará, também identifica o evento externo que faz com que a função seja executada. As plataformas de cloud populares suportam acionadores de vários tipos, incluindo temporizadores, eventos que ocorrem noutros serviços cloud (como um documento que está a ser carregado para o armazenamento na cloud) e chamadas HTTP. É uma simples questão de carregar o código de faturação para um runtime de função e configurá-lo para ser executado uma vez por dia, uma vez por semana ou uma vez por mês. É igualmente simples ativar uma função sempre que uma fatura é carregada para o armazenamento na cloud (por exemplo, o Amazon S3 ou o Armazenamento do Azure) ou quando uma chamada é colocada num ponto final REST associado à função.
As funções sem servidor são utilizadas frequentemente para realizar tarefas autónomas, como cópias de segurança noturnas e faturação. São também utilizadas para ligar outros serviços cloud e compor soluções avançadas com serviços cloud como blocos modulares. A Figura 12 introduz uma dessas soluções utilizada para combinar vários serviços do Azure para monitorizar a atividade dos ursos-polares no Ártico. Uma Função do Azure desempenha um papel fundamental na arquitetura ao retirar a saída do Azure Stream Analytics (acionada por uma chamada HTTP), ao obter uma foto do Armazenamento de Blobs do Azure e ao enviá-la a um modelo preparado com o Serviço de Visão Personalizada do Azure, que utiliza IA (inteligência artificial) para determinar se a foto contém um urso-polar. A função é a cola que liga o Stream Analytics, o Armazenamento de Blobs e o Serviço de Visão Personalizada.
Figura 12: Usando uma função do Azure para conectar outros serviços do Azure.
Fluxos de trabalho sem servidor
Alguns serviços de computação sem servidor permitem aos clientes automatizar fluxos de trabalho empresariais sem escrever código. Os Aplicativos Lógicos do Azure, por exemplo, fornecem mais de 100 conectores internos para interface com fontes de dados que vão desde bancos de dados Oracle até serviços de mídia social, como o X. Eles fornecem gatilhos para definir quando os fluxos de trabalho devem ser executados -- por exemplo, quando um arquivo é carregado para Box.com ou algo é tuitado com uma hashtag especificada. Fornecem também centenas de ações predefinidas que definem o que acontece quando um acionador é ativado e isso pode ser encadeado para formar fluxos de trabalho complexos e condições que permitem que as ações sejam executadas condicionalmente. São infinitamente extensíveis porque uma das ações que o Azure Logic Apps suporta chama uma Função do Azure. Se um fluxo de trabalho envolver lógica personalizada que não está encapsulada numa ação, poderá fornecer o código que implementa essa lógica e incluí-lo no fluxo de trabalho como se fosse uma ação predefinida.
A Figura 13 mostra um fluxo de trabalho no designer do Azure Logic Apps1. Quando é recebido um e-mail, a Aplicação Lógica entra em ação e verifica a existência de uma expressão-chave no assunto do e-mail e a presença de um anexo. Se ambas as condições forem cumpridas, a Aplicação Lógica invoca uma Função do Azure para retirar qualquer HTML do corpo do e-mail. Em seguida, deposita o e-mail limpo e todos os anexos que o acompanham no Armazenamento de Blobs do Azure e envia um e-mail com ligações para os documentos relevantes no Armazenamento de Blobs a notificar as partes interessadas de que as informações estão disponíveis e a aguardar revisão. Este exemplo combina dois paradigmas sem servidor — um Aplicativo Lógico que executa ações sem qualquer código (pelo menos não o código que você ou qualquer pessoa em sua organização escreveu) e uma Função do Azure contendo código que você forneceu para personalizar o fluxo de trabalho — e é representativo da mudança que está ocorrendo na computação em nuvem de máquinas virtuais "faça você mesmo" para abstrações de nível mais alto que permitem que as organizações concentrem suas energias na solução de problemas de negócios em vez de gerenciar virtualmente máquinas e instalação e manutenção de tempos de execução.
Figura 13: Definindo um fluxo de trabalho nos Aplicativos Lógicos do Azure.
A Amazon oferece um serviço semelhante, o AWS Step Functions. Com o Step Functions, pode compor fluxos de trabalho visuais que combinam outros serviços, como o AWS Lambda e o AWS ECS. Os fluxos de trabalho incluem uma série de passos, com a saída de um passo a servir de entrada para o seguinte. Como o Azure Logic Apps, o AWS Step Functions fornece primitivos para ramificação e execução paralela, o que evita que tenha de escrever código para fazer o mesmo. Na verdade, um fluxo de trabalho empresarial torna-se um diagrama de máquinas de estado fácil de compreender, de explicar a outras pessoas e de modificar.
Bases de dados sem servidor
Nos primórdios da computação na cloud, alojar uma base de dados na cloud significava aprovisionar uma máquina virtual e instalar um produto de base de dados, como o MySQL, PostgreSQL ou SQL Server. O PaaS alterou tudo isto ao oferecer bases de dados como serviço. Por exemplo, com a Base de Dados SQL do Azure ou o Amazon Relational Database Service (RDS), basta aprovisionar uma instância e, em minutos, terá uma base de dados alojada na cloud pronta para servir os clientes. Além disso, o fornecedor de serviços cloud mantém a plataforma de base de dados atualizada ao aplicar atualizações de software e correções.
Uma inovação mais recente da computação na cloud é uma base de dados sem servidor, que oferece um modelo de preços/desempenho otimizado ideal para bases de dados individuais com padrões de utilização irregulares. O Azure, por exemplo, oferece uma versão sem servidor da Base de Dados SQL do Azure. Com a versão principal da Base de Dados SQL do Azure, pode escolher um escalão de preços/desempenho com base na carga máxima que espera que a base de dados processe. Se as cargas tiverem "picos" ou forem intermitentes, muitas vezes acaba por pagar como se a base de dados tivesse tido sempre cargas altas.
A versão sem servidor da Base de Dados SQL do Azure resolve isto ao dimensionar a base de dados conforme necessário para processar as cargas que encontra, sendo os custos baseados na soma dos custos de computação e de armazenamento. Tal como acontece com as funções sem servidor que utilizam um modelo de consumo, paga apenas o que utilizar. A Amazon oferece um serviço, o AWS Aurora Serverless, uma versão sem servidor do serviço de base de dados Aurora da Amazon, enquanto que a Google oferece aos seus clientes um serviço de base de dados NoSQL sem servidor conhecido como Google Cloud Firestore.
Referências
- Microsoft (2019). Automatize o tratamento de emails e anexos com os Aplicativos Lógicos do Azure. https://learn.microsoft.com/azure/logic-apps/tutorial-process-email-attachments-workflow.