 |
Definição
Em arquiteturas tradicionais, a implantação de um software abrange muito mais do que a sua lógica: servidores, middleware e runtime são alguns dos fatores que devem ser levados em conta. Ao utilizar uma arquitetura serverless, por outro lado, o desenvolvedor não precisa se preocupar com o que acontece a nível de infraestrutura e com a gestão de servidores.
Isso pode acontecer de duas formas. Ao dividir a sua aplicação em partes menores, o desenvolvedor pode usar serviços gerenciados para desempenhar funções que não fazem parte do diferencial da aplicação, como por exemplo login, gerenciamento de senhas e até mesmo armazenamento de arquivos, feitos por chamadas de APIs ou via SDK. Esse é um modelo de arquitetura serverless chamado BaaS (Backend as a Service ou, em português, Backend como um Serviço).
Já na segunda forma, a lógica da aplicação é dividida em funções e cada uma delas é implantada individualmente em uma plataforma de FaaS (Functions as a Service ou Funções como um Serviço), que está sempre disponível, sem gerar cobrança na ociosidade, e são acionadas por eventos. Assim, a plataforma de FaaS é configurada para responder a uma requisição, rodar o código necessário e, depois, encerrar a função solicitada. Em nenhum desses dois modelos de arquitetura serverless (BaaS e FaaS), o cliente gerencia a infraestrutura necessária para manter a aplicação.
O API Gateway é uma parte importante da arquitetura serverless. Esse recurso é um componente também serverless que, basicamente, atua na mediação entre o cliente da aplicação e as suas funções, gerindo as APIs. No exemplo acima, o cliente realiza uma requisição para uma aplicação web, o API Gateway recebe e roteia a requisição HTTP para a função requisitada; essa função, por sua vez, executa uma API externa ou interage diretamente com o banco de dados, tendo seu resultado retornado para o usuário também através do API Gateway. Nesse esquema, funções 1 e 2 são Funções como um Serviço e a API externa executada através da função 1, Backend como um Serviço.
Benefícios
Esse particionamento das funções da aplicação e a terceirização da lógica de algumas implementações no código apresentam alguns benefícios, como:
Redução de Custos
Para garantir a disponibilidade de uma aplicação, é necessário prever a sua escalabilidade ao provisionar os recursos de hardware. O desafio é que, na maior parte do tempo, esses recursos ficam ociosos, gerando despesas. Ao utilizar arquiteturas serverless, os custos são reduzidos porque não é preciso provisionar recursos, isso é feito pelo provedor do serviço. Assim, como as funções da aplicação em um ambiente serverless são acionadas por eventos, o cliente paga somente pelo tempo em que a aplicação foi executada.
Arquiteturas serverless também ajudam a reduzir o Custo de Trabalho. Dessa forma, ao usar Backend como um Serviço, por exemplo, não é preciso desenvolver toda a lógica da aplicação, o desenvolvedor tem menos código para programar, testar e implantar.
Redução de Riscos
Como os recursos de hardware são de responsabilidade do provedor de serviços, cabe a ele garantir a sua disponibilidade. Dessa forma, por mais que possam ocorrer períodos de downtime, eles são solucionados mais rapidamente por equipes preparadas e dedicadas a essas atividades, garantindo maior nível de serviço.
Escalabilidade
Arquiteturas serverless prevêem a escalabilidade automática das funções implantadas. Assim, se mais de uma requisição é feita para determinada função, a plataforma prepara outras instâncias para processá-las, escalando horizontalmente.
Inovação
Por todas as razões acima, é mais fácil inovar ao usar arquiteturas serverless. Uma das principais vantagens dessa abordagem é a redução de tempo na etapa de desenvolvimento de aplicações, já que é possível terceirizar partes do código ao utilizar Backend como um Serviço. Isso concentra os esforços do desenvolvedor no diferencial da aplicação e diminui o tempo entre concepção e implantação do projeto.
Desafios
Por ser uma tecnologia recente, arquiteturas serverless têm algumas limitações. Uma delas é o vendor lock-in, esse termo designa uma séries de peculiaridades de produtos que tornam o consumidor dependente do provedor do serviço ou tecnologia. No ambiente Serverless, esse termo se traduz na dificuldade de migrar recursos de uma plataforma de FaaS para outra, já que os serviços oferecidos por um provedor em particular possuem particularidades e configurações específicas para serem utilizadas.
Outra limitação são os cold starts. Isso acontece quando uma função escala para muitas instâncias executadas ao mesmo tempo, quando a função não costuma ser requisitada ou ainda quando foi alterada. O problema se refere à instanciação e inicialização dos contêineres que executam o código, isso gera um tempo maior de latência do que quando os contêineres já estão inicializados, o que é chamado de warm start.
É importante ter em mente que serverless é um conceito recente, que ganhou popularidade depois do lançamento do AWS Lambda, da Amazon Web Services, em 2014. Portanto, as limitações citadas e outras mais fazem parte de uma fase de aprimoramento e adequação da tecnologia por parte dos provedores de serviços e também da própria indústria, que ainda está aprendendo a fazer uso dela. Outros serviços serverless são Firebase e Google Cloud Functions, da Google Cloud Platform, e Azure Functions, da Microsoft Azure.