Estivemos essa semana na PHP Experience, um evento que nos surpreendeu muito positivamente, principalmente pela qualidade das palestras e formato. Com um primeiro dia para tutorias, uma noite para os keynotes, e um terceiro e último dia para 3 trilhas temáticas, e recheadas com assuntos bem pertinentes, úteis não apenas para quem trabalha com PHP, mas como para qualquer desenvolvedor. Como por exemplo, sobre Big Data e Programação Orientada a Aspectos.
Vamos aqui, contar um pouco sobre como foram dois keynotes, que o nosso time gostou bastante.
Leveraging a distributed architecture to your advantage
A noite da segunda-feira começou com o keynote do Michelangelo van Dam, sobre como uma arquitetura distribuída pode te ajudar. O começo foi recheado de conceitos, desde uma explicação rápida sobre LAMP, até um passo-a-passo de como geralmente escalamos a aplicação, chegando até a arquitetura de micro-serviços.
Mas o ponto central do keynote não era micro-serviços, e sim alta-disponibilidade. Para muitos alta-disponibilidade gera custos desnecessários, afinal se a AWS cair por exemplo, vários outros serviços grandes irão juntos, e o seu será só mais um. Porém quando falamos de serviços para o mercado financeiro, transporte e saúde, a alta disponibilidade é essencial, se a AWS cair, uma outra região, ou até outra cloud terá que assumir. E esse foi o ponto principal do palestrante, que tem uma vasta experiência, pela sua empresa prestar esse tipo de serviço.
Sua recomendação para alta disponibilidade é ter sempre uma outra cloud pronta pra assumir, caso a primeira caia. Em vários casos que AWS caiu, outras regiões também tiveram seus serviços impactados, e no histórico de quedas, quando a AWS cai, a Azure está de pé, e vice-versa. Portanto utilizar ambas, é uma estratégia boa, tanto que é o que eles recomendam para os seus clientes.
Alguns outros pontos importantes pra que isso seja possível são:
prepare o seu código e arquitetura para serem distribuídos e escalarem;
de nada adianta ter backups, se você nunca testa eles. Faça simulações de desastres, inclusive a Netflix tem uma ferramenta para isso;
automatize o seu processo de deploy (na Vizir por exemplo, usamos o Terraform).
Event Sourcing: the good, the bad and the complicated
Keynote feito pelo italiano, que vive na Alemanha, Marco Pivetta. Abordou um assunto não tão trivial, e que muita gente não tinha conhecimento, inclusive nós, que é o Event Sourcing.
A primeira coisa a ser ter em mente, é que Event Sourcing não é algo pra ser aplicado a torto e a direita, precisam existir motivos fortes para a sua aplicação. Isso deve-se a complexidade que ele traz. O principal motivo é para lidar com serviços externos, afinal você não tem controle sobre eles. Usando Event Sourcing você tem todos os eventos do sistema armazenados, geralmente numa fila (ex: AWS SQS e RabbitMQ), e um worker, que em caso de falha, consegue reprocessar o evento.
Até agora nos parece que estamos falando apenas de processamento assíncrono, certo? Algo que muitos de nós fazemos, como por exemplo, ao enviar um e-mail de confirmação de uma compra. Bem, a aplicação de Event Sourcing, vai um pouco além dos recursos externos, ela envolve o código da sua camada de negócio também.
Alguns conceitos o Marco trouxe para criar a sua aplicação usando eventos:
Aggregate Root: é o ponto central que você irá chamar para disparar os eventos, agregando todos os eventos gerados por terminada operação. Exemplo, o fechamento de um pedido, irá disparar eventos como: salvar o pedido no banco de dados, integrar com o ERP, enviar email, etc. Quem chama o “agregador” é a sua camada de aplicação, aliás, aqui cabe um ponto importante, lembra que falei que os eventos são atômicos? Portanto, toda validação necessária, algo que geralmente não é atômico, tem que ser feita antes da criação dos eventos, por muitas vezes não serem atômicas, por poderem alterar o estado a ser salvo;
Projetors: uma vez que um evento é criado, um projector irá produzir o estado daquele evento. Geralmente, ele que irá persistir o evento numa tabela, arquivo, fila, etc;
Event handles: são os responsáveis por processar o efeito colateral de um evento.
Como você pode perceber, são vários conceitos novos, e isso que estou apenas resumindo o que o Marco passou no keynote. Por isso, se você ficou interessado, e quer entender melhor como implementar Event Sourcing, recomendo fortemente a sua apresentação (não sei se o pessoal do PHP Experience irá liberar as talks – acho que sim, porquê estavam gravando, mas se quiserem já ver a apresentação do Marco, ela a deu na Web Camp 2016).
….
Bem é isso. Como dissemos no começo, o evento foi muito bom, mesmo com alguns problemas na hora do coffee break e coquetel, onde se percebeu que o espaço e quantidade de comida, não foram bem dimensionados para a quantidade de pessoas que estavam lá. O conteúdo prevaleceu, e é o que sempre deve prevalecer, e tanto os keynotes, como as palestras das trilhas foram e sua maioria de excelente nível e bem pertinentes, tanto que várias salas estavam lotadas.
Parabéns a todos envolvidos! Em 2018 pretendemos voltar!
