Serverless é um modelo de desenvolvimento nativo em nuvem para criar e executar aplicações sem o gerenciamento de servidores.
Nesse modelo, os servidores ainda são usados, mas eles são abstraídos do desenvolvimento de aplicações. O provedor de nuvem fica responsável pelas tarefas rotineiras de provisionamento, manutenção e escala da infraestrutura do servidor. Os desenvolvedores só precisam empacotar o código em containers para fazer a implantação.
Depois da implantação, as aplicações serverless atendem à demanda e aumentam ou diminuem a escala automaticamente de acordo com as necessidades. As soluções serverless dos provedores de nuvem pública costumam ser oferecidas sob demanda por meio de um modelo de execução orientados a eventos, que é um modelo de arquitetura de software.
O que é arquitetura serverless?
A arquitetura serverless é uma abordagem de design de software que permite que os desenvolvedores criem e executem serviços sem precisar gerenciar a infraestrutura subjacente.
Os desenvolvedores podem escrever e implantar código, enquanto um provedor de nuvem provisiona servidores para executar seus aplicativos, bancos de dados e sistemas de armazenamento em qualquer escala.
Os servidores permitem que os usuários se comuniquem com um aplicativo e acessem sua lógica de negócios, mas o gerenciamento de servidores consome tempo e recursos consideráveis.
As equipes precisam manter o hardware do servidor, cuidar das atualizações de software e segurança e criar backups em caso de falha. Ao adotar a arquitetura serverless, os desenvolvedores podem transferir essas responsabilidades para um provedor terceirizado, permitindo que eles se concentrem em escrever o código do aplicativo.
Como funciona a arquitetura serverless?
Uma das arquiteturas serverless mais populares é o Function as a Service (FaaS), onde os desenvolvedores escrevem o código do aplicativo como um conjunto de funções discretas.
Cada função executa uma tarefa específica quando acionada por um evento, como um e-mail recebido ou uma solicitação HTTP. Após os estágios habituais de teste, os desenvolvedores implantam suas funções, juntamente com seus gatilhos, em uma conta de provedor de nuvem.
Quando uma função é invocada, o provedor de nuvem executa a função em um servidor em execução ou, se não houver nenhum servidor em execução no momento, ele ativa um novo servidor para executar essa função.
Esse processo de execução é abstraído da visão dos desenvolvedores, que se concentram em escrever e implantar o código do aplicativo. Embora a arquitetura serverless exista há mais de uma década, a Amazon introduziu a primeira plataforma FaaS mainstream, AWS Lambda, em 2014.
Atualmente, a maioria dos desenvolvedores ainda usa o AWS Lambda para criar aplicativos sem servidor, mas Google e Microsoft têm suas próprias ofertas de FaaS também, chamadas Google Cloud Functions (GCF) e Azure Functions, respectivamente.
A função do provedor de nuvem na computação serverless
Com o modelo serverless, o provedor de nuvem executa servidores físicos e aloca os recursos deles em nome dos usuários, que podem implantar código diretamente na produção.
As soluções serverless geralmente são divididas em duas categorias: backend as a service (BaaS) e function as a service (FaaS).
Com o BaaS, os desenvolvedores têm acesso a vários serviços e aplicações de terceiros. Por exemplo, talvez um provedor de nuvem ofereça serviços de autenticação, criptografia extra, bancos de dados acessíveis pela nuvem e dados de uso de alta fidelidade.
Normalmente, você chama as funções serverless por meio de interfaces de programação de aplicação (APIs).
Na verdade, quando os desenvolvedores se referem ao serverless, é mais provável que eles estejam falando do modelo FaaS. Com esse modelo, os desenvolvedores ainda gravam uma lógica personalizada no lado do servidor, mas ela é executada em containers totalmente gerenciados por um provedor de serviços de nuvem.
Todos os principais desenvolvedores, oferecem ao menos uma solução de FaaS. Essa solução teve como base o projeto Knative do Kubernetes.
Sobre Knative e Kubernetes Serverless
Uma solução popular na execução de ambientes serverless, é a plataforma de orquestração de containers do Kubernetes. Essa é uma maneira de executar aplicações em containers em infraestruturas automatizadas. No entanto, sozinho, o Kubernetes não é capaz de executar aplicações serverless de maneira nativa.
O Knative é um projeto da comunidade open source que fornece componentes para implantar, executar e gerenciar aplicações serverless no Kubernetes. Com o ambiente serverless do Knative, é possível implantar o código em plataformas de Kubernetes.
Para criar um serviço com o Knative, basta empacotar o código como uma imagem de container e enviá-la ao sistema. Seu código será executado apenas quando necessário, pois o Knative inicia e encerra as instâncias automaticamente.
O Knative é formado por três componentes principais:
- Build: uma abordagem flexível para compilar código-fonte em containers;
- Serving: possibilita a implantação rápida e a escala automática de containers por meio de um modelo orientado a solicitações para o fornecimento de cargas de trabalho com base na demanda;
- Eventing: uma infraestrutura de consumo e produção de eventos para acionar aplicações. Isso é feito por várias fontes, como eventos gerados por suas próprias aplicações, serviços de nuvem de vários provedores, sistemas de Software as a Service (SaaS).
O Knative foi projetado para implantar qualquer carga de trabalho de aplicação moderna, incluindo monólitos, microsserviços e funções pequenas, ao contrário dos frameworks serverless mais antigos.
Ele é uma alternativa às soluções de FaaS controladas por um único provedor de serviços e pode ser executado em qualquer plataforma de nuvem compatível com o Kubernetes. Isso inclui a execução em um datacenter on-premise. Assim, as organizações têm mais agilidade e flexibilidade para executar cargas de trabalho serverless.
Quais são as vantagens da computação serverless?
Confira abaixo algumas das principais vantagens de contar com a computação serveless no sistema da sua empresa:
Não é necessário gerenciar os servidores
Embora a computação “sem servidor” ocorra de fato nos servidores, os desenvolvedores nunca precisam lidar com os servidores.
Eles são gerenciados pelo fornecedor. Isso pode reduzir o investimento necessário em DevOps, o que diminui as despesas e também libera os desenvolvedores para criar e expandir seus aplicativos sem serem limitados pela capacidade do servidor;
Os desenvolvedores são cobrados apenas pelo espaço do servidor que utilizam, reduzindo os custos
Da mesma forma que em um plano de telefone pré-pago, os desenvolvedores são cobrados apenas pelo que utilizam.
O código só é executado quando as funções de back-end são necessárias para o aplicativo sem servidor, e o código é automaticamente expandido conforme a necessidade. O provisionamento é dinâmico, preciso e em tempo real.
Alguns serviços são tão precisos que suas cargas são divididas em incrementos de 100 milissegundos. Em comparação, em uma arquitetura tradicional totalmente baseada em servidor, os desenvolvedores precisam projetar antecipadamente quanta capacidade de servidor eles precisarão e depois adquirir essa capacidade, quer a utilizem ou não.
Arquiteturas sem servidor são intrinsecamente escaláveis
Imagine se os correios pudessem, como em um passe de mágica, aumentar e reduzir o número de caminhões de entrega à vontade, aumentando o tamanho de sua frota quando a quantidade de correspondência aumentasse (digamos, um pouco antes do Dia das Mães) e diminuindo sua frota nos momentos em que fosse necessário fazer menos entregas.
Isso é basicamente o que os aplicativos sem servidor conseguem fazer. Os aplicativos construídos com uma infraestrutura sem servidor serão dimensionados automaticamente conforme a base de usuários ou o uso aumentam.
Se uma função precisar ser executada em várias instâncias, os servidores do fornecedor irão inicializá-las, executá-las e encerrá-las conforme necessário, geralmente usando containers. (A função será inicializada mais rapidamente se houver sido executada recentemente.
Consulte “O desempenho pode ser afetado” abaixo.) Como resultado, um aplicativo sem servidor será capaz de lidar com um número excepcionalmente alto de solicitações tão bem quanto ao processar uma única solicitação de um único usuário. Um aplicativo estruturado tradicionalmente com uma quantidade fixa de espaço no servidor pode ficar sobrecarregado com um aumento repentino do uso.
É possível realizar implantações e atualizações rápidas
Ao usar uma infraestrutura sem servidor, não há necessidade de carregar o código para os servidores ou de fazer qualquer configuração de back-end para liberar uma versão de um aplicativo que funcione.
Os desenvolvedores podem muito rapidamente fazer o upload de bits de código e lançar um novo produto. Eles podem carregar o código de uma só vez ou uma função por vez, já que o aplicativo não é uma pilha monolítica única, mas sim um conjunto de funções fornecidas pelo fornecedor. Isso também torna possível atualizar, corrigir, consertar ou adicionar rapidamente novos recursos a um aplicativo.
Não é necessário fazer alterações em todo o aplicativo; em vez disso, os desenvolvedores podem atualizar o aplicativo usando uma função por vez.
Desvantagens da computação serverless
Da mesma forma, também é necessário analisar outras questões que podem ser consideradas desvantagens ao contar com este tipo de tecnologia. São elas:
Os testes e a depuração se tornam mais desafiadores
É difícil replicar o ambiente sem servidor a fim de ver como o código irá realmente funcionar depois de implementado.
A depuração é mais complicada porque os desenvolvedores não têm visibilidade dos processos de back-end e porque o aplicativo é dividido em funções separadas e menores. O Cloudflare Workers Playground é uma sandbox que ajuda a reduzir o atrito nos testes e na depuração.
A computação sem servidor apresenta novas preocupações de segurança
Quando os fornecedores executam todo o back-end, pode não ser possível verificar completamente sua segurança, o que pode ser um problema, especialmente para aplicativos que lidam com dados pessoais ou sensíveis.
Como as empresas não têm seus próprios servidores físicos distintos, os provedores sem servidor frequentemente executarão códigos de vários de seus clientes em um único servidor a qualquer momento.
Essa questão de compartilhar máquinas com outras partes é conhecida como “multilocação” (pense em várias empresas tentando alugar e trabalhar em um único escritório ao mesmo tempo). A multilocação pode afetar o desempenho do aplicativo e, se os servidores multi-inquilinos não forem configurados corretamente, isso pode acarretar a exposição dos dados.
A multilocação tem pouco ou nenhum impacto para as redes em que a sandbox funciona corretamente e tem uma infraestrutura poderosa o suficiente. Por exemplo, o Cloudflare executa uma rede de 15 Tbps com excesso de capacidade suficiente para mitigar a degradação do serviço, e todas as funções sem serverless hospedadas pela Cloudflare são executadas em sua própria sandbox.
Arquiteturas sem servidor não são construídas para processos de longa duração
Isso limita os tipos de aplicativos que podem funcionar de forma econômica em uma arquitetura sem servidor.
Como os provedores sem servidor cobram pelo tempo de execução do código, pode custar mais caro executar um aplicativo com processos de longa duração em uma infraestrutura sem servidor do que em uma infraestrutura tradicional.
O desempenho pode ser afetado
Como não está sendo executado constantemente, o código sem servidor pode precisar ser “inicializado” quando for utilizado.
Esse tempo de inicialização pode degradar o desempenho. Entretanto, se parte do código for usado regularmente, o provedor sem servidor o manterá pronto para ser ativado: uma solicitação para esse código pronto para uso é chamada de “inicialização a quente”. Uma solicitação de código que não é usado há algum tempo é chamada de “inicialização a frio”.
O Cloudflare Workers evita amplamente o problema de inicialização a frio usando o motor V8 do Chrome, que na maioria dos casos é capaz de inicializar e executar o código JavaScript em menos de 5 milissegundos. Se o código já estiver em execução, o tempo de resposta será inferior a um milissegundo;
O aprisionamento tecnológico é um risco
Permitir que um fornecedor forneça todos os serviços de back-end para um aplicativo inevitavelmente aumenta a confiança nesse fornecedor.
Configurar uma arquitetura sem servidor com um fornecedor pode dificultar a troca de fornecedores, se necessário, especialmente porque cada fornecedor oferece recursos e fluxos de trabalho ligeiramente diferentes.
Concluindo a computação serverless
Devido à menor complexidade operacional e a possível diminuição nos custos, o modelo de computação serverless está se tornando bem atrativo para usuários de nuvem.
Trouxemos um apanhado de informações sobre o assunto. Agora é o momento de descobrir como esse novo modelo pode ajudar sua empresa na prática!
E se você precisa de ótimas soluções em cloud ou outras tecnologias importantes para a segurança, armazenamento e desempenho da sua empresa, entre em contato com a Movti! Um dos nossos especialistas irá te ajudar a encontrar a solução que você precisa!
