Computação sem servidor, até o fim da lógica da nuvem
A computação sem servidor é um princípio que surgiu recentemente no cenário de TI. É uma espécie de busca pelo absoluto por parte dos CIOs, e talvez ainda mais por parte dos CFOs. Ele procura responder à pergunta mais primitiva da nuvem: podemos passar sem servidores?
Quando a computação em nuvem nasceu, o objetivo era reduzir o custo do investimento em infraestruturas de TI. E, por extensão, para nos livrarmos gradualmente de todas as restrições impostas por essas infraestruturas.
Vamos dar uma olhada mais de perto no serverless: como ele é definido? Quais são os benefícios mais tangíveis e demonstráveis e, acima de tudo, quais são as desvantagens e os riscos? Como você verá nas respostas que fornecemos abaixo, não há nada de mágico no serverless. Mas há uma combinação eficaz de tecnologias e modelos de negócios para responder o mais próximo possível às demandas em constante mudança das empresas.
Sem servidor: a definição de computação sem servidor
O que é sem servidor?
O termo "sem servidor" refere-se à execução do código de um aplicativo sem a necessidade de um servidor. Não há infraestrutura local ou em nuvem dedicada especificamente a uma determinada organização ou aplicativo.
Em outras palavras, em uma arquitetura sem servidor, não apenas a execução do código, mas também a manutenção dos servidores, é gerenciada pelo provedor de nuvem.
O advento do FaaS, Função como Serviço
É necessário fazer um esclarecimento: por trás desse nome atraente estão, apesar das aparências... servidores.
Porque a tecnologia ainda não está no estágio em que a computação se tornará totalmente virtual, impalpável, livre de todas as restrições físicas. Existem, é claro, recursos e servidores nos quais o código será executado.
Essa abordagem é bastante semelhante à dos microsserviços. A diferença é que a arquitetura sem servidor está naturalmente vinculada a um provedor de serviços em nuvem (CSP). Já os microsserviços são baseados em contêineres que podem ser implantados em diferentes hospedagens.
O termo FaaS, ou Função como serviço, é usado com frequência. A ideia é executar uma função sob demanda, toda vez que ela for necessária, solicitando um provedor de nuvem remoto:
- O desenvolvedor só precisa fornecer seu código;
- o provedor retornará o resultado toda vez que ele for solicitado.
Portanto, antes de mais nada, estamos buscando reduzir os custos de infraestrutura e ser altamente adaptáveis.
Vantagens e limitações do serverless
Vantagens financeiras... mas não só
O modelo de faturamento é, na maioria das vezes, um modelo de "pagamento conforme o uso": a empresa paga pela memória, pelo armazenamento e pela capacidade de computação usados durante a execução, de acordo com seu uso e, portanto, de acordo com o tempo de servidor utilizado:
- O serverless possibilita a redução dos custos de um serviço que é pouco utilizado;
- de qualquer forma, o faturamento é uma espécie de culminação do conceito de computação em nuvem: é um reflexo estrito do uso feito do servidor remoto;
- se uma função ou código não for executado, o custo pode ser zero.
Outra vantagem é a velocidade de desenvolvimento. Para passar do projeto à produção, você não precisa mais se preocupar com a infraestrutura: a capacidade de computação estará inevitavelmente disponível, como e quando você precisar dela.
A flexibilidade também é uma vantagem definitiva. Se você não quiser perder tempo dimensionando ou testando recursos de hardware, transfira a carga para o CSP. Ele sempre será capaz de fornecer a energia de que você precisa, quando você precisar: isso faz parte do contrato.
Sem servidor, mas não sem restrições
Apesar das aparências, essa arquitetura impõe certas regras.
Uma delas é o número reduzido de fornecedores. Os três maiores são :
- AWS (Amazon Web Service) e, em particular, o AWS Lambda, que é o jogador histórico,
- Microsoft Azure Functions,
- e o Google Functions.
O método de faturamento significa que você precisa projetar um código que não consuma muito tempo de computação:
- em todo caso, o tempo de execução alocado para a função é geralmente limitado;
- você não pode excedê-lo, ou ele será cobrado em excesso.
Por exemplo, a AWS, que lançou esse conceito em 2014, fornece os seguintes números:
- o tempo médio de execução de uma função em seus servidores é de 800 ms,
- apenas um quarto excede 3 segundos
- e 12% são executados por mais de 10 segundos.
Em geral, a codificação é limitada pelas linguagens (ou idioma) suportadas pelo provedor de serviços em nuvem. O faturamento também se baseia na memória necessária para executar seu código.
Portanto, embora a arquitetura sem servidor seja altamente flexível e possa lidar com grandes aumentos na carga de trabalho, ela deve ser mantida sob controle em termos de custo. Ela pode até ser mais cara do que uma arquitetura tradicional no local ou na nuvem.
Sem servidor também significa uma abordagem específica à segurança
Devido à sua natureza muito específica, o paradigma sem servidor se destaca em vários aspectos quando se trata de segurança:
- os provedores de nuvem gerenciam o sistema operacional, a segurança do tempo de execução e os patches. Isso é uma garantia, dada a escala dos provedores atuais;
- a natureza efêmera e sem estado da computação sem servidor torna a vida mais difícil para os invasores. O fato de as funções sem servidor irem e virem, sem memória, reduz o risco de ataques de longo prazo;
- o tamanho pequeno dos blocos de código facilita a análise por ferramentas de segurança de CSP.
Por outro lado, essa arquitetura também cria vulnerabilidades. Cada função se torna um possível ponto de ataque, dificultando o monitoramento de seus servidores pelos provedores. Também é mais complicado, tanto para o CSP quanto para o codificador, observar vários processos e vários pontos de entrada/saída.
Os aplicativos tradicionais têm um perímetro mais claro, com o exterior e o interior claramente distintos. Os recursos de segurança tradicionais, como WAF, firewall e IDS, podem ser instalados.
Por fim, é importante observar que os aplicativos nativos em nuvem podem usar vários módulos e bibliotecas com códigos de várias fontes de terceiros. Os possíveis invasores podem tentar incluir códigos maliciosos em projetos comuns.
Sem servidor, uma arquitetura a ser adotada com urgência?
Como geralmente acontece com tecnologias e conceitos emergentes, precisamos dar um passo atrás antes de decidir se vamos adotá-los ou rejeitá-los. Ela só faz sentido em um determinado contexto.
Além do simples aspecto técnico, seu uso também pode ter um impacto sobre os recursos humanos de sua organização. Ele exige que você conte com uma equipe sólida de programadores, que talvez precise ser reforçada.
Ao mesmo tempo, isso pode levar a uma redução nos recursos dedicados à infraestrutura e ao seu gerenciamento.
Portanto, na verdade, mesmo que pareça ter sido projetado para permitir que você faça escolhas pontuais, ao impulsionar determinados projetos, ele pode transformar profundamente seu departamento de TI e os serviços vinculados a ele.
Artigo traduzido do francês