O lado oculto da estratégia Serverless

25 de janeiro de 2021 Por Ramon Durães

A computação em nuvem é uma das principais evoluções no mercado de tecnologia nos últimos anos tornando acessível a pessoas e empresas recursos computacionais que antes eram disponíveis a grandes empresas, permitindo, portanto, a aceleração da Transformação Digital.

Para um rápido entendimento das abordagens de Cloud Computing é importante citar alguns conceitos adotados no mercado, conforme demonstrado nos tópicos abaixo:

Infrastructure as a service (IaaS) com mais foco em infraestrutura, como máquinas virtuais gerenciadas pelo contratante que cuida da administração e gestão do sistema operacional como atualizações.
Platform as a service (PaaS) oferece uma abordagem com serviços prontos, como um servidor de aplicação totalmente gerenciado pelo provedor de nuvem e disponibilizado como “serviço”.
Function-as-a-service (FaaS) oferece uma abordagem “Serverless” sem custos iniciais com alocação de servidores e totalmente gerenciado pelo provedor de nuvem.
Kubernetes as a Service (KaaS) oferece uma abordagem Cloud-Native, disponibilizando a infraestrutura do Kubernetes gerenciado pelo provedor de nuvem.

A abordagem “Serverless” ou “Functions” introduzida pela Amazon AWS com o nome “Lambda” e disponibilizada no Microsoft Azure e Google Cloud como “Functions” oferece uma proposta bem interessante com um modelo computacional teoricamente gratuito e/ou mais barato que as outras abordagens de forma que comercialmente se “posicionaram”, inclusive, como o futuro da Cloud Computing.

No entanto, como a proposta deste artigo é analisar o impacto da abordagem Serverless na estratégia de software e na Transformação Digital das empresas, nós discutiremos alguns pontos para ficar claro que não existe almoço grátis. Nós analisaremos a abordagem promovendo uma reflexão profunda sobre decisões tomadas no dia a dia que afetam diretamente o futuro dos projetos.

O modelo Serverless oferece escalabilidade dinâmica e automática e é cobrado pela quantidade de Requests recebidos com uma quantidade inicial gratuita o que se torna bem “atrativo”. Outros pontos de cobrança devem ser observados com bastante atenção como:

Compute Time (ms) (Tempo de processamento medido em milissegundos da sua API, incluindo o tempo de retorno de um serviço externo, como chamadas a um banco de dados externo)
CPU / Memory (GB-s) (Alocação de recurso)
API Requests (Uso do API Gateway para exposição como API’s)
Networking (In/Out) (Tráfego de entrada e saída)
Storage (Armazenamento)

Após apresentação dos itens acima é fundamental ressaltar que apesar de uma abordagem automática de escalabilidade se você não tiver uma gestão profunda de Observability (Log, Trace, Metrics) acompanhando o Serverless você estará exposto ao risco de não ter uma boa experiência com serviços, deixando de responder ou cobrando “bem” acima do valor “grátis”.

A abordagem Serverless é sempre vendida de forma muito simples, escalável, fácil, quase de graça e na demonstração sempre aparece um “Hello, World!” com um método contendo em média 50 linhas de código de software que dão um retorno rápido e bonito em milésimos de segundos. Imagina uma propaganda fantástica que apenas tem o botão comprar, comprar, comprar.

No meu primeiro contato com “Serverless” me veio de imediato uma profunda reflexão sobre a abordagem de “Stored Procedure” empurrada pelos fornecedores de banco de dados na década passada, transformando-o em uma das camadas de negócio da aplicação, propagando uma contaminação extrema até os dias atuais nos projetos legados.

A tendência comum é entendermos que ao usar uma arquitetura “Serverless” não pagaremos quase nada ao provedor de Cloud. Você realmente acredita que o provedor de Cloud funciona como uma “ONG”? A realidade depois do “Hello, World!” tem mostrado que a prática não é bem assim.

Os projetos reais são complexos, demoram mais tempo no processamento e possuem processos longos “long running process”. Outro problema comum são os clientes que não desejam aguardar o tempo do “Cold starts” do Serverless para responder uma requisição de um cliente e você também pagará mais por isso em algum momento.

Com o passar dos anos o histórico de consumo do Serverless em projetos reais tem provocado muitas reflexões, visto que na operação o “barato” não é tão “barato”. Eu não estou discordando do preço cobrado e, sim, da ilusão que é de graça. Portanto, apenas se atente que existe uma conta a ser paga em Cloud e motivo de estudo pelos profissionais “FinOps”, “Software Architecture”, “Cloud Architecture”.

Na posição de estrategista de software eu preciso me preocupar com detalhes e um deles é altamente crítico e conhecido como o “Lock-in no Cloud Provider”. O risco do acoplamento de todo desenvolvimento do software no provedor de Cloud (AWS, Azure e GCP).

A adoção desse tipo de estratégia expõe o negócio a um risco de ruina em uma eventual mudança de tecnologia e/ou precificação por parte do provedor de nuvem e/ou impossibilidade de usar partes dos serviços em outro provedor por uma vantagem competitiva ou mitigação de risco (Multi-Cloud / Cloud-Native). No atual momento os provedores oferecem ótimas vantagens aos clientes para usarem as suas plataformas.

O movimento Cloud-Native acabou se popularizando nos últimos anos com ofertas de Kubernetes nos principais provedores de Cloud. O Kubernetes é uma ferramenta OpenSource para o gerenciamento de containers e é oferecido no formato gerenciado pelos provedores de Cloud, permitindo a adoção de uma estratégia de “Microservices” e outros serviços comuns no seu negócio aliando-se a todo o poder computacional da nuvem.

As principais ofertas gerenciadas de Kubernetes disponíveis são o Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (Amazon EKS) e o Google Kubernetes Engine (GKE), unificando o melhor uso da nuvem com serviços gerenciados, auto escaláveis em um formato que podemos conceitualizar como “Container as a service (CaaS)” ou “ContainerLess”, como eu prefiro chamar.

Na prática suas aplicações terão um ambiente computacional com um ótimo custo, permitindo a publicação de um serviço em vários provedores de Cloud Computing. Nesse modelo, por exemplo, de Container o Azure não cobra a API do Kubernetes e, sim, os nodes (Instâncias) com base na configuração escolhida e no tamanho (CPU/Memória/Disco).

O serviço escala automaticamente sem nenhuma intervenção cobrando apenas pelo período utilizado de forma similar ao Serveless. Os clusters podem utilizar instâncias de containers (Azure Container Instances (ACI), AWS Fargate…) por meio do “Virtual Kubelet”.

Os principais provedores de nuvem oferecem também um modelo de contração prévia de recursos conhecido como “Reserved Capacity” resultando em um custo bem mais baixo nos serviços, podendo variar até a 80% em alguns cenários, tornando uma operacionalização de Cloud-Native / KaaS / CaaS para cenário de aplicações complexas bem mais barato que o próprio Serverless sem deixar de explorar todo o potencial da nuvem.

O Serverless nativo do provedor de nuvem (AWS/Azure/GCP) é o novo legado? Baseado em iniciativas Cloud-Native tem surgido projetos Serverless que executam “tasks” dentro do Cluster Kubernetes como Knative (Google), OpenFaaS (Vmware), Kubeless (Bitnami), OpenWhisk (IBM), Fission (Platform 9) e muitos outros. Os projetos citados servem de referência para que você pesquise e aprofunde no tema, caso julgue interessante.

Conforme você observou acima o universo de Cloud Computing tem muitas variáveis e recomendo fortemente que quando for definir uma estratégia de longo prazo busque contratar um profissional especializado no tema, permitindo-o analisar os objetivos da empresa e construir em conjunto uma estratégia de Cloud Computing de longo prazo.

Se você chegou até aqui mesmo depois das provocações acima, então prepare-se, pois a melhor parte ficou para o final e evolve efetivamente um dos ativos da empresa que é o código fonte do software desenvolvido. Caso trabalhe com desenvolvimento de software sabe o quanto é desafiador definir e manter uma estratégia para apoiar o negócio e no futuro com manutenções, evoluções, etc.

Esse momento me lembra muito uma frase do CEO da Microsoft, Satya Nadella “Every company is a software Company” refletindo o tamanho dos investimentos em projetos de desenvolvimento de software. O mercado aumentou a demanda por contratação de pessoas desenvolvedoras de software o que naturalmente requer uma maior preocupação sobre cada linha desenvolvida.

Ao avaliar uma estratégia Serverless você já se perguntou quantas funções “Serverless” você vai desenvolver (10, 10 mil ou 100 mil)? E usando quantas linhas de código em cada Serverless (50, 1000, 5000)? E qual o tamanho da equipe e experiência? E como evoluir o código fonte pelos Squads diferentes mantendo a qualidade?

Não se iluda achando que o Serverless vai resolver o problema do código fonte ruim do projeto. O maior risco é ignorar as estratégias de Software Development Life Cycle (SDLC).

As práticas de arquitetura de software e engenharia de aplicação são fundamentais quando se trata de negócios digitais, onde existe uma dinâmica muito maior de evolução do software e alto impacto em caso de falhas.

Não adianta modernizar o negócio e construir uma pilha de débitos técnicos tornando a manutenção inviável ao ponto de impedir a continuidade do negócio. As abordagens de Domain-Driven Design (Eric Evans / Vaughn Vernon) são importantes para uma colaboração entre as equipes de negócio e desenvolvimento do software, padronizando o negócio, conforme exemplo abaixo:

Fonte: Bounded Context – Martin Fowler

Os princípios de arquitetura de software se tornaram essenciais para guiar o desenvolvimento do código fonte e escalar os projetos entre as equipes de desenvolvimento de software, atuando fortemente em práticas de Loose coupling (Baixo acoplamento), Reuse (Organização e reuso de serviços) , Manutenability (Código estruturado e simples de manter), Testability (Estratégia de testes com isolamento de dependências) / Reliability ( Estratégia de disponibilidade).

Nós temos a disposição no mercado várias ferramentas como o Sonar que analisa a qualidade do código fonte desenvolvido, ferramentas de segurança para código, containers, componentes. Na imagem abaixo uma amostragem do Quality Gate do sonar:

Fonte: SonarQube – http://bit.ly/36bruvy

A experiência computacional oferecida pelos serviços do Cloud Computing é fantástica e democratizou a digitalização das empresas. O desenvolvimento do seu software continuará sendo o maior desafio e fundamentos importantes de arquitetura de software, padronização e o que eu qualifico como gestão do “Custo de Propriedade do software” tendem a definir o futuro do negócio e evitar o “spaghetti code”, duplicação de código.

Na minha opinião inovar não é adotar Serverless e, sim, desenvolver um software bem feito, atuando na causa raiz dos problemas recorrentes nos projetos de forma que consiga promover uma experiência de inovação no negócio seja em conjunto com Serverless ou não.

Para saber mais:

Cloud Native Computing Foundation (CNCF)