Como o serverless muda a maneira como os desenvolvedores criam e testam

O Serverless continua crescendo em importância, mas, de acordo com alguns especialistas, requer uma maneira diferente de arquitetar e testar sistemas.

De acordo com algumas medidas, mais da metade das empresas adotaram o serverless. Se você está do lado “ainda não” dessa equação, a engenheira líder da comunidade da Prefect, Anna Geller, ofereceu várias maneiras pelas quais a computação sem servidor não apenas ajuda as empresas a construir de forma mais eficaz, mas também incentiva os desenvolvedores a codificar de forma mais produtiva.

E, no entanto, como o cofundador da Serverless Days, Paul Johnston, destacou, muitos desenvolvedores abordam o serverless de forma errada e tropeçam no processo.

Como ele observou: “Se você tratar um sistema sem servidor como um sistema de software e tentar construí-lo dessa maneira, é muito mais provável que você se esforce para obter o melhor resultado”.

Mas o que ele quer dizer e como os desenvolvedores podem evitar essa armadilha?

VEJA: AWS Lambda, uma estrutura de computação sem servidor: Uma folha de dicas (PDF grátis) (TechRepublic)

Por que ficar sem servidor?

Uma das melhores coisas do serverless, de acordo com Geller, é que ele incentiva práticas úteis de engenharia. Por exemplo, se podemos concordar que “é benéfico construir componentes de software individuais de tal forma que eles sejam responsáveis ​​por apenas uma coisa”, então o serverless ajuda porque “incentiva o código que é fácil de mudar e sem estado”.

Além disso, ela continuou, sem servidor, mas força um desenvolvedor a construir um código reproduzível.

“O Serverless não apenas força você a tornar seus componentes pequenos, mas também exige que você defina todos os recursos necessários para a execução de sua função ou contêiner”, disse Geller.

Ao exigir esses serviços independentes, o serverless incentiva os desenvolvedores a se preocuparem com “coreografia em vez de orquestração, com cada componente desempenhando um papel mais arquiteturalmente consciente”, como Mike Roberts, da Symphonia, postulou.

Essa ideia de arquitetura orientada a eventos é poderosa, mas também onde muitos desenvolvedores saem dos trilhos.

Construindo com coreografia em mente

“Sistemas sem servidor devem ser (mas raramente são) considerados como um grande número de sistemas desacoplados, mas muito pequenos, completamente independentes uns dos outros, conectados por eventos”, observou Johnston.

Bem, é assim que o software funciona, certo?

“Sim”, ele acrescentou, “isso é ‘software’ no sentido geral. Mas isso não é ‘software’ no sentido que a maioria dos desenvolvedores ou gerentes pensam sobre isso.”

Parte dessa dissonância entre o pensamento de sistemas sem servidor e de software se resume à segurança – sem servidor exige que um desenvolvedor confie algumas preocupações de segurança ao provedor de nuvem subjacente – e uma perda geral de controle porque, novamente, mesmo que o desenvolvedor se concentre em seu aplicativo lógica, o provedor de nuvem ainda está gerenciando servidores em seu nome. Mas é realmente na área de testes que a diferença necessária de abordagem é exposta.

“O alto elemento de desacoplamento em um sistema sem servidor significa que você não tem o mesmo requisito para testar entre as equipes”, enfatizou Johnston. “Cada elemento único precisa de teste (isso não muda), mas como cada elemento é desacoplado (ou deveria ser) e é pequeno (ou deveria ser), deve haver um acoplamento próximo de zero entre as equipes e entre os elementos. Se houver acoplamento próximo de zero entre equipes e elementos de um sistema, então… você só precisa testar os elementos (exceto onde há acoplamento, onde você precisa testar).”

O teste de unidade permanece relativamente simples, mas o teste de integração se torna mais difícil e ainda mais importante.

“Parte da razão pela qual considerar os testes de integração é importante é que nossas unidades de integração com Serverless FaaS são muito menores do que com outras arquiteturas”, escreveu Roberts. “Contamos muito mais com testes de integração do que com outros estilos arquitetônicos.”

Isso é complicado pela necessidade de confiar nas nuvens para esses testes, o que pode ser um salto desconfortável.

“Confiar em ambientes de teste baseados em nuvem em vez de executar tudo localmente no meu laptop foi um choque para mim”, disse Roberts.

E depois há a abordagem da arquitetura (e teste) que difere.

“Então, o processo de desenvolvimento [in the serverless world] trata-se de construir muitos elementos pequenos e desacoplados e testá-los”, disse Johnston. “O processo de gerenciamento mais amplo a a ser entender como esses elementos pequenos e desacoplados se encaixam.”

Coreografia, não orquestração, em outras palavras.

Uma mudança intransponível no pensamento? Dificilmente. Mas é diferente e, como Johnston, Roberts e outros argumentam, descobrir essas diferenças e construir de acordo é a chave para obter o serverless certo.