Tivemos um problema interessante há alguns anos. Somos uma empresa totalmente remota com todo o nosso software na nuvem. E tínhamos um conjunto de aplicativos Spring Boot em execução em contêineres com infraestrutura como código. Mas precisávamos de agilidade nos negócios.

O mercado global de trabalho se move rapidamente, e sempre há demanda por novos produtos. Tivemos que encontrar uma maneira de manter nossa liderança em todo o setor.

Somos uma empresa de tecnologia com uma estratégia ousada

Em 2022, criamos um ADR (Registro de Decisão de Arquitetura) que dizia: "sem servidor em primeiro lugar e contêineres conforme necessário". E desencadeou debates em quase 40 equipes de engenharia.

Vamos explicar uma terminologia primeiro

Serverless-first não é apenas funções-como-serviço. É também um grupo de serviços gerenciados de provedores de nuvem que: 

  • Menor sobrecarga operacional ao não gerenciar a infraestrutura

  • Dimensione conforme necessário, incluindo a escala até zero para torná-los totalmente elásticos

  • Tem preços elásticos (você paga apenas pelo que usa) 

Na G-P, serverless-first refere-se ao uso do AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, API Gateway, S3, DynamoDB e outros.

O Serverless-first significa que, quando selecionamos uma solução para computação, armazenamento, mensagens ou similar, gostaríamos que as equipes começassem com uma opção serverless. Uma observação importante: se o serviço serverless não atender à necessidade, as equipes devem voltar para um serviço mais pesado, que exija mais investimento operacional.

“Contêineres conforme necessário” esclarece que serverless-first não significa serverless-only. Há momentos em que precisamos de contêineres (por exemplo, instalar um produto de software COTS) — e tudo bem.

Uma estratégia de tecnologia que prioriza os clientes

Nós nos movemos em um ritmo ágil para atender às necessidades de nossos clientes e usuários. Serviços como Lambda, S3 e DynamoBD são incrivelmente resilientes e rápidos. Ao descarregar o trabalho pesado indiferenciado, podemos gastar mais tempo criando recursos para os usuários, em vez de trabalhar na configuração de infraestrutura genérica.

Um princípio-chave em G-P é: "Você constrói, você executa." Nossas equipes possuem seus softwares. Então, não jogamos software na parede para uma equipe de DevOps. 

Benefícios do “sem servidor em primeiro lugar”

O Serverless é inerentemente orientado por eventos.

Nossa arquitetura é totalmente orientada a eventos. Ao usar a arquitetura orientada a eventos (Event-Driven Architecture, EDA), podemos dimensionar nossa organização e nosso software. O Serverless nos força a manter um pequeno raio de explosão e a nos comunicarmos de maneira totalmente nativa da nuvem por meio de eventos.

Habilitar restrições

Como global employment platform , levamos a conformidade a sério. Nossa infraestrutura de nuvem é bem arquitetada e usamos uma estratégia de várias contas que separa cargas de trabalho e automatiza a conformidade com a nuvem. O Serverless nos ajuda a impor altos padrões controlando como provisionamos recursos de nuvem.

Descarregar o trabalho

Nosso provedor de nuvem gerencia nossos serviços serverless. Um único conjunto de blocos de construção — integrados, seguros, ajustados, habilitados e mantidos pela AWS — nos libera para focar mais na cadeia de valor para os clientes.

Cargas de trabalho bem arquitetadas

Cada carga de trabalho que criamos é revisada com o AWS Well-Architected Framework. Nós nos concentramos em escala, segurança, confiabilidade e otimização de custos para garantir que não apenas atendamos, mas também excedamos nosso SLA (Contrato de Nível de Serviço). Isso capacita nossas equipes de engenharia à medida que continuamos a evoluir com ambientes em nuvem. 

Sobre nossas equipes

Nossa estratégia de tecnologia é ambiciosa e isso a torna desafiadora. Muitos engenheiros não trabalharam em uma arquitetura sem servidor (ou em uma arquitetura distribuída). A transição para a arquitetura serverless não é fácil, e procuramos engenheiros que se sintam confortáveis em aprender, pensar grande e se mover no ritmo.

Alguns engenheiros não têm certeza sobre o termo serverless (sim, sabemos que há servidores) porque a abordagem é mais do que escrever código em funções. Nossa estratégia exige uma abordagem holística para os princípios clássicos nativos da nuvem.

O resultado

Fizemos progressos extraordinários em dois anos. Há muitos benefícios da modernização (consulte nosso artigo sobre AWS/valor de negócios conhecido da modernização da nuvem). Especificamente, observamos o seguinte:

1. Velocidade: a maneira como dividimos nosso sistema permite que equipes e produtos inovem e evoluam de forma independente. Isso tem um impacto enorme na agilidade dos negócios.

2. Conformidade: Usamos o AWS Well-Architected Framework para revisar todas as cargas de trabalho. Como usamos muitos serviços gerenciados da AWS, podemos confiar em sua excelência operacional e começar de um lugar de alta qualidade.

3. Pensamento do sistema: tivemos que padronizar muitos dos nossos processos para que pudéssemos pensar sobre o sistema, a confiabilidade e o valor do negócio. Não gastamos tempo trabalhando em componentes de baixo valor.

4. Inovação: Serverless significa que tudo é uma API. Essa restrição forçada requer uma abordagem de API em primeiro lugar. Quando pensamos em nós mesmos como uma plataforma, podemos alcançar um novo nível de inovação conectando facilmente sistemas via APIs, como conectar G-P Gia™ a uma nova base de conhecimento.

5. Propriedade: a AWS é proprietária de nossa infraestrutura, mas somos proprietários de nosso domínio de negócios. O Serverless-first com design orientado por domínio nos forçou a focar no problema de negócios. Isso mantém clara a propriedade da capacidade.

O Serverless-first nem sempre é mais rápido, mas é mais benéfico. Preferimos otimizar a velocidade do sistema do que a velocidade do desenvolvedor individual. O Serverless-first é menos sobre usar funções e mais sobre pensar: “O código é uma responsabilidade. O sistema é o ativo.” Quanto menos código tivermos que escrever, mais poderemos considerar e moldar o sistema de negócios que estamos construindo.

À medida que compartilhamos nossa história, isso se tornará óbvio na velocidade em que estamos trabalhando, que é um resultado direto do serverless-first. Fique atento.