O termo Serverless vem ganhando cada vez mais força nos últimos anos, desde 2014 quando a Amazon lançou oficialmente o AWS Lambda. Até hoje sabemos que essa arquitetura de aplicação traz algumas confusões sobre como ela funciona, a começar pelo seu nome, que significa, literalmente, sem servidores.
Vamos começar esclarecendo que nós continuamos com servidores, porém os desenvolvedores não precisam mais se preocupar tanto com estes. A arquitetura Serverless incorpora serviços BaaS – “Backend as a service” (onde a lógica e o estado são controlados por terceiros, ex: Firebase) com FaaS – “Function as a Service”, onde a lógica ainda é escrita pelo desenvolvedor da aplicação, mas ele é executado em containers efêmeros (podem durar apenas uma execução), sem estado, e gerenciados por terceiros.
Agora que começamos a entender um pouco mais o termo, podemos nos questionar o porquê de adotar uma solução como esta. Eu defendo dois pontos principais: mais tempo focado em resolver problemas de negócio e pagamento da execução sob demanda, a seguir explico esses pontos.
Quando adotamos uma solução Serverless não precisamos mais planejar como iremos rodar nossa aplicação nos servidores. Normalmente, precisamos entender quantos servidores devem ser contratados, qual o melhor sistema operacional, se será necessário usar um load balance, quais os horários/dias de pico da aplicação para escalarmos e mais outros problemas. Todo esse tempo poderia ser traduzido no que realmente traz valor, código para solucionar as regras de negócio.
No momento que adotamos uma arquitetura Serverless é exatamente isso que acontece, todas as preocupações anteriores já estão resolvidas, nós precisamos apenas subir nossas funções e todo o estado/execução dela é delegado para o third-party escolhido.
Para explicar o pagamento sob demanda, vamos entender um pouco melhor como funciona essa caixa preta. Imagine que você faz o código de uma função hello world e o upload dela para o seu third-party (Amazon, Google, Microsoft, etc). Nesse momento, é necessário definir um evento que irá ser o gatilho da sua função (FaaS é event-triggered), por exemplo, uma chamada get em uma determinada url. Enquanto nenhuma requisição for feita para esse caminho, sua função estará offline, porém sempre disponível.
Quando uma requisição chegar, ela será encapsulada dentro de um container que vai subir e ficar ativo até a execução de toda a função ou do limite de tempo determinado para ela (hoje a Amazon já permite a criação de Lambdas com 15 minutos de execução). É necessário lembrar que as funções são stateless, ou seja, nunca podemos assumir que o seu estado estará disponível para uma chamada subsequente, porque essa chamada pode ser direcionada para um outro container e o anterior já pode até estar offline.
Quanto mais requisições a função receber, mais containers irão subir, logo trata-se de um escalonamento automático.
O valor a ser cobrado será referente ao número de solicitações feitas, ao tempo de execução e também aos recursos de processamento e memória que a sua função consumiu.
Com isso, além de você não consumir o tempo de desenvolvimento com os seus servidores, você paga apenas pelo que realmente usa e consegue escalar automaticamente.
Mas então você pode pensar que alguns serviços que são, apenas, BaaS, como o Heroku, já oferecem escalonamento automático. Porém existe uma diferença significativa, a granularidade. Quando falamos de escalonamento com BaaS estamos falando a nível de servidor, gastando mais tempo e dinheiro.
Já para Serverless, escala-se a nível de função, consequentemente é muito mais rápido de escalar, muito mais preciso e muito mais barato. Porque imagine que você tem um e-commerce, com arquitetura de microsserviços, decide fazer uma promoção apenas para usuários novos e rapidamente seu cadastro começa a ser muito requisitado, para escalar você precisa subir novas instâncias do seu serviço de usuários, que inclui n outras funções relacionadas a ele. No caso de Serverless, apenas essa função de cadastro seria escalada com base nessa alta demanda, sendo assim escalaria mais rápido, mais precisamente, com menos custo e de forma transparente.
Porém, sabemos que Serverless não é um solução definitiva para a sua aplicação e podemos citar como principais problemas: cold start, vendor lock-in e monitoramento.
São várias as linguagens que você pode escolher desenvolver suas funções: JavaScript, Python, Go, ou qualquer outra linguagem JVM. Mas essa escolha tem um impacto no tempo que a função demora para ser encapsulada num container e estar disponível, esse fenômeno é chamado de cold start.
Sabemos que JavaScript é uma linguagem interpretada, logo é muito mais rápido esse tempo para ela do que para Java, que precisa subir uma JVM. Assim, dependendo do propósito da sua aplicação, a latência para as linguagens compiladas pode ser um obstáculo.
Já o vendor lock-in, nesse caso, não se trata de você ter escolhido a Amazon e depois decidir migrar para o Google, mas sim você ter delegado todo o estado dos seus servidores para um third-party. Isso faz com que você se depare com limites e custos inesperados.
Em relação ao monitoramento, agora estamos lidando com nano-serviços, porque a granularidade fica a nível da função. Isso faz com que seja difícil ter uma visão geral da saúde da sua aplicação, então é necessário buscar produtos que possam te ajudar a ter um melhor dashboard, com informações mais claras como o tempo de cold start e tempo médio de duração de cada função, alarmes para funções com erro, em produção nós usamos uma ferramenta chamada IO/PIPE.
Para termos uma base de onde o Serverless se encontra em relação a adoção podemos olhar o Radar de Tecnologia da ThoughtWorks, que definiu desde 2007 a arquitetura como pronta para trial, isso significa que os padrões e modelos ainda estão sendo definidos, mas que já é possível adotá-la em produção.
Eu trabalho em um time que adotou Serverless desde o início do ano passado, e foi clara a evolução em relação a artigos, documentação e suporte, e até hoje acreditamos que tomamos a decisão correta ao escolher essa arquitetura. E por ter uma granularidade tão fina, você pode começar a adotar essa solução aos poucos no seu dia-a-dia e descobrir o quão bem ela se adapta a diferentes cenários.
Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.