Funções Lambda para prototipagem rápida

Nos últimos meses, a palavra “serverless” tem aparecido constantemente em eventos e blogs de tecnologia. A promessa do serverless é que alguns serviços ou frameworks podem dispensar a preocupação com servidores, permitindo que você apenas programe sem restrições. Certamente, servidores ainda estão por aí; então o que há de novo no atual cenário de infraestrutura de serviços (IaaS)? Arquiteturas Lambda são um paradigma novo e interessante que divide projetos em funções disponibilizadas em várias redes. É o mesmo conceito que equipes de trabalho apresentam para convencer seu CTO migrar para microsserviços.

Arquiteturas Lambda são poderosas porque são capazes de facilitar a idealização de projetos e torná-los mais econômicos. Assim como microsserviços, a arquitetura Lambda impõe novos desafios: descobrimento do serviço, educação da equipe, resiliência, multilinguagens e multicloud — para ressaltar algumas delas. Tudo e todos precisam estar coordenados. Além disso, funções Lambda se encaixam perfeitamente em projetos iniciais e experimentações. Este artigo apresenta algumas das ferramentas que você poderá utilizar no seu próximo projeto.

Fluxo de trabalho eficaz

Basicamente, arquiteturas baseadas em Lambda lançam uma unidade computacional para um serviço que executa algo. Obviamente, se você precisa gerenciar centenas de serviços com execução de etapas que acionam umas às outras, você pode terminar com fluxos semelhantes ao da Figura 1.

Figura 1. Fluxo de lógica complexa

Não vou me estender sobre esse cenário, mas recomendo que você consulte arquitetos experientes ou leia artigos adicionais para aprender a gerenciar deficiências técnicas e como microsserviços podem revidar.

Por agora, vamos focar em um projeto novo — um que seja fácil, limpo e eficaz. Primeiro, você deve concluir as lições básicas rapidamente — landing page, gerenciamento de usuário e pagamento — e, depois, você pode adicionar mais recursos. Contudo, ainda é muito cedo para dizer quais recursos irão cativar o usuário a ponto de ele pagar pelo produto.

Em resumo, o objetivo é construir um produto com segurança definindo os blocos nos quais você pode pensar isoladamente e somente quando precisar deles. Funções Lambda podem agilizar esse processo e encurtar o tempo de desenvolvimento do produto.

Você provavelmente não precisa migrar toda a sua infraestrutura profissional para a arquitetura Lambda. Você provavelmente precisa de menos frameworks e mais estruturas que apenas funcionem. E você certamente precisa definir como implementar e manter as centenas de funções.

Seja qual for seu stack, siga sua intuição e inicie uma nova Lambda. Encerre-a ou substitua-a. Você terá experimentações seguras e iterações rápidas.

Você talvez note que isso é semelhante a microsserviços, como o Docker, mas mentalmente menos desgastante. Você pode chamar de “nano” se quiser distingui-los, mas acredito que containers e Lambdas são o detalhe das implementações que se aproveitam dos mesmos benefícios do padrão da arquitetura descrita acima. Lambdas executam um serviço sendo uma função — e apresentam o benefício de serem encerradas quando não são mais necessárias. Isso força os desenvolvedores a pensarem em tarefas de processamento menores e stateless. O código resolve um problema com efeitos colaterais mínimos. Pense nisso como a combinação da boa e velha filosofia UNIX e da última tendência funcional. Sou suspeito, mas penso que isso deixa o desenvolvedor feliz, com um forte consenso da comunidade. E o que é preciso para fazer isso?

A maioria dos frameworks e SaaS exigem que você exponha a função com um objeto que pode guardar segredos como atributos de consultas HTTP. Certamente, nada evitará que você tenha que escrever 2 mil linhas de código entre module.exports e o callback(), mas isso pode remeter a um antipadrão.

E a facilidade da implementação pode rapidamente dificultar mais a manutenção do que dividir seus problemas em soluções diretas:

Agora você tem algum código que o levará ao HTTP graças ao Fission. Isso requer que você tenha em mãos um setup no Kubernetes, mas em pleno 2018 quem não tem um “sistema open-source para implementações, scaling e gerenciamento automático de aplicações em containers?”. Mas falando sério: se você não tem tempo ou não gosta de administrar clusters distribuídos, ainda está em boa companhia. Grandes plataformas de hosting oferecem ferramentas competitivas para a adição de Lambdas. Você pode estar pronto em apenas 30 segundos com o Webtask 101 — sem gastar um único centavo:

Depois de ter a chance de iniciar rapidamente um projeto como React ou Webpack, digamos, você percebe que não é algo sofrido — mas, ainda assim, é repleto de recursos:

E a função Lambda agora é executada periodicamente, o que, como você sabe, é um caso de uso bastante comum.

Em todos os aspectos, as barreiras para se inserir são mínimas aqui: você pode escrever um código como funções e não há exigência para domínio de uma linguagem nova específica nem configuração complexa. Ou ele podem ter sido rapidamente envolvidos em estruturas populares, assim como serverless faz para vários provedores de nuvem. Isso é importante porque novos paradigmas que não o obrigam a reaprender tudo e, no entanto, são imediatamente acionáveis em projetos costumam receber muita tração. E isso significa um ecossistema robusto de serviços, bibliotecas, ajudas e artigos. Isso gera movimento, e assim por diante.

Esses serviços e frameworks são especialmente importantes para o serverless porque o foco principal é poupar você do trabalho de gerenciar questões não relacionadas com o núcleo do seu projeto. Entretanto, ele usa tecnologias não triviais e gerencia infraestruturas complexas de instâncias computacionais efêmeras que são dinamicamente mapeadas nas gateways para rotear o tráfego.

Alternativas de self-hosting como o OpenWhisk oferecem maior controle sobre o serverless, sem tecnologias sofistificadas como proxies e containers. Então você deve ter seu time de DevOps e seu investimento pronto para fazer isso acontecer. Isso significa que você não terá qualquer relação com terceiros; a personalização completa permite alguns casos de negócio bem específicos (ou soluções de atalho). Mas isso também significa que os servidores estão de volta, então é importante estar ciente dos desafios relacionados a esse cenário — provisionamento, configuração, manutenção, monitoramento, performance e segurança.

Enquanto isso, vamos focar em como você pode aproveitar as ferramentas já existentes para diversão e lucro.

Projetos iniciais em nuvem: feedback e iteração de inicialização

Como você viu, códigos podem ser escritos rapidamente, e implantações podem ser baratas. O tempo necessário para ir da etapa da ideia até o online é o mínimo possível, e isso é uma faca de dois gumes. Como no Twitter, você pode colocar uma simples ideia na nuvem instantaneamente ou você pode seguir a filosofia Lean Startup e utilizá-la para iterar com mais agilidade. Seja qual for a qualidade inicial da sua ideia, você pode torná-la pública ou compartilhar com contatos seletos para obter feedback e experiência. Isso pode ser bom para saber se seu design ou sua tecnologia inicial é relevante. De outra forma, você pode construir uma landing page e engajar usuários. Depois, você saberá se sua ideia é algo que as pessoas querem ou se não merece mais tempo ou esforço. Engenheiros costumam não abrir mão de uma ideia que eles realmente querem construir (a menos que decidam recomeçar do zero ou mudar para outra tecnologia sofisticada). Não posso ajudar você a lutar contra isso, mas pelo menos você pode ter os números necessários para tomar a decisão.

Lambdas podem ser usadas segundo o princípio don’t repeat yourself (DRY) no nível de arquitetura. Eu considero esse argumento um tanto fraco, assim como várias “práticas recomendadas” em ciência da computação; é tão bom quanto o autor que a implementou. E, no entanto, o fluxo de trabalho serverless promove serviços dissociados com uma única finalidade; logo, você provavelmente pode compartilhar alguns deles, como processamento de pagamentos, renderização estática de sites, registro de usuários e assim por diante. Eu certamente fiz isso, e conforme você for desenvolvendo seus projetos, conseguirá extrair alguns padrões e compartilhar mais e mais serviços, acelerando sua caminhada até o nível de prototipagem. Eu realmente acredito, por outro lado, que isso será interrompido à medida que seu projeto crescer. Por experiência própria, nós tendemos a especializar blocos a fim de resolver um conjunto específico de finalidades. Isso significa manter as coisas da forma mais simples possível, implementando somente as ferramentas necessárias e seguindo o open/closed principle.

Vamos adicionar alguns ingredientes de open-source e comunidade à discussão. Já que estamos tratando de serviços dissociados e com limites evidentes, compartilhar um código pode ajudar em outros projetos. Recentemente, a Stdlib arrecadou US$ 2 milhões por oferecer uma biblioteca comum de funções acessíveis através da rede. Tudo parece apontar para essa direção, mas não posso afirmar que já chegamos lá. Talvez tenhamos muito a ganhar ao confiar em código de terceiros, trade-offs de desenvolvimento internos e adoption rates, mas ainda não há muitos projetos que aproveitem essa oportunidade. Apesar disso, como uma pequena ideia, pode ser algo a ser feito para (mais uma vez) agilizar. Por exemplo, todo serviço que é comum a um projeto SaaS inicial, mas não leva a uma finalidade específica, pode ser adicionado.

Embora essa estratégia claramente tenha suas limitações, é válido ressaltar que é viável em uma organização para empoderar times de desenvolvimento.

O cenário da nuvem: containers e tendências na tecnologia

Até agora, este artigo abordou argumentos favoráveis ao uso das tecnologias Lambda para protótipos pequenos. Eu espero que isso ressoe com a sua experiência e talvez leve você a experimentá-la no seu próximo projeto. Porém, caso qualquer um dos meus pontos ou palavras-chave tenha causado confusão, quero deixar claro onde Lambdas se encaixam no cenário DevOps (uma pequena parte dele, para ser justo).

Primeiro, nenhum desses termos são mutuamente exclusivos: você pode criar uma arquitetura em microsserviços utilizando Lambdas que rodem código dentro de containers. Isso não é um acidente, considerando que o serverless emergiu alguns anos depois do Docker e containers. Eles desbloquearam uma poderosa orquestração da nuvem e forneceram a agilidade necessária para Lambdas serem iniciadas por eventos e encerradas após o processamento.

Da forma que vejo, tudo isso se resume ao uso do desenvolvedor e aos objetivos do negócio. Nada impede você de inserir elefantes em containers ou desenvolver microsserviços em máquinas bare-metal. São ferramentas que você pode aproveitar e combinar, dependendo de suas restrições. Kubernetes, por exemplo, se define como uma orquestração de containers de nível de produção, mas com alguns ajustes você pode gerar um framework serverless:

• Microsserviços são um padrão de arquitetura que promove serviços dissociados com limites e interfaces claros e pequenos.

• Containers são um recurso do Linux que permite isolamento mais leve de processos que VMs, graças ao cgroups.

• Lambdas são funções efêmeras que são acionadas em eventos específicos, processam e se encerram.

Conclusão

A startup na qual trabalho organizou recentemente seu primeiro hackathon. Construímos vários projetos em 24 horas, e vários de nós acabamos usando funções Lambda porque elas eram rápidas e baratas (de graça, na verdade). Nós conseguimos dividir o trabalho em times de três ou quatro pessoas. O escopo estava bem definido e era perfeito para projetos baseados em eventos (como o desenvolvimento de bots para o Slack). Alguns de nós estávamos trabalhando com o framework pela primeira vez e ainda fomos capazes de torná-lo operacional em poucos minutos escrevendo, desenvolvendo e monitorando o código Lambda.

Tudo isso pode ser interrompido à medida que seu projeto cresce. No entanto, ao passo que aprimoramos as ferramentas para desenvolvedores, acredito que esse paradigma nos leva na direção certa: execução simples, custos efetivos e facilidade no uso e no compartilhamento. É provável que você não precise migrar toda sua infraestrutura profissional para a lambda. É provável que você precise de poucos frameworks e mais estruturas que apenas funcionem. E você definitivamente precisa definir como lançar e manter centenas de funções.

Então pule a bordo! Essa já é uma tecnologia empolgante e ainda temos muito para contribuir.

...

Quer ler mais conteúdo especializado de programação? Conheça a IBM Blue Profile e tenha acesso a matérias exclusivas, novas jornadas de conhecimento e testes personalizados. Confira agora mesmo, consiga as badges e dê um upgrade na sua carreira!