Amazon Web Services: Serverless Architecture

Introdução

Sou arquiteto de soluções há alguns anos. Iniciei minha carreira como desenvolvedor e nunca, nesses 20 anos de experiência, abri mão de desenvolver minhas aplicações, scripts, automações, ... Fui Arquiteto de Software por um tempo. Também já tive oportunidade de ser sysadmin administrando milhares de instâncias de Web e Application Servers, bem como produtos de integração, SOA, entre outros. Por 3 anos fui Coordenador de Segurança da infraestrutura web da IBM e de alguns de seus clientes. Como se não bastasse, fui responsável por dar suporte a desenvolvedores a melhor utilizar recursos nos servidores, adotando boas práticas e padrões corporativos e de segurança.

Por conta da diversidade de áreas e desafios que cada uma me apresentou, durante esses anos, posso afirmar, com segurança, que Serverless Architecture é uma das maiores quebras de paradigma desse mundo DevOps dos últimos, pelo menos, 10 anos.

Para explicar melhor o porquê dessa afirmação, cabe observar como chegamos até aqui sob perspectivas de quem projeta, de quem desenvolve e daqueles que administram a infraestrutura necessária para disponibilizar as aplicações aos usuários.

The Road so far

Por questões de simplificação, vou considerar apenas a época pós-internet.

Data Centers Tradicionais

Estamos no final da década de 90. Um arquiteto de soluções recebe a incumbência de projetar um novo web site, simples, mas que precisa estar no ar 24 x 7. Infelizmente, o seu data center não têm mais servidores disponíveis. Vira para o project manager e joga essa bomba no colo dele. Dependendo da empresa, esse processo poderia levar semanas, meses até.

Virtualização

Estamos agora no século XXI, digamos, 2005, essa mesma requisição chega a um outro arquiteto de soluções. Agora já está disponível a facilidade da virtualização. Infelizmente ainda há necessidade de saber se há storage, subnet, endereços IPv4 (nem sempre disponíveis) e mais uma série de outros recursos físicos disponíveis. Não podemos esquecer da lista de profissionais para preparar tudo isso. Entre eles, especialistas em sistemas operacionais, bancos de dados, middleware e por aí vai. Mais uma vez, missão inglória para o gerente de projetos. Quanto tempo até isso tudo estar disponível? 3 meses, 6 meses?

Opa! Precisamos de ambiente de desenvolvimento, ambiente de teste, homologação. Coloca mais uns meses no prazo. Quanto custa isso tudo? O fato de ter pedido um servidor já inicia a tarifação e ela só acaba depois que, formalmente, desligamos/liberamos os recursos todos.

Cloud Computing - Infrastructure as a Service (IaaS)

Finalmente, chegamos ao mundo ideal! (Será?) IaaS. Alguns cliques e temos nossas máquinas disponíveis. Mas e quanto aos profissionais? Mesmo problema. Além disso, o Project Manager, coitado, precisa saber da equipe de desenvolvimento o que mais precisa ser feito. O líder prepara uma lista de tarefas para configurar as máquinas de desenvolvedores, configurar servidores web, de aplicação, criar databases, etc etc etc.  

Parece que ainda há bastante para melhorar. Pelo menos agora já se pensa orientado a serviços (SOA). Aplicações começam a se integrar por serviços, reutilização é palavra de ordem, definir qualidade de serviço e mais uma série de outras conquistas.

Containers e Microservices

E se fosse possível ter todas essas configurações pré instaladas? Com apenas um comando, uma combinação de produtos já estariam disponíveis para uso. Foi assim que surgiu a cultura dos contêineres que ficou muito conhecida através do Docker, principalmente a partir de 2014. Rapidamente as plataformas de cloud introduziram esse serviço de disponibilizar contêineres.

O surgimento dos containers ajudou a consolidar uma variante, ou como alguns preferem, uma especialização da SOA: Microservices. Em resumo, as aplicações tradicionais, monolíticas continham todo o código dentro delas. Essa abordagem gerava inúmeras dificuldades, entre elas a manutenção e reutilização de código. Surgiu então a Services Oriented Architecture. Onde, em vez de uma única aplicação, pedaços eram divididos semanticamente em Serviços.

O sucesso dessa abordagem estimulou empresas como a Netflix, por exemplo, a adotar algo ainda mais arrojado. Dividir os serviços em micro partes, independentes umas das outras, no sentido de dependência para releases. Um exemplo, hipotético, na Americanas.com seria dividir recomendações de compra, carrinho de compras, controle de estoque, etc. Em pequenos pedaços de código. Funções (daí o caso de alguns chamarem de FaaS - Function as a Service).

Realmente, é preciso reconhecer o valor desse modelo de arquitetura. Um projeto que consegue adotar todas essas boas práticas e treinar sua equipe para usar as tecnologias envolvidas, vai, com certeza, ter retornos consideráveis. Integrando ferramentas DevOps conseguirão atingir uma agilidade incrível.

Infelizmente, ainda restaram algumas arestas para aparar. Os dockers precisam ser "orquestrados", administrados por um especialista. Ainda precisamos nos preocupar com problemas nos softwares rodando neles. Application Servers, Web Servers, Database Servers, sysadmins, DBAs, backups. Outra questão muito relevante é com relação ao custo. O momento em que ligamos um container, a tarifação começa. Seu preço pode variar de acordo com provisionamento de storage e memória. Vários ambientes, vários dockers, muitos dólares.

Serverless Architecture

A tradução literal (arquitetura sem servidores) simplifica bastante essa oferta fantástica de cloud computing. Não é que não tenhamos mais servidores. Em algum lugar existe um mecanismo que usa um servidor. Isso é evidente. O que não precisamos mais é nos preocupar com servidores e por consequencia, não precisamos nos preocupar com uma série de outras questões. Quem vai administrar? Quem vai lidar com patches de segurança? Quem vai fazer backup do banco de dados? Não sei. Não me importo. O que me importo é com o código Java, Node.js, Python, C#... Onde ele vai rodar? Também não me importa.

Lembra do Project Manager? Será que ele vai ficar feliz em saber que o projeto começa imediatamente? Mas calma, essa tecnologia super avançada deve custar uma fortuna! Aha! Aí é que vem a cartada final. Você não paga nada até que comece a usar. E se usar. Se as Lambda Functions de homologação só forem usadas uma vez a cada final de sprint, só será pago o tempo em que elas estiverem executando. Isso vale para qualquer outra separação lógica que se faça necessária. Aliás, falando nisso, quantas versões você pode ter de uma mesma função? Quantas você achar que consegue gerenciar. Backwards compatibility, te apresento seu melhor amigo.

Isso significa que preciso mudar a maneira de pensar nos microservices? Mil vezes não. Esse modelo é perfeito para quem quer adotar essa estratégia de desenho. João, e meu job na crontab? Cria uma lambda function para ele. E se eu precisar saber quando um arquivo de um fornecedor chegou no meu servidor de arquivos? Ative um evento que dispara uma Lambda Function. As possibilidades são inúmeras.

Vários serviços da plataforma da AWS se integram perfeitamente a AWS Lambda Functions.

Se ainda tem alguma dúvida. Vou desenhar pra você:

O que eu faço agora?

Bom. Isso é exatamente o que precisa ser feito. Se perguntar onde foi que você se perdeu no tempo. Absorver todas essas informações ainda vai levar tempo para profissionais e empresas. Se você já faz parte desse mundo, sabe que o momento é de transformações significativas e a Amazon Web Services tem liderado muito dessas iniciativas. Sugiro a todos que considerem se especializar nessa plataforma fantástica.

Em um próximo artigo vou mostrar na prática como publicar um web site utilizando princípios de serverless architecture utilizando o que há de melhor na AWS. Fique ligado.