Em diversos momentos da carreira, Phil Calçado trabalhou na transição de monolitos para a arquitetura de microservices mas, recentemente, o maior desafio tem sido a migração para o serverless. Em uma recente apresentação na QCon de Nova York, Calçado falou sobre sua experiência combinando o conceito de serverless com microservices.
Calçado, que já trabalhou no Meetup, no SoundCloud e, atualmente, está trabalhando na SeatGeek, iniciou definindo microservices como uma arquitetura para aplicações altamente distribuídas, colocando uma ênfase em aplicações distribuídas com o foco na lógica de negócio, em contraste com o termo mais comumente utilizado, sistemas distribuídos, no qual acredita que há muito foco em questões relacionadas à infraestrutura.
De uma perspectiva de microservices, Calçado acha difícil definir serverless e nota que existem muitas definições diferentes, então se refere ao livro What is Serverless? escrito por Mike Roberts e John Chapin, ambos da Symphonia. Uma característica distinta do serverless, apontada por Calçado, é que não há uma conexão direta entre o código e o conceito de serviço, o que significa que não é necessário pensar em CPU, memória e outros requisitos de infraestrutura.
O Meetup é uma das startups originadas de Nova York e é basicamente uma grande aplicação monolita rodando na JVM, que é difícil de se trabalhar. Em uma tentativa em direção ao serverless, eles iniciaram um projeto focando em um novo design assíncrono, baseado em eventos. No novo design, eventos são criados a partir de alterações no banco de dados feitas no monolito e estes eventos são então persistidos e processados por funções lambda e, enfim, armazenados com visões específicas (projeções CQRS) necessárias ao negócio.
O projeto não foi muito bem sucedido e tiveram que reverter as alterações e voltar a utilizar uma API. Um problema que ocorria frequentemente era que ao resolver um bug também era necessário reprocessar todos os dados, pois a mudança no código poderia significar uma alteração na lógica e acarretar em dados incorretos nas views. Outro problema era como gerenciar as escritas de volta ao monolito. Isto era realmente complicado, então tomaram uma decisão pragmática e utilizaram o código legado como API para escritas. Mas essa solução levantou a questão se todo este trabalho com eventos e lambdas ao ler os dados era realmente necessário. O maior problema, entretanto, foi a falta de governança pois não tinham o controle de ownership, onde ocorriam os deploys das funções, quais estavam em produção, além de outros problemas similares.
Calçado observa que, apesar de tudo, algumas coisas funcionavam melhor do que o esperado. Tornar novos engenheiros produtivos ocorria mais rápido que o esperado. Quando os times de engenharia eram donos e, ao mesmo tempo, operavam os deploys as coisas funcionavam muito melhor do que as experiências anteriores, Calçado acredita que uma das razões para isso era o tamanho menor dos lambdas, o que tornava muito mais fácil o controle de todo o processo. A satisfação dos desenvolvedores também era mais alta que o esperado.
Um problema que Calçado vê no serverless é que, em contrapartida aos microservices onde há um número limitado de pequenos serviços, as funcionalidades são divididas em um número alto de funções. Frequentemente essas funções também se comunicam umas com as outras, em alguma forma de rede peer-to-peer, o que faz com que seja difícil saber o que está acontecendo. Calçado faz referência a um tweet de Chris Ford que diz:
Arquitetura de máquinas de pinball.
Para evitar esse tipo de arquitetura, Calçado cita Martin Fowler e seu artigo de 2002: Interfaces Públicas versus Interfaces Publicadas. Embora existam interfaces que são públicas, elas não deveriam ser utilizadas. O provedor de uma biblioteca ou algum tipo de software similar deveria prover uma interface publicada, que é a única que deveria ser utilizada. Com base nisso, Calçado e sua equipe separaram todas as funções em grupos com um API gateway na frente de cada grupo, e os gateways eram as únicas formas de acessar as funções. Calçado admite que isso é como criar serviços com funções como unidade de processamento, utilizando o serverless como unidade de construção de microservices.
Calçado observa que no Meetup utilizavam uma abordagem 100% AWS, mas mesmo desenvolvendo tudo na Amazon ainda tinham cerca de 10% dos times de engenharia dedicados a ferramentas e plataformas. Ainda há muito para se resolver com coisas que não se comunicam uma com a outra e outros problemas similares.
Quando se olha o que foi alcançado, Calçado não tem certeza se o resultado é realmente serverless, mas mostra que o importante é que foi possível caminhar de uma grande aplicação legada e complicada em direção a um mundo de computação serverless. Ele observa também que embora o serverless pareça ser o futuro, ainda não estamos nele. Mas com ferramentas melhores, Calçado acredita que esse é o caminho a seguir.
A apresentação do Calçado foi gravada e será publicada no fim de Setembro no InfoQ.