Serverless: Computação sem servidor

Serverless: o futuro das aplicações?

Olá surinauta! Bem vindo a mais um post. Hoje vamos falar sobre Serverless: computação sem servidor. Este será o mergulho em um dos tópicos anteriores: Expectativas para cloud computing no futuro. Vamos ver o que é, como utiliza-la e desmistificar algumas lendas sobre essa tecnologia.

O que é Serverless?

Executar funções, ou até aplicações inteiras, sem se preocupar com criar, configurar ou manter os servidores; isso é a motivação de serverless. Nesse sentido, os provedores de cloud oferecem serviços como AWS Lambda, GCP Functions ou Azure Functions.

Mas arquiteturas serverless não são apenas backend. Serviços de frontend serverless podem ser providos também via AWS S3, GCP Cloud Storage ou Azure Storage.  Com isso, sites estáticos ou camadas de frontend para suas aplicações podem ser disponibilizadas utilizando todas as facilidades da arquitetura serverless.

Este modelo de desenvolvimento está sendo difundido e ganhando novos adeptos a cada dia. Com o intuito de facilitar seu uso, já existem frameworks para trabalhar com ela. Um exemplo desses frameworks que está sendo muito bem aceito e se integra com a maior parte dos provedores cloud é o https://serverless.com.

Há quem defenda que serverless será o futuro das aplicações. Mas ela não será para todos. Embora sejam várias as facilidades apresentadas, existem características que limitam a atuação em sua hospedagem.

Serverless Evolution (fonte: https://hackernoon.com/how-can-serverless-computing-benefit-your-startup-67503e08f76e)

Serverless Evolution (fonte: https://hackernoon.com/how-can-serverless-computing-benefit-your-startup-67503e08f76e)

Facilidades

Mas não se desesperem, ainda existem muitas facilidades que sua aplicação pode usufruir de ambientes serverless. Nesse sentido, veja alguns dos pontos positivos que tornam essa tecnologia cada dia mais atrativa para os desenvolvedores:

  • Escalabilidade: talvez essa seja a característica mais atrativa aos desenvolvedores. A capacidade de se adaptar e atender a mais ou menos demandas, sem necessitar de configurações adicionais, certamente é muito bem vista. Nesse sentido, as requisições são processadas de forma elástica, aumentando ou reduzindo a quantidade de serviços providos em função chamadas recebidas;
  • Pouca ou nenhum configuração de ambiente: justamente por não haver servidor para ser configurado, toda a camada acima dele também não terá necessidade de ser ajustada. Sistema operacional, interpretador de linguagem, máquina virtual, tudo será provido como serviço; desonerando trabalho de sua equipe;
  • Segurança: o que é um ponto negativo, em termos de flexibilidade para o desenvolvedor, é o destaque da segurança. Com isso, as restrições de acesso ao ambiente tornam-se uma garantia de segurança para as aplicações. Varreduras de pastas, execução de comandos remotos, injeção de códigos terão acessos limitados diretamente pelo provedor do serviço;
  • Versionamento de ambiente: todos os serviços oferecido atualmente tem algum esquema de versionamento. Com isso, sejam URLs diferentes para APIs ou histórico de alterações para arquivos estáticos, é possível acessar ou recuperar uma versão anterior, ou até trabalhar com diferentes versões em paralelo.

Limitações

Esta é certamente uma tecnologia revolucionária que facilita muito a sustentação das aplicações.  Entretanto existem alguns pontos a serem observados antes de se aventurar por esses mares.  Confira alguns deles:

  • Acesso a pastas do servidor: a ideia é não ter servidor; logo, não haveriam pastas em discos para serem acessadas. Com isso, a ideia é que sua aplicação não precise gravar e nem ler nada do sistema de arquivos. Mas alguns serviços permitem criar áreas que podem ser manipuladas como se fossem pastas locais, com as devidas permissões restritas;
  • Executar linha de comando: o acesso e as permissões ao terminal ou prompt de comando são bem restritas. Assim como o item anterior, em que as aplicações não podem navegar pelos diretórios do servidor, os comandos acessíveis também são bem limitados ou até totalmente bloqueados;
  • Natureza stateless: aplicações tem a capacidade de armazenar estados de sessões em seus servidores de aplicação. Mas caso não haja um servidor para se armazenar, logicamente esses dados deverão ser guardados em outro local. É muito comum o uso de bancos de dados em memória (Redis ou Memcached) ou NoSQL (MongoDB) para persistir dados temporários de acessos dos usuários das aplicações;
  • Utilizar bibliotecas nativas: este item também é um reflexo da natureza de não se ter acessos de baixo nível ao servidor. Instalações de novas bibliotecas ou APIs que acessem diretamente o kernel do sistema operacional não estarão disponíveis. Os ambientes tem uma configuração padrão e com poucas aberturas para personalizações.

Mitos

Finalmente, tudo que é novo e de pouco conhecimento geral, acaba rodado por muitos mitos. As incertezas sobre o que é certo e errado sobre a tecnologia podem ser divulgadas sem nenhum embasamento comprovado. Mas seguem alguns dos mitos que certamente vocês não precisam se preocupar:

  • Não existem servidores: não gerenciar um servidor, não que dizer que não exista um servidor. O serviço é apenas uma abstração do trabalho para oferecer mais valor no desenvolvimento. Mas certamente existe um servidor por trás, um sistema operacional, com ambiente de execução para a linguagem de programação e, possivelmente, um servidor de aplicação;
  • Lock-in com provedor: algumas bibliotecas podem ser encapsuladas e disponibilizadas de acordo com o provedor em que esteja hospedado. Nesse sentido, pode haver alguma dependência em relação a essas chamadas. Uma boa modularização e frameworks, como o supracitado https://serverless.com, minimizam em muito esses problemas;
  • Segurança 100% garantida: a segurança na nuvem é composta de diversas camadas. Os níveis que estejam a cargo da infraestrutura, serão garantidos pelo provedor do serviço. Mas a proteção da aplicação e de seus dados, ainda é responsabilidade dos desenvolvedores. Acessos indevidos ao servidor e alteração de código serão bloqueadas nativamente pela arquitetura. Entretanto, SQL injection ou roubo de credenciais ainda devem ser impedidas pela aplicação;
  • NoOps: a desoneração de monitoramento da infraestrutura não tira o mérito de monitorar a aplicação. O processo integrado de CI e CD deve acontecer normalmente, assim como o acompanhamento das quantidades de requisições por período e uso de CPU e memória por cada processamento. Todos estes insumos devem ser coletados e retroalimentar o processo de melhoria contínua em DevOps.

 

Gostou dessas dicas? Tem outras dúvidas sobre o assunto? Deixe um comentário!

Para saber mais sobre nossos serviços, acesse: atmosfero.com ou surittec.com.br.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *