DEV Community: Leonardo Lemos

Imagem Docker. Para rodar projetos PHP em menos de 30 segundos.

Leonardo Lemos — Tue, 06 Jan 2026 15:02:25 +0000

Release da imagem PHP Full da Convenia, com PHP 8.5

Nesta semana, lançamos a versão 8.5 da nossa imagem Docker para aplicações PHP, agora com PHP 8.5 e nesse post vamos falar um pouco de como utilizar essa imagem.

Na Convenia, a maior HR Tech do Brasil, utilizamos essa imagem de forma padronizada em todos os nossos projetos. Isso significa que qualquer desenvolvedor da equipe sabe exatamente como iniciar, testar e implantar aplicações sem surpresas no ambiente — seja em desenvolvimento, homologação ou produção. Nesse post abordamos todas as vantagens de padronizar a forma de executar aplicações

Essa imagem está disponível desde a versão 8.1, sendo amplamente testada e utilizada em produção em centenas de projetos e pipelines da Convenia e já acumula mais de 10K de pulls no Docker Hub.

O que é a imagem Docker PHP Full?

A imagem Docker PHP Full é um ambiente containerizado que já contém tudo o que aplicações PHP precisam para rodar com segurança e desempenho:

PHP pré-configurado com versões modernas
Servidor web integrado
Ferramentas úteis como Composer, cron e extensões comuns
Testes de integridade e atualizações regulares

A Convenia mantém esse padrão há diversas versões — do PHP 8.1 até o novo 8.5 — garantindo estabilidade e suporte contínuo para todos os projetos da empresa.

Como usar a imagem

Instalação

Para começar com a imagem PHP Full da Convenia, basta usar o Docker ou Docker Compose.

Usando Docker

docker run --rm -p 80:80 convenia/php-full:8.5

Ao acessar o seu localhost será possível ver uma documentação similar a essa

Essa página é a própria documentação da imagem sendo servida pelo PHP + nginx. No proximo exemplo com o docker compose vemos como executar a nossa aplicação dentro da imagem, é só montar um volume ou copiar a aplicação para o diretório /var/www/app dentro do container.

Usando com Docker Compose

Crie um arquivo docker-compose.yml na raiz do seu projeto:

services:
  app:
    image: convenia/php-full:8.5
    container_name: app
    volumes:
      - .:/var/www/app
    ports:
      - "80:80"

Depois, execute:

docker-compose up -d

Esse arquivo pode ser colocado na raiz de um projeto Laravel por exemplo, e ao subir a stack do compose o projeto já deve executar sem maiores problemas.

Na verdade é possível colocar esse arquivo em qualquer aplicação PHP que tenha a pasta public como entrypoint do request, aplicações Symfony, Laravel. Se o entrypoint for na raiz apenas acrescente a pasta public ao montar o volume:

    volumes:
      - .:/var/www/app/public

Atualizações automáticas

A imagem é construída e atualizada semanalmente para garantir o uso de versões seguras e livres de vulnerabilidades conhecidas, com escaneamento contínuo de dependências. O último build pode ser consultado no workflow do Github Actions

Segurança

O serviço FPM (porta 9000) é exposto apenas internamente no container
É recomendado bloquear a porta 9000 em ambientes externos
A imagem já vem com as configurações de segurança recomendadas para produção. Como desabilitar mensagens de erros e afins.

Exemplos de customização

Substituir configuração do Nginx

Você pode substituir a configuração padrão do servidor web:

services:
  app:
    image: convenia/php-full:8.5
    volumes:
      - ./nginx.conf:/etc/nginx/http.d/default.conf

Assim adapta o container às regras específicas do seu projeto.

Tarefas agendadas com cron

A imagem já inclui o binário cron, facilitando tarefas agendadas:

Adicione um arquivo crontab com os comandos desejados;
Copie para o container:

COPY crontab /etc/crontabs/root

Inicie cron no container:

docker run --rm mycronimage crond -l 2 -f

Isso facilita execução de comandos como o scheduler do Laravel.

Conclusão

Seguem uma listinha com as vantagens da utilização dessa imagem em projetos PHP:

Consistência entre ambientes
Facilidade de uso
Atualizações contínuas
Padrão único para toda a empresa

Spot By NetApp análise da utilização do Elasticgroup na Convenia

Leonardo Lemos — Fri, 26 May 2023 20:24:37 +0000

Nesse post tenho como objetivo contar um pouco de como está sendo a utilização da Spot by NetApp. Importante analisar que a Spot tem um monte de produtos voltados para cloud, nesse post vou analisar apenas o Elasticgroup que é o produto da Spot voltado para gerenciar as instâncias EC2, similar ao AutoScalingGroup(ASG) da AWS.

OBS: Sempre que me referir a "Spot" com inicial maiúscula estou me referindo à empresa SpotByNetapp e sempre que eu me referir a "spot" com inicial minúscula estou me referindo ao tipo de instancia spot da AWS

Na Convenia já utilizávamos instâncias spot para todo serviço que não fossem crítico e admitissem interrupções. No mês da black friday utilizamos exclusivamente instâncias “On Demand” para evitar interrupções massivas devido ao esgotamento da oferta spot, esse foi o resultado:

No gráfico acima existe um spike de custo em dezembro causado pela utilização das instancias "On Demand". Após analisar o custo fizemos uma reunião de post mortem e decidimos avaliar o Elasticgroup da Spot que promete fallback para “on demand” caso a oferta spot se esgote.

De inicio posso dizer que gostamos de resultado final e passamos todos as instâncias para serem gerenciadas pelo Elasticgroup.

Como foi a integração??

Sempre que precisamos testar qualquer coisa dentro da Convenia fazemos uma POC com algum serviço interno para entender realmente os pontos negativos e positivos, e foi isso que fizemos.

O primeiro passo para integração é fazer a ligação da conta da Spot com a sua conta da AWS seguindo o passo a passo na própria documentação da Spot, esse passo apesar de muito bem explicado contém algumas etapas, caso haja dúvida na implantação ou mesmo em relação as possibilidades que a Spot pode trazer sugiro uma conversa com o pessoal da RealCloud que nos ajudou bastante a entender os produtos da spot e entender como fazer essa migração.

Após linkar a conta da AWS com a Spot seguimos um wizard que importa as configurações do AutoScalingGroup da aws para um Elasticgroup dentro da spot. Apenas isso foi necessário para ter as instancias sendo gerenciadas pela Spot, após a criação do Elastic group podemos inativar o nosso AutoScalingGroup(setando a capacidade desejada, mínima e máxima para 0) ou mesmo remove-lo.

No nosso caso, fazer essa migração para o primeiro serviço durou cerca de uma hora. Continuamos monitorando para ver como o Elasticgroup faria as trocas de instancias para conseguir mais saving e fizemos mais alguns testes para forçar refresh de instancias e interrupções para entender como ele lida com isso, na nossa experiência não tivemos nem uma surpresa, simplesmente não perde em nada para o ASG da AWS, ainda tem algumas funcionalidades a mais como vou falar mais para frente.

Um outro ponto importante que vale ressaltar durante a integração é que a RealCloud nos acompanhou durante todo o processo, e o billing começou a rodar apenas após a integração de todos os serviços.

Quais as vantagens da adoção da Spot?

A resposta lógica para essa pergunta seria custo mas vou começar falando das coisas que não tem haver com custo, o custo vamos analisar mais profundamente no próximo tópico, então seguem as outras vantagens:

Fallback para “On Demand”: Esse é um dos principais motivadores para a adoção na minha opinião, é muito difícil prever a oferta spot com eficiência, a AWS promete avisar sobre interrupções com 2 minutos de antecedência, dessa forma é possível construir automações para lidar com a interrupção mas eu particularmente não gosto de lidar com isso artesanalmente. O que acabamos fazendo é manter as instancias mais críticas com “On Demand”. Poder confiar que o Elasticgroup vai fazer o fallback corretamente te permite spotizar até as instancias mais críticas e evita que você faça a loucura de voltar todas as instancias para “On Demand” nas vesperas de uma black friday causando aquele spike de custo mostrado no inicio.

Abaixo os logs do Elasticgroup fazendo a substituição de instancias spot pot "On Demand":

5/21/2023, 5:30 AM, INFO, Updating group
5/21/2023, 5:30 AM, INFO, Falling back to on-demand, no spot instances could be launched.
5/21/2023, 5:30 AM, INFO, Scheduling action: [scale] ( , scaleTargetCapacity: 5 , scaleMinCapacity: 5 , scaleMaxCapacity: 8)
5/21/2023, 5:30 AM, INFO, Instances: [i-01b3bc7d84018f540,i-0762fba5e0348ef70,i-0d204f6f3e1b6a9a5,i-04182456095d6e21d] have been launched. Reason: Group update
5/21/2023, 5:30 AM, INFO, Updating Group Succeed
5/21/2023, 5:31 AM, INFO, Instance [i-0d204f6f3e1b6a9a5,i-01b3bc7d84018f540,i-04182456095d6e21d,i-0762fba5e0348ef70] successfully registered to load balancer: rh-live-core-84
5/21/2023, 5:31 AM, INFO, Instance [i-0d204f6f3e1b6a9a5,i-01b3bc7d84018f540,i-04182456095d6e21d,i-0762fba5e0348ef70] successfully registered to load balancer: rh-live-internal-core-84

Scheduled scalling: O Elasticgroup nos permite definir alguns schedulers no formato de cron para escalar as maquinas em determinados horários. Na Convenia deixamos no mínimo duas instancias rodando para os serviços principais durante o dia e por ser um sistema muito focado no publico brasileiro, o tráfego cai bastante durante a noite, nesse caso podemos configurar esse scheduler para desligar as instancias redundantes pela madrugada, trazendo um saving ainda maior

Simplicidade na organização de recursos: Para manter práticas do CodeReview e manter uma padronização mínima dos serviços utilizamos o terraform. Geralmente ao criar o autoscaling dentro da AWS acabamos criando uma serie de recursos avulsos, como scaling policies, asg attachments entre outros. Ao adicionar o recurso de Elasticgroup no nosso terraform notamos uma boa simplificação visto que o Elasticgroup é um único recursão que aglomera todas as funcionalidades, no final trocamos diversos recursos do terraform por apenas um.

Abaixo um exemplo real de um Elasticgroup criado pelo terraform na Convenia:

resource "spotinst_elastigroup_aws" "core_webserver_live_asg" {
  name = "core_webserver_live_asg"
  spot_percentage = 100
  orientation = "balanced"
  draining_timeout = 120
  fallback_to_ondemand = true
  desired_capacity = 5
  min_size = 5
  max_size = 8
  capacity_unit = "instance"

  scaling_target_policy {
    policy_name = "CPU track scaling"
    namespace = "AWS/EC2"
    metric_name = "CPUUtilization"
    statistic = "average"
    unit = "percent"
    target = 70
    cooldown = 120
  }

  instance_types_ondemand = "t3.small"
  instance_types_spot = [
    "t3.small",
    "t3a.small",
  ]

  subnet_ids = [var.subnet_1, var.subnet_2, var.subnet_3, var.subnet_4]
  product = "Linux/UNIX"

  target_group_arns = [
    aws_alb_target_group.core_live_target_group.arn,
    aws_alb_target_group.core_internal_live_target_group.arn
  ]

  security_groups = [aws_security_group.core_instance.id]
  enable_monitoring = false
  ebs_optimized = false
  image_id = data.vault_generic_secret.swarm_base_image.data["image_id"]
  ebs_block_device {
    device_name = "/dev/sda1"
    delete_on_termination = true
    volume_size = "32"
    volume_type = "gp3"
  }

  user_data = base64encode(templatefile("user_data.sh", {swarm_token = var.swarm_token}))

  tags {
    key = "Workload"
    value = "live-core"
  }

  tags {
    key = "Name"
    value = "live-core-webserver-elasticgroup"
  }

  iam_instance_profile = "my-super-secret-policy arn"
  health_check_type = "TARGET_GROUP"
  health_check_grace_period = 300

  scheduled_task {
    is_enabled = true
    task_type = "scale"
    cron_expression = "0 23 * * *"
    scale_target_capacity = 1
    scale_min_capacity = 1
    scale_max_capacity = 3
  }

  scheduled_task {
    is_enabled = true
    task_type = "scale"
    cron_expression = "30 8 * * *"
    scale_target_capacity = 5
    scale_min_capacity = 5
    scale_max_capacity = 8
  }

  region = "us-east-1"

  lifecycle {
    ignore_changes = [
      desired_capacity,
    ]
  }
}

Custo sobre o saving: Talvez esse seja uma dos principais atrativos na venda dos serviços pela Spot, o modelo de billing da Spot é sobre o seu saving logo não existe a possibilidade de você pagar por algo que você não vai ter, retorno garantido! Se seu billing não diminui você não paga nada.

Esses foram algumas das vantagens que notamos nessa migração mas confesso que a Convenia não utiliza todo o poder da Spot, ainda existe possibilidade para spotizar instancias statefull entre outras coisas, independente do seu case acho difícil acreditar que a Spot não tem alguma solução que possa trazer algum tipo de saving, quanto maior o seu sistema(em quantidade de maquinas) mais passa a fazer sentido essa adoção.

Mas e o Custo??

O principal motivador para a adoção da Spot é redução de custos, essa é a bandeira deles! A Convenia tem uma infra relativamente pequena e para quantificar esse saving adequadamente precisamos nos atentar a alguns detalhes.

Como mostrado no gráfico de billing acima, que contém apenas custo “On Demand e Spot”, em setembro de 2022 e abril de 2023 o custo permanece mais ou menos no mesmo patamar, isso é bom pois nesses últimos meses nossa infra cresceu um pouco, spotizar as instancias críticas que antes não eram spot nos permitiu esse resultado.

A spot tem um custo sobre o saving: nossa conta da spot varia em torno de 130 Bidens. Quando adicionamos esse custo ao valor mensal mostrado no billing da aws notamos que a conta de abril de 2023 supera um pouco a conta de setembro de 2022, isso se deve ao crescimento da nossa infra nesses meses mas mesmo sem esse crescimento não acredito que o saving teria sido expressivo a ponto de justificar a adoção da Spot apenas por custo. Importante notar que quanto maior for a sua infra maior é a justificativa para a adoção, talvez a Convenia não tenha tido resultados tão expressivos pelo tamanho da infra e pelo fato de já utilizar Instancias spot para alguns serviços, claro que o saving poderia ser ainda maior se spotizarmos as instancias statfull que temos.

Nosso total de desconto devido a instancias spot ficavam em torno de 65%, a taxa de Spot é de 28% sobre esse saving de 65 mas o que ninguem conta é que para uma empresa brasileira utilizando a Spot teremos algumas impostos que somados com a taxa da Spot podem arranhar os 40% desse saving.

Outra detalhe muito importante que é radicalmente negligenciado é o custo da mão de obra, por mais que a integração seja simples, trocar os ASGs massivamente pelo Elasticgroup exige uma validação mínima além de um acompanhamento para ver se está funcionando como previsto e se está atingindo o saving previsto, no fim o time vai morrer com alguns dias em cima dessa integração e mão de obra é caro!

Conclusão

No final, analisando o conjunto de vantagens e desvantagens julgo como positiva a utilização da Spot, se tivesse que julgar apenas a redução de custo com computing já não faria tanto sentido, mas ter um fallback para “on demand” automático, simples e confiável é a maior das vantagens para min, visto que não vamos ver spikes de custo nas épocas de black friday, o que já compensaria o preço pago pelo serviço da spot.

Essa conclusão de custo é muito particular da Convenia que tem uma infra relativamente pequena e já era bem espotizada antes. Conforme o crescimento da empresa acredito que o saving proporcionado passa a ser cada vez mais relevante. No aws summit de 2022 o Nubank mostrou um pouco do case deles de utilização da Spot, com o volume deles a spotização pode trazer um valor absurdo de custos, pra quem quiser ver esse case mais de perto só ver aqui no youtube

Mongo Atlas, porque utilizar o recurso de VPC Peering no seu cluster?

Leonardo Lemos — Thu, 29 Dec 2022 12:39:52 +0000

Nesse post quero compartilhar uma dica bem valiosa que adotamos na Convenia. Nossa stack é composta de microserviços e utilizamos extensamente MongoDB e RabbitMQ, esse último para comunicação entre os serviços, como mostrado nesse post.

Toda infra da Convenia roda dentro da AWS e a AWS não tem uma boa opção gerenciada de MongoDB ou RabbitMQ, então utilizamos o Mongo Atlas e o CloudAmqp para aliviar o trabalho de manutenção nesses serviços.

Problemas

Vamos tomar como exemplo a comunicação entre o serviço gerenciado do Mongo Atlas e a nossa aplicação, após provisionar tudo da maneira mais simples devemos chegar a essa arquitetura:

Na verdade isso funciona relativamente bem, a aplicação funcionaria de maneira aceitável no entando parece um caminho longo da nossa aplicação(API) até o banco de dados o que não é o ideal, na verdade o banco de dados deve ficar o mais "perto" possível da nossa aplicação, na arquitetura acima eu consigo pontuar alguns problemas:

Custo: o NAT gateway faz parte de toda arquitetura de rede que inclui uma subnet privada, a grosso modo ele é responsável por prover acesso à internet aos componentes internos da rede. O gande problema é que esse NAT é um elemento caro na infraestrutura pois tem um custo apenas por existir(pois tem ip público) e também cobra um custo relativo ao tráfego que passa por ele. No nosso caso os dados da nossa aplicação estão passando por ele para chegar ao MongoDB, o mesmo não aconteceria se o banco estivesse dentro da mesma subnet da aplicação, nesse caso a aplicação conseguiria conversar diretamente com o banco.
Performance: Claro, sair pelo internet gateway para internet e passar "sei la por onde" até chegar no nosso banco de dados vai introduzir um pouco de latência e naturalmente diminuir a resiliência da aplicação, o mesmo não aconteceria com um banco na mesma subnet da nossa aplicação.
Segurança: De todos os pontos, este é o item mais preocupante, principalmente no caso da Convenia que trafega dados pessoais em época de LGPD. A conexão entre a aplicação e os serviços externos é criptografada, isso significa que é relativamente segura pois mesmo se o tráfego for interceptado os dados não podem ser acessados. Mas mesmo com a criptografia é desconcertante ter o tráfego suscetível a um ataque, seria melhor se esses dados nem passassem pelo mundo externo.

Solução

Pensando bem, nosso cluster de MongoDB está provisionado dentro da AWS, nossa aplicação também está dentro da AWS, nossa aplicação realmente precisa fazer toda essa volta para chegar até o banco? Para o nosso bem a resposta para essa pergunta é "não", quase todos os possíveis serviços que você pode pensar em consumir oferecem uma maneira de garantir que a comunicação com eles permaneça inteiramente dentro da AWS, a maneira mais comum é o VPC Peering que tanto o Mongo Atlas quanto o CloudAmqp fornecem. O Datadog por exemplo fornece um endpoint para acesso direto, dessa forma todo o tráfego permanece dentro da rede interna da AWS e nem passa pelo NAT Gateway.

Após criar o VPC Peering do Mongo Atlas como nesse passo a passo, chegamos na arquitetura acima, essa arquitetura é muito mais segura, performática e elimina o custo do NAT Gateway. A outra arquitetura nem deveria ser considerada, principalmente se a empresa trabalha com dados sensíveis. Perceba que no diagrama acima nem aparecem os "Internet Gateways", isso porque a partir de agora a aplicação vai consumir a aplicação diretamente através do Peering.

Com relação aos problemas apontados anteriormente, uma vez que não precisamos mais sair para internet para chegar até nosso banco de dados, o custo com Tráfego do Nat Gateway deve reduzir, talvez se nossa aplicação não precisar de algum outro recurso interno seria possível até remover o NAT Gateway.

O banco de dados já estava próximo à nossa aplicação, nossa aplicação apenas não conseguia chegar até ele da maneira mais fácil, após fazer o Peering nossa aplicação passa a conhecer o melhor caminho até o banco, ficando a poucos saltos do banco e melhorando a performance e resiliência.

Por último devemos notar que agora é impossível de um elemento desconhecido interceptar o tráfego entre nossa aplicação e o banco, isso diminui muito a superfície de ataque que um suposto Hackerzinho malvado poderia utilizar.

Últimas configurações

Agora já conseguimos atingir 90% dos nossos objetivos, mas para finalizar precisamos impedir que o Mongo Atlas seja acessível externamente. Geralmente esse tipo de serviço gerenciado relacionado a infraestrutura tem uma área de Network como a do Atlas:

A imagem acima contém as regras de acesso da Convenia para o Atlas, temos dois peerings logo temos 2 regras de acesso permitindo apenas acessos vindos das 2 VPCs da Convenia. Aqui o ideal é remover qualquer regra permitindo o intervalo 0.0.0.0/0, esse intervalo permite acesso global ao cluster.

Conclusão

A utilização de recursos como VPC Peering e VPC Endpoints podem aumentar a performance e melhorar a segurança da sua aplicação, bem como diminuir o custo com tráfego no Nat gateway. Aliás mantenha distância do Nat gateway, saia para internet apenas quando for realmente necessário.

Utilizando uma imagem base para suas aplicações PHP

Leonardo Lemos — Thu, 28 Jul 2022 18:04:00 +0000

Para garantir a padronização das aplicações e facilitar o trabalho do dia a dia, na Convenia, utilizamos uma imagem base para todas as aplicações. O proposito desse post é mostrar as vantagens dessa abordagem e como criar suas aplicações a partir dessa imagem.

Porque padronizar a imagem base?

Na Convenia temos uma stack bem homogênea quase que inteiramente em PHP, manter uma imagem diferente em cada projeto aumenta a chance de aparecer um problema específico com uma versão específica de uma biblioteca que está instalada apenas em um projeto, o desenvolvedor que mantém esse projeto terá que resolver esse problema e não terá como reaproveitar o conhecimento dos amigos visto que esse problema ocorreu apenas no projeto dele.

Seguindo a mesma linha de raciocínio imagine o quão diferente os setups podem parecer sem uma padronização, manter essa padronização ajuda bastante quando o desenvolvedor muda de projeto ou mesmo quando ele faz um "merge request" em um outro projeto, dessa forma ganhamos agilidade por não ter que estudar especificidades de cada projeto.

Novas features e correções de bugs são centralizadas em apenas uma imagem ao invés de serem feitas em cada projeto.

Bom e finalmente eliminamos o famoso "na minha maquina funciona". Já que estamos utilizando um container padronizado no ambiente de desenvolvimento porque não utilizar o mesmo container em ambiente de produção(com alguns cuidados claro)? Isso praticamente erradica a possibilidade de ocorrer um erro proveniente da discrepância entre uma biblioteca visto que quase todas as bibliotecas vão ser idênticas. Esse risco só não é nulo porque inevitavelmente vamos ter que instalar alguma extensão antes de enviar para produção(opcache por exemplo).

Em algum momento teremos que gerar uma nova imagem a partir da imagem base contendo a aplicação para rodar em produção. Se todos os projetos tem a necessidade de ter um webserver por exemplo porque não adicionar esse webserver já na imagem base? Isso vai tornar a etapa de build do pipeline muito mais rápida visto que passamos a maioria das coisas comuns aos projetos para a imagem base, temos um deploy mais ágil!

Utilizando a imagem base

Para rodar uma aplicações PHP da forma convencional são necessários 2 containers, o PHP-FPM e um servidor web como nginx ou apache. Rodar esses 2 componentes separadamente, apesar de ser o recomendado, demanda que o desenvolvedor mergulhe em detalhes referentes à comunicação entre os containers e até mesmo configuração de volumes, muitas vezes esses detalhes não são interessantes no momento, desenvolvedores iniciantes se sentem bem perdidos nesses detalhes.

Analisando outras stacks como nodejs vamos perceber que é relativamente mais simples containerizar esse tipo de aplicação, pois o próprio processo do node já é capaz de servir os requests sendo necessário apenas um container, mas e se podessemos rodar uma aplicação PHP com a mesma simplicidade? Essa é a proposta da imagem PHP Full que utilizamos aqui na convenia como imagem base de todas as aplicações PHP.

Vamos executar a imagem PHP Full com o seguinte comando:

docker run --rm -p 80:80 convenia/php-full:latest

O comando acima executa um container apartir da image convenia/php-full:latest e binda a porta 80 do container à porta 80 do host, logo ao entrar no nosso localhost pelo browser(em windows e macOS pode ser necessário utilizar o IP da vm do docker, dependendo do seu setup) devemos ver a página da documentação:

Essa documentação é um arquivo PHP, isso significa que a imagem já está pronta para servir nossa aplicação, tudo que precisamos fazer é colocar nossa aplicação dentro do diretório /var/www/app que é onde a imagem procura por padrão.

Para fazer um lab bem rápido vamos executar um comando no terminal para instalar uma aplicação Laravel fresh:

docker run --user 1000 --rm -v $(pwd):/app composer create-project laravel/laravel

Isso deve utilizar o composer para criar uma aplicação Laravel bem na pasta em que executamos o comando. Em seguida vamos executar o seguinte comando para criar um container "colocando" a aplicação Laravel que criamos no passo anterior dentro da pasta /var/www/app, é nessa pasta que o webserver dentro do container olha para servir a aplicação:

docker run --rm -p 80:80 -v $(pwd)/laravel:/var/www/app convenia/php-full:latest

Após executar o comando podemos entrar no nosso browser novamente porém agora o resultado é esse:

Pronto finalmente estamos rodando nossa aplicação PHP dentro do container, e tudo que fizemos foi copiar a aplicação para uma pasta específica dentro do container, esse é o propósito dessa imagem, prover uma forma simples e segura para executar aplicações PHP podendo ser utilizado em ambiente de desenvolvimento e produção.

Criando um arquivo Docker Compose

Já sabemos como utilizar nossa imagem porém em um ambiente real podemos sentir a necessidade de rodar mais de um container, containers de serviços como mysql e redis para nossa aplicação e o próprio container da nossa aplicação pode começar a ficar complexo pois pode surgir a necessidade de utilizar mais volumes, podemos definir uma network para isolar nossa aplicação. Logo o comando para rodar esse container vai ficando cada vez mais complexo e rodar a stack completa se torna uma tarefa árdua. Para resolver esse problema utilizamos um arquivo docker-compose.yml que deve ser criado na raiz do projeto:

version: '3.3'
services:
  app:
    image: convenia/php-full:latest
    container_name: application
    volumes:
      - .:/var/www/app
    ports:
      - 80:80

Esse arquivo contém todos os detalhes que incluímos via linha de comando quando rodamos nosso container e ele é versionado junto com a aplicação, dessa forma qualquer pessoa que pegar o projeto consegue executar a stack toda com um único comando:

docker-compose up -d

Após executar esse comando devemos ver o mesmo resultado de quando utilizamos o comando anterior, devemos ver a aplicação rodando no browser.

Conclusão

Com certeza padronizar uma imagem base nos seus projetos não vai resolver todos os seus problemas mas ajuda a diminuir a complexidade na implantação e evita silos de conhecimento relacionados ao setup local, espero ter contribuído com esse post, deixe sua opinião nos comentários ou me da um grito no twitter.

Os cuidados para um deploy "Zero Down Time"

Leonardo Lemos — Tue, 07 Dec 2021 21:36:15 +0000

Atualmente existem ferramentas que nos ajudam a executar containers em produção e a maioria delas trazem funcionalidades preciosas como "Health Checks", "Limite de recursos" e até mesmo prometem um deploy "Zero Down Time", o foco deste post é nesse último Item. Na Convenia utilizamos o Docker Swarm para gerenciar alguns containers em produção e o Docker Swarm entrega esse tipo de deploy "Zero Down Time" através de uma simples configuração, porém após alguns testes em uma API sob stress constatamos que sempre ocorriam alguns erros no momento do deploy. Aprofundando a análise do que poderia causar esses erros, percebemos que podemos cometer alguns "equívocos" que nos impedem de ter um deploy verdadeiramente sem Down Time e ainda podemos constatar que esses "equívocos" são comuns em outras ferramentas como Kubernetes também, dai saiu a motivação para escrever esse post.

Graceful ShutDown

A grosso modo podemos definir "Graceful shutdown" como a maneira "natural" em que um processo é desligado. Muitos processos abrem sockets e trabalham com estado em memória então para esses processos desligarem naturalmente muito provavelmente eles vão fechar as conexões abertas e persistirem o estado, que está na memória, no HD para que não haja perda de dados e para poder retomarem as atividades sem maiores problemas quando forem reiniciados, em uma queda de energia por exemplo, os processos não tem esse privilégio, nesse caso podemos nos deparar com erros durante a próxima inicialização do processo, isso é conhecido como "Hard Shutdown".

A boa notícia é que todos os softwares mais difundidos fazem isso por padrão, o nginx quando recebe o "sinal" de desligamento espera a resposta de todos os requests que estão em execução no momento, antes de desligar de fato. Esse "Graceful Shutdown" é importante porque o deploy consiste na "troca" de um processo com a versão antiga do software pelo mesmo processo contendo a versão nova, ao desligar o processo contendo a versão antiga, os requests que estiverem em execução não podem falhar, pois eles ainda estão sendo respondidos pelo processo antigo enquanto os novos requests já estão sendo servidos pelo processo novo como mostrado na imagem abaixo.

Na Convenia temos muitos listeners feitos com o Pigeon, nesse caso não estamos falando de um webserver e sim de um consumer que "ouve" uma fila do RabbitMQ, você já deve imaginar que para "ouvir" essa fila temos que ter uma conexão aberta com o RabbitMQ então nada mais justo que fechar as conexões no momento em que o processo for desligado, é justamente isso que o Pigeon faz no código a seguir:

    protected function listenSignals(): void
    {
        defined('AMQP_WITHOUT_SIGNALS') ?: define('AMQP_WITHOUT_SIGNALS', false);

        pcntl_async_signals(true);

        pcntl_signal(SIGTERM, [$this, 'signalHandler']);
        pcntl_signal(SIGINT, [$this, 'signalHandler']);
        pcntl_signal(SIGQUIT, [$this, 'signalHandler']);
    }

    public function signalHandler($signalNumber)
    {
        switch ($signalNumber) {
            case SIGTERM:  // 15 : supervisor default stop
                $this->quitHard();
                break;
            case SIGQUIT:  // 3  : kill -s QUIT
                $this->quitHard();
                break;
            case SIGINT:   // 2  : ctrl+c
                $this->quit();
                break;
        }
    }

Nesse código definimos handlers para os sinais de desligamento que o processo pode receber e chamamos os métodos quit() e quitHard() que têm como objetivo fechar a conexão com o RabbitMQ. Até agora falamos muito sobre esses sinais que os processos podem receber de outro processos, ou até mesmo do kernel, mas caso você não estaja familiarizado ou se não souber exatamente a diferença entre eles, você pode ficar um pouco mais por dentro nesse artigo.

PID 1

Quando utilizamos docker para executar nossa aplicação em produção e fazemos um deploy, um container com a nova versão da aplicação é iniciado,o container com a versão antiga da aplicação recebe o sinal "SIGTERM" que é um pedido formal de desligamento, caso o container demore mais que 10 segundos para desligar ele será morto, logo o processo dentro do container tem 10 segundos para fazer o seu "Graceful Shutdown". A grande pegadinha é que dentro do container apenas o processo de ID 1 vai receber esse sinal, se dentro do container iniciarmos um outro processo antes da nossa aplicação, esse processo vai portar o id 1 e não a nossa aplicação. Agora que temos outro processo recebendo os sinais de desligamento no lugar da nossa aplicação, nunca vamos ter a oportunidade de fazer um Graceful Shutdown porque nunca saberemos o momento de desligar, por mais que esse pareça um erro bobo na verdade isso acaba acontecendo com uma certa frequência como por exemplo nos Dockerfiles a seguir:

FROM nginx:latest

ENTRYPOINT ["nginx", "-g", "daemon off;"]

O Dockerfile acima está com o ENTRYPOINT no formato de array, se você entrar dentro do container gerado por esse Dockerfie e executar o comando pstree verá o seguinte output:

Perceba que o "nginx" é o primeiro processo mais a esquerda, isso significa que atingiremos o objetivo de ter um Graceful Shutdown visto que o nginx vai receber os sinais pessoalmente e ele sabe muito bem como lidar, para tirar a dúvida podemos executar um docker stop no container em execução e provavelmente veremos o container sendo desligado quase instantaneamente.

FROM nginx:latest

ENTRYPOINT nginx -g 'daemon off;'

A Mudança no dockerfile acima foi sutil, mas faz toda a diferença, com a sintaxe corrida do ENTRYPOINT o comando em questão é executato pelo shell dentro do container, segue o output do pstree:

Agora o processo mais a esquerda é o sh, ele quem receberá os sinais de desligamento e por acaso não sabe muito bem o que fazer com esses sinais, se você executar um docker stop nesse container verá que demora 10 segundos para parar, dessa forma não faremos o "Graceful Shutdown" e nunca teremos um verdadeiro deploy "Zero Down Time" porque sempre que o container com a versão antiga do código morrer, vai levar os requests que estão em execução para a vala junto. Logo devemos nos assegurar que nosso processo está recebendo o sinal de desligamento corretamente.

Vários processos no mesmo container

É conceitualmente correto que o container contenha apenas um processo(PID 1), mas é relativamente comum aparecer a necessidade de executar mais de um processo no mesmo container. Tomando como exemplo uma aplicação PHP, que não é capaz de responder como uma aplicação completa(HTTP) apenas com o processo do PHP-FPM, pois necessita de um reverse proxy como apache ou nginx para isso, como poderíamos fazer um único container contendo tanto nginx como php-fmp e que funcione como uma aplicação completa capaz de entender o protocolo HTTP? A própria documentação do docker nos traz algumas recomendações sendo que dentre elas a melhor seria utilizar o supervisord como processo principal no container, cuidando dos outros processos. O supervisord é capaz de propagar os sinais de desligamento que recebe para os processos filhos, sendo assim tanto o nginx quanto o PHP-FPM terão a possibilidade de fazer um "Graceful Shutdown" assim que o supervisord receber o sinal SIGTERM.

Prioridade dos processos dentro do container

Bom temos uma aplicação PHP sendo executada em produção e seguimos tudo que foi falado até agora, estamos executando tanto o php-fpm quanto o nginx, ambos rodando sobre o supervisord, porém por incrível que pareça estamos notando o erro 502 durante o deploy. Isso acontece porque durante o deploy um novo container é criado e o supervisord simplesmente não sabe qual processo deve iniciar primeiro, se por acaso o nginx estiver pronto para receber um request, mas o php-fpm ainda não foi corretamente iniciado então temos um 502. Resolver esse problema de prioridade entre os processos é relativamente simples, o supervisord tem uma flag priority que tem o proposito de dizer quem é o processo de maior prioridade, entre outras palavras esse processo deve ser criado primeiro e morrer por último, a seguir segue uma configuração real de uma aplicação da Convenia em produção:

[supervisord]
nodaemon=true

[program:nginx]
command = nginx -c /etc/nginx/nginx.conf  -g 'daemon off;'
user = app
autostart = true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
redirect_stderr=true

[program:php-fpm]
command = /usr/sbin/php-fpm7 -F
priority = 1
user = app
autostart = true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
redirect_stderr=true

Esse é um arquivo de configuração do supervisord, perceba a configuração do php-fpm priority = 1, essa configuração vai instruir o supervisord a criar o php-fpm primeiro e a desligar ele por último, agora sim temos um deploy perfeito, sem downtime.

Conclusão

Para alcançar um deploy perfeito não adianta simplesmente utilizar os orquestradores mais poderosos do mercado, precisamos tomar alguns cuidados com o nosso container e aplicação também:

Garantir que a aplicação é capaz de fazer um Graceful Shutdown
Garantir que a aplicação está recebendo os sinais de desligamento corretamente, ou mantendo a aplicação como sendo o primeiro processo dentro do container, ou utilizando alguma ferramenta como o supervisord que propaga os sinais que ela recebe.
Garantir que os processos estão sendo iniciados e desligados na ordem correta, caso o container rode mais de um processo.

Tomado esses cuidados estamos prontos para ter um deploy sem Downtime.

Arquitetura Event Driven, quando da errado

Leonardo Lemos — Mon, 21 Jun 2021 14:15:40 +0000

Introdução

No post anterior expliquei um pouco como funciona uma arquitetura orientada a eventos e como implementamos essa arquitetura na Convenia. Comentei um pouco sobre o nosso tratamento de erros e hoje pretendo me aprofundar mais nesse assunto.

Assim como no post anterior gostaria de enfatizar que as escolhas de arquitetura e stack fazem sentido para o nosso tamanho e previsão de crescimento. Possivelmente para você não faça sentido fazer tudo da mesma forma como fazemos uma vez que cada projeto é único com as suas particularidades, mesmo assim é provável que você consiga tirar algo de bom desse post.

Nesse post as palavras "mensagem" e "evento" representam a mesma coisa mas em contextos diferentes, a grosso modo "mensagem" é o nome dado a informação em transito através de um message broker e evento é o nome dado para a mensagem em um contexto "orientado a eventos", "listener" é o nome dado ao processo responsável por "ouvir" eventos.

Como os serviços se comunicam?

A seguir vamos analisar um exemplo simples utilizando o Pigeon bem parecido com o do post anterior:

Pigeon::dispatch('employee.created', [
    'name' => 'Scooby Doo' 
]);

No exemplo acima estamos emitindo o evento employee.created que tem como body o nome do colaborador, para ouvir esse evento em outro serviço com o Pigeon temos esse código:

Pigeon::events('employee.created')
    ->callback(function ($event, ResolverContract $resolver) {
            //doing nice things

            $resolver->ack();
        })->fallback(Throwable $exception, $message, $resolver) {
            //send to sentry

            $resolver->reject(false);
        })->consume(0, true);

O código acima faz algumas coisas

Configura o Pigeon para ouvir o evento employee.created em outro serviço, com a chamada Pigeon::events('employee.created').
Define um callback para "lidar" com o evento passando uma Closure através do método ->callback(), essa Closure será executada cada vez que o evento employee.created for "ouvido".
Define um fallback através do método ->fallback(), essa closure será executada sempre que acontecer uma exception dentro do callback.
O método ->consume() começa a consumir a fila de fato.

O Pigeon utiliza RabbitMQ para intermediar a comunicação entre os dois serviços, se tentarmos mostrar isso em um diagrama teremos o seguinte:

No momento em que o serviço lê a mensagem do RabbitMQ a mensagem fica em um estado "unacked", isso significa que o Rabbit está esperando a confirmação dessa mensagem por parte de quem a leu. O RabbitMQ não entregará essa mensagem a mais ninguem até receber a confirmação de que algo deu certo ou a confirmação de que algo deu errado(rejeição) com a mensagem. No passo 4 retratado no diagrama acima fazemos uma confirmação na mensagem para o RabbitMQ saber que ela foi processada corretamente, apenas depois de receber essa confirmação o RabbitMQ remove a mensagem da fila.

O diagrama acima mostra um caminho muito feliz mas vamos imaginar que logo após ler a mensagem, o serviço ouvinte "morre" devido a algum problema de hardware antes de confirmar a mensagem:

De forma similar ao exemplo anterior, após a leitura da mensagem o Rabbit coloca a mensagem no estado "unacked", ao processar a mensagem um erro muito inesperado acontece e o Listener(processo) morre no passo 3, nesse momento o Rabbit sabe que deve voltar a mensagem para o estado de "ready", assim outro listener pode tentar processar essa mesma mensagem, isso é possível porque os listeners mantém uma conexão aberta com o Rabbit e quando o processo do listener morre a conexão com o Rabbit é "cortada", nesse momento ele sabe que deve "liberar" todas as mensagens que aquele listener leu mas não confirmou.

Até o momento mostramos fluxos saudáveis e falhas de terceiros que podem acontecer esporadicamente mas e quando nosso próprio código que consome a mensagem está quebrado? E quando a própria mensagem está quebrada?

Dead Letter Exchange para o Resgate

Vamos tentar imaginar a seguinte situação onde o código do nosso próprio listener está quebrado:

Pigeon::events('employee.created')->callback(function ($event, ResolverContract $resolver) {
    doesNotExists();

    $resolver->ack();
})->consume(0, true);

No código acima repare a chamada para a função doesNotExists(), como o próprio nome já diz essa função não existe e quando esse listener tentar consumir uma mensagem ele vai entrar no fluxo retratado na imagem 2. O grande problema é que normalmente utilizamos algum recurso como o supervisord para "reviver" os processos que morrem e quando esse listener "voltar a vida" ele vai entrar no fluxo da imagem 2 novamente entrando em um looping.

Temos uma mensagem sendo consumida em looping, ela será consumida corretamente apenas se o código do listener for corrigido, isso causa vários problemas como mostrado no post anterior. O RabbitMQ, não por acaso, tem um recurso chamado dead letter exchange que serve para esse tipo de situação e com esse recurso a mensagem pode ser enviada em uma exchange separada para ser tratada posteriormente, como mostra o fluxo a seguir:

Para esse fluxo acontecer precisamos "rejeitar" explicitamente a mensagem através do método fallback mostrado no inicio do artigo e retratado novamente a seguir:

->fallback(Throwable $exception, $message, $resolver) {
    //send to sentry

    $resolver->reject(false);
})

No código acima a chamada $resolver->reject(false); é a chamada que rejeita explicitamente a mensagem, caso você não defina um fallback, o Pigeon tem um fallback padrão que rejeitará a mensagem caso a env PIGEON_ON_FAILURE esteja presente com o valor reject.

LetterThief

Após rejeitar a mensagem, ela irá para uma dead letter exchange de onde podemos armazenar essa mensagem problemática em uma fila, avaliar mais tarde ou dar um tratamento digno para ela ali mesmo. No caso da Convenia desenvolvemos um serviço chamado "LetterThief" que é responsável por gerenciar as mensagens que foram rejeitadas e avisar o time quando ocorre uma rejeição:

Acima está retratada a listagem das mensagens rejeitadas, nesse serviço conseguimos filtrar as mensagens pela suas propriedades, Toda rejeição ocorre em uma fila e exchange específicas e em um certo momento. Os filtros são capazes de trazer rejeições que ocorreram em uma determinada fila ou em um determinado momento.

Ná página de detalhes da mensagem rejeitada temos todas as informações da mensagem, sabemos de que serviço ela veio, sabemos qual foi o listener que a rejeitou e o mais importante, temos o correlation_id que será utilizado para confrontar o erro com as exceptions que cairem no sentry. Com essas informações sabemos exatamente o porque uma mensagem foi rejeitada e o envio para o sentry é feito pelo listener logo antes de rejeitar a mensagem:

As imagens acima mostram um erro real que ocorreu no ambiente de produção e a parte de tags contendo o correlation_id, infelizmente não posso mostrar a exception com mais detalhes para não expor dados sensíveis :/

Legal, o serviço traz bastante visibilidade para os erros que ocorreram mas como os desenvolvedores são avisados sobre o ocorrido? O LetterThief tem uma integração com o slack assim toda a equipe é notificada quando um erro ocorre e pode agir imediatamente para resolver o problema.

Na imagem acima vemos a notificação que chega no slack, ela contém a fila onde ocorreu o problema e o link para a mensagem no serviço do LetterThief, dessa forma o desenvolvedor responsável já sabe que deve corrigir o problema o quanto antes.

Você deve estar se perguntando o que acontece com a mensagem após a correção do problema já que muito provavelmente ela deveria causar algum efeito no sistema mas acabou não causando devido ao erro ocorrido, após resolver o erro o desenvolvedor tem a capacidade de reenviar a mensagem através do LetterThief.

Na imagem acima é possível ver o botão "TRY MESSAGE AGAIN" que resulta nessa confirmação que está sendo exibida, após a confirmação, a mensagem será reenviada diretamente para a fila de onde o erro foi causado, dessa forma o processamento deve ocorrer normalmente.

Cuidados adicionais

Você deve estar se deparando com algumas questões após ter chego até aqui, a verdade é que para tudo isso funcionar corretamente temos que ter alguns cuidados que são garantidos em um fluxo rígido de code review:

Os listeners devem ser idempotentes, como pode ocorrer um erro durante o processamento, no caso de uma criação no banco de dados por exemplo, não podem haver registros duplicados, devemos fazer a opção por uma função de upsert ao invés de um create, isso vai evitar que dois registros sejam criados quando a mensagem for reenviada, lembrando que a mensagem pode ser reenviada mais de uma vez.
O listener deve obrigatoriamente enviar a mensagem para o sentry e logo em seguida rejeitar a mensagem no fallback, muita lógica não é bem vinda aqui pois não podem haver falhas dentro do fallback, isso causaria a devolução da mansagem para a fila e o problema de reprocessamento infinito apresentado no inicio do post.
Devemos ser cuidadosos ao avaliar datas dentro do listener, não devemos nunca avaliar o momento em que a mensagem chega no listener, sempre devemos avaliar a data em que o evento foi emitido, isso chega obrigatoriamente com todo o evento, dessa forma evitamos de processar uma data errada devido ao delay da mensagem.

Conclusão

Toda arquitetura distribuída tem uma complexidade mais elevada, observabilidade e tratamento de erros são pautas de muitas talks e donos da preocupação de várias equipes. Sem dúvidas em uma arquitetura orientada a eventos precisamos de uma forma de lidar com erros no processamento de mensagens assíncronas. No caso específico da Convenia a melhor saída foi fazer nosso próprio serviço que atende exatamente ao que precisamos. Existem outras opções de message broker como kafka que podem trazer soluções já prontas para esse problema, o que te economizará o trabalho de desenvolver e manter a solução, de qualquer forma é muito importante ter uma solução similar a essa para auxiliar a equipe no dia a dia.

O LetterThief foi desenvolvido com a premissa da segurança em relação a perda de mensagens, se reparar cuidadosamente vai ver que utilizando o LetterThief é impossível perder uma mensagem no meio do caminho, ou ela foi processada corretamente ou foi parar no LetterThief, caso o desenvolvedor do listener tenha sido muito transgressor ao implementar o listener, a mensagem voltará para a fila, independente da opção que adotarmos acho essa premissa de "nunca perder a mensagem" importante para se levar em consideração.

Laravel & MongoDB na Convenia

Leonardo Lemos — Thu, 18 Mar 2021 02:03:31 +0000

Olá pessoal nesse post vou falar um pouco de como utilizamos MongoDB com o Laravel na Convenia e quais vantagens que ele nos trouxe com documentos embedados.

Como desenvolvedores estamos muito familiarizados com o modelo Relacional, por isso é comum cometermos o erro de modelar qualquer tipo de banco da mesma forma que modelamos um relacional. Para enfatizar a diferença na modelagem vamos tentar imaginar uma modelagem relacional para a tela mostrada na imagem seguinte, em seguida vamos tentar reproduzir a mesma modelagem com o MongoDB:

Na imagem acima temos 2 seções, o card a esquerda contendo informações gerais do colaborador e o card na direita contendo "Endereço", de uma forma mais clássica modelariamos isso em 2 tabelas, sempre tendo em mente evitar qualquer tipo de duplicidade de informação:

Do lado da aplicação precisaremos de 2 models para "dar vida" a essas 2 tabelas, a model do Laravel é uma implementação de active record, nesse padrão geralmente mapeamos uma tabela por model, essa model fará o papel da nossa entidade e também tem a responsabilidade de acessar o banco de dados.

//app/Models/Colaborador.php

class Colaborador extends Model
{
    use HasFactory;

    public function enderecos()
    {
        return $this->hasMany(
            Endereco::class,
            'id_colaborador',
            'id'
        );
    }
}

//app/Models/Endereco.php

class Endereco extends Model
{
    use HasFactory;
}

No nosso caso a Model principal é a model de Colaborador, ela mantém uma ligação com a model Endereco através do método enderecos que por si é um relacionamento HasMany (Colaborador possui vários Endereços), sempre que quisermos trazer o colaborador junto com o endereço temos 2 opções:

Podemos fazer um Lazy Loading:

Colaborador::find(1)
        ->enderecos
        ->first()
        ->cep;

O código acima resultará em 2 consultas: A primeira trazendo o colaborador e a segunda trazendo o endereço, a segunda por sua vez é executada no momento da chamada do relacionamento enderecos (representado pelo ->enderecos). A estrutura da consulta ficará da seguinte forma:

select
  *
from
  "colaboradors"
where
  "colaboradors"."id" = 1
limit
  1

select
  *
from
  "enderecos"
where
  "enderecos"."id_colaborador" = 1
  and "enderecos"."id_colaborador" is not null

Como você pode ver 2 consultas não é grande problema, mas se tivessemos uma coleçao de colaboradores teriamos o famoso problema de N+1 consultas, então com 10 colaboradores teriámos uma consulta para trazer os colaboradores e em seguida 10 consultas, para trazer os endereços de cada colaborador um a um, para resolver esse problema podemos fazer um Eager loading:

Colaborador::with('enderecos')->get();

Agora estamos trazendo todos os colaboradores com endereço, a chamada ao método with instrui o ORM a trazer os endereços de todos os colaboradores em uma única consulta:

select
  *
from
  "colaboradors"

select
  *
from
  "enderecos"
where
  "enderecos"."id_colaborador" in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20)

Perceba que o resultado da consulta de colaboradores é utilizado na consulta de endereços, e o próprio Eloquent sabe como combinar os dados de endereço com os dados de colaboradores por baixo dos panos.

Com a explicação acima podemos chegar a conclusão de que a consulta acima não é tão problemática mas vamos pensar que o colaborador na vida real tem muito mais relacionamentos, apenas como exercício tente estruturar os relacionamentos seguintes na sua cabeça: absences, contactInformation, dependents, documents, perceba que em um cenário real o número de queries separadas que precisamos fazer pode nos trazer um problema de performance, esse exemplo é um exemplo real, é um pedacinho da nossa entidade de colaborador, não seria exagero falar em dezenas de relacionamentos.

Agora que já vimos um exemplo de modelagem no MySQL (relacional), como ficaria esse mesmo exemplo no MongoDB e o quais seriam as vantagens?

O MongoDB é um banco de dados baseado em documentos, descrevemos o que é armazenado no formato JSON, e diferente do MySql ele tem um schema flexível, isso significa que você pode mudar a estrutura do documento de acordo com a necessidade, sem se preocupar em criar migrações.

O pacote mais difundido para se trabalhar com o mongo no Laravel é o Laravel MongoDB, ele "imita" o eloquent garantindo a mesma interface, e nos traz bastantes possibilidades, veja como ficaria a mesma modelagem em uma única coleção no mongo:

> db.colaboradors.find().pretty()
{
    "_id" : ObjectId("604c12d75c9f4250b731d662"),
    "name" : "Miss Amelia Schuppe",
    "cargo" : "in",
    "departamento" : "aut",
    "salario" : 1000,
    "data_admissao" : "2021-03-13",
    "endereco" : {
        "cep" : "15014140",
        "endereco" : "125 Hammes Extensions\nSouth Bernadinebury, OR 51480",
        "bairro" : "East Alf",
        "cidade" : "West Tremayne",
        "uf" : "Wisconsin",
        "numero" : 200
    },
    "updated_at" : ISODate("2021-03-13T01:18:15.747Z"),
    "created_at" : ISODate("2021-03-13T01:18:15.747Z")
}

O MongoDB nos apresenta um paradigma de modelagem diferente, em um banco de dados relacional nos baseamos nas entidades em si e na suas relações, buscamos uma maior normalização e evitamos duplicidade, ao modelar as coleções no MongoDB fazemos a modelagem baseado na consulta, podemos inclusive ter 2 coleções diferentes de colaboradores para consultas diferentes, claro que isso nos traz alguns desafios na escrita pois teremos que manter ambas as coleções atualizadas, mas ganhamos muita performance na leitura, não é errado inclusive pensarmos em manter o mesmo dado duplicado no mesmo documento porém em formatos diferentes, uma versão "crua" do dado e outra versão formatada pronta para exibição.

No documento modelado acima temos o endereço embedado na entidade colaborador, quando consultarmos o colaborador, com apenas uma consulta, recebemos o seu endereço "de graça", imagine que no exemplo real da Convenia onde temos uma série de relacionamentos do colaborador, apenas uma consulta basta para trazer o colaborador por completo, isso traz um ganho de performance bem interessante!

O pacote nos traz um relacionamento especial para tratar documentos embedados, o embeds many:

class Colaborador extends Model
{
    use HasFactory;

    protected $connection = 'mongodb';

    public function enderecos()
    {
        return $this->embedsMany(
            Endereco::class,
            'id',
            'id_colaborador'
        );
    }
}

Isso permite que você mantenha a mesma modelagem de Entidades no lado da aplicação, tendo uma model específica para o endereço, na hora de armazenar o ORM vai entender que ele deve embedar (fazer o upsert do registro) o endereço dentro do documento de colaborador.

Você pode estar se perguntando "mas e se eu quiser compartilhar o endereço com mais de um colaborador?", nesse caso tenha em mente que os tipos de relacionamentos convencionais (hasMany, hasOne, belongsTo), ainda estão disponíveis, nesse caso a modelagem fica muito parecida com o a modelagem do MySql, existem casos em que isso é bem vindo:

> db.colaboradors.find().pretty()
{
    "_id" : ObjectId("604c1572e8a76d528004f023"),
    "name" : "Jaycee Cole",
    "cargo" : "deleniti",
    "departamento" : "optio",
    "salario" : 1000,
    "data_admissao" : "2021-03-13",
    "endereco" : "604c1572e8a76d528004f022",
    "updated_at" : ISODate("2021-03-13T01:29:22.757Z"),
    "created_at" : ISODate("2021-03-13T01:29:22.757Z")
}

> db.enderecos.find().pretty()
{
    "_id" : ObjectId("604c1572e8a76d528004f022"),
    "cep" : "15014140",
    "endereco" : "36740 Jenkins Mountain Suite 890\nPort Rubie, UT 17199",
    "bairro" : "Lennashire",
    "cidade" : "Isaiahbury",
    "uf" : "California",
    "numero" : 200,
    "updated_at" : ISODate("2021-03-13T01:29:22.736Z"),
    "created_at" : ISODate("2021-03-13T01:29:22.736Z")
}

Como mostrado acima, peceba que é possível reproduzir no MongoDB qualquer tipo de estrutura que fariamos em um banco relacionar, porém precisamos ter em mente que o MongoDB não tem a operação de join, a operação similar no MongoDB seria o lookup mas utilizando o "Laravel MongoDB" presisamos fazer uma query raw, que fica bem desajeitada apesar de cumprir perfeitamente o seu papel.

Muito bem, mas agora como eu decido qual tipo de relacionamento devo utilizar?

O protagonismo da Entidade

Bem não existe uma receita perfeita para decidir o que devemos embedar ou não, mas temos sinais que devemos avaliar para tomar essa decisão, todos esses sinais vão determinar o protagonismo da entidade no seu sistema, vamos avaliar a entidade de endereço como exemplo.

Precisamos compartilhar aquele endereço entre vários colaboradores? Caso não precise compartilhar o endereço, é um bom sinal de que o correto seria embedar esse dado, se precisarmos compartilhar o endereço pode ser mais inteligente definir uma coleção de endereços pois evita o esforço de atualizar vários colaboradores ao atualizar um único endereço.
Onde precisamos exibir o endereço, sempre presicamos exibir a entidade no qual ele pertence(colaborador)? Aqui você pode argumentar que estamos deixando o layout guiar a modelagem, mas de fato o layout diz muito sobre a importância de uma certa Entidade no sistema, se o endereço sempre é exibido junto com o colaborador devemos suspeitar de que o endereço não tem o protagonismo necessário para compor sua própria coleção.
As rotas(REST) em que o endereço aparecem, são rotas do próprio endereço ou são rotas do colaborador? Se a informação do endereço forem exibidas somente em rotas do colaborador ou em uma rota filha do colaborador(nested resource) então devemos entender isso como um sinal de que o endereço deve ser embedado no colaborador.
Existem muitos procedimentos que levam em consideração apenas o endereço? Vamos entender a busca como um procedimento, em geral não é comum buscarmos colaboradores por endereço, apenas por dados como nome, departamento, cargo, isso também sinaliza o baixo protagonismo da model de Endereço.
Existe muito acesso ao colaborador apenas para ver o Endereço? É possível que todas as afirmações acima te levem a entender que você deve embedar o endereço porém é possível que as pessoas utilizem muito o endereço por algum motivo(envio de correspondência talvez), nesse caso pode ser necessário dar ao endereço sua própria coleção, isso vai impedir as leituras de endereço de concorrerem com as leituras de colaborador, claro que para isso funcionar a tela de endereço deve ser remodelada para não exibir outros dados, óbvio também que o designer do time não vai gostar disso né, mas aí é ver se vale ou não a pena.

Se você confrontar suas entidades com a lista acima vai ver que na maioria dos casos as entidades que devem ser embedadas são o que chamamos de "entidades fracas", são entidades que não tem o porquê de existir sem uma "entidade forte" na qual ela pertence.

Bancos relacionais e campos json

Quase todos os bancos relacionais modernos trazem algum tipo de solução de schema flexível, eu estaria sendo muito parcial se não comentasse sobre isso, o MySQL por exemplo, tem campos json que nos permitem os mesmos resultados citados acima, bem como a mesma análise de "protagonismo da entidade", isso conversaria muito bem com o Laravel e seu recurso de custom casts, sem dúvida você deve levar essa possibilidade em consideração, no nosso caso acabamos fazendo a opção pelo MongoDB por outras vantagens como o aggregation pipeline, que é uma ferramenta muito poderosa para filtrar e transformar os resultados, feature essa que necessita de um único post somente para ela.

Conclusão

O MongoDB é uma ferramenta muito completa e com certeza tem muito a oferecer, no entanto a maioria das aplicações são perfeitamente atendidas com o bom e velho banco relacional, se esse for o seu caso sugiro que você faça a opção pelo conhecido, pois toda nova tecnologia traz uma curva de aprendizado bem como os seus próprios desafios, com o MongoDB não é diferente, pretendo escrever um posto mostrando todos os desafios que passamos com ele, e não foram poucos :)

Espero ter contrinuído de alguma forma, até a próxima!

Event Driven com Laravel Pigeon

Leonardo Lemos — Mon, 30 Nov 2020 01:24:54 +0000

Olá pessoal, event driven é uma arquitetura muito difundida em microserviços por promover desacoplamento entre os diferentes serviços, na Convenia fizemos a opção por essa arquitetura e nesse artigo gostaria de expor um pouco do que fizemos e como fizemos.

Primeiramente gostaria de dizer que as escolhas que fizemos foram levando em consideração nossa escala e previsão de crescimento, essa stack pode não ser a ideal para você e por se tratar de um tema bem amplo e sem uma definição formal, tomamos algumas iniciativas que fazem muito sentido para nós, mas podem não se encaixar bem no seu case, apesar disso é provável que o texto a seguir seja construtivo caso você esteja pensando em fazer algo assíncrono a desacoplado.

Como funciona uma arquitetura guiada por eventos?

Todo framework maduro atualmente vem com algum tipo de event bus, se você está familiarizado com esse conceito basta pensar nisso de uma forma mais ampla, ao invés de haver uma classe que dispara um evento e N classes de Listeners que ouvem esse evento, teriamos um serviço emissor e N serviços "ouvintes", caso isso não tenha ajudado na compreensão vou explicar um pouco melhor:

Na imagem acima temos alguns elementos importantes:

Serviço emissor(Serviço de pedidos): é o serviço de onde o estimulo é originado, ele é responsável apenas por fechar o pedido e ao finalizar ele grita: "Pedido Finalizado"! Dessa forma todos os outros serviços que se importam por esse "estimulo" podem reagir a ele. O serviço emissor não conhece os serviços que "se importam" pela mensagem dele, a atuação dele acaba integralmente após a emissão da mensagem.
Serviços Ouvintes (representados à direita da figura): Os três serviços se importam pela mensagem emitida pelo serviço de pedidos mas não conhecem o serviço de pedidos em si, dai para frente eles podem fazer o que quiserem com a mensagem emitida sem influenciar o serviço emissor ou mesmo sem influenciar outros ouvintes, muito diferente do que aconteceria em uma abordagem procedural.
Message broker(a peça central): Esse elemento é o responsável por promover o desacoplamento temporal entre o emissor e os ouvintes, isso significa que a mensagem é emitidas quando o emissor acha conveniente e sem que ele se importe se os ouvintes vão poder ouvir a mensagem naquele momento, os ouvintes podem ouvir a mensagem quando eles quiserem, se caso um ouvinte está offline ou mesmo "quebrado", o message broker vai "segurar" a mensagem até que aquele ouvinte esteja apto a recebe lá.

Como isso tudo se encaixa no ecossistema da Convenia?

Ao escolher as peças da stack procuramos manter o mínimo de complexidade possível para que a stack não nos onere e para que o desenvolvimento permaneça simples, fizemos a opção pelo rabbitmq pela simplicidade de uso e setup e por ser uma opção robusta o bastante.

Do lado das aplicações utilizamos PHP com o framework Laravel e isso nos trouxe bastante agilidade no desenlvolvimento das aplicações, porém quase não existem soluções para fazer todos os serviços funcionarem como uma unidade, então fizemos muita coisa por conta própria.

Logo no inicio começamos a fazer a comunicação entre os serviços com a lib mais difundida de php, a amqplib, que apesar de cumprir o seu papel e ser performática o bastante, parece desajeitada e é praticamente imockavel(intestável), além de nos obrigar a escrever um boilerplate deselegante, para resolver esse problema escrevemos o Pigeon(sugiro a leitura da documentação), ele envelopa a amqplib nos dando a possibilidade de testar as emissões e escrever um código verdadeiramente elegante, o Pigeon também nos permite tratar o rabbitmq como descartável, ao invés de manter um arquivo de definição de filas versionado, o Pigeon é capaz de criar as filas on the fly e já fazer os binds corretamente, se algo der errado apenas subimos outra instancia do rabbit e tudo irá funcionar.

Aqui está um exemplo de emissão de um evento com o Pigeon:

Pigeon::dispatch('sample.event', [
    'scooby' => 'doo' 
]);

Para ouvir o evento acima poderíamos fazer o seguinte código:

Pigeon::events('sample.event')
    ->callback(
        Closure::fromCallable([$this, 'httpCallback'])
    )->fallback(
        Closure::fromCallable([$this, 'httpFallback'])
    )->consume(0, true);

No exemplo acima definimos uma Closure para um callback(quando tudo ocorre bem) e outra para um fallback(quando algo da errado), o Pigeon é bem completo e pretendo entrar em mais detalhes em um outro post, mas por hora acredito que isso demonstra bem como ocorrem a comunicação entre os serviços.

Como projetar um Listener?

O listener é a classe que vai conter o código que ouve os eventos(código apresentado no item anterior), esse código abre um soquet com o rabbitmq e fica esperando por eventos, isso significa que o processo do listener nunca vai "morrer", por isso precisamos tomar alguns cuidados especiais pois por padrão o programador PHP está acostumado com o ciclo de vida do request, que é bem efêmero e isso nos permite fazer algumas transgressões que quando cometidas em um Listener pode dar muita dor de cabeça, seguem alguns cuidados necessários.

Execute o listener sempre sobre o supervisor: Isso não é só aconselhado para programas escritos em PHP, o vault é uma ferramenta para gerenciar segredos escrita em go e é aconselhável rodar ele sobre o supervisor também, isso porque o supervisor pode reviver o seu processo caso ele morra, sem ele seu listener morreria e você precisaria fazer um processo manual para revive-lo e com listener morto o serviço está "surdo".
Configure corretamente o supervisor: é importante dar atenção para as configurações do supervisor relacionadas a tentativas, em casos extremos o supervisor fica tentando reiniciar o processo que está quebrado infinitamente causando alto consumo de CPU, em setups mais simples onde o webserver fica na mesma instancia do Listener isso seria catastrófico pois o próprio webserver seria impactado, pense que se você utiliza algum serviço para gerenciar exceções como o sentry, normalmente existe uma cota, você pode estourar essa cota com as infinitas tentativas do supervisor e perder visibilidade.
Separe as instancias de listeners das instancias de webserver: para evitar a situação do item anterior seria uma boa prática ter instancias de "Worker", que rodam apenas esse listener, essas instancias tendem a ser mais simples também pois não precisam ser acessadas via HTTP, em clouds como a aws isso economizaria o custo e esforço de setup com load balancer.
Evite desperdiçar recursos: Agora o processo se mantêm vivo por muito tempo então devemos tomar o cuidado de fechar as conexões que abrimos e não fazer nem um tipo de procedimento que pode se acumular durando o consumos das mensagens do rabbitmq, suponha que você copie uma imagem para redimensiona-la e esquece de apagar essa imagem no final do processo, logo logo você ficará sem armazenamento, o mesmo é muito comum de acontecer com uso de memória.
Comandos do artisan: Comandos do artisan são feitos para procedimentos pontuais, coisas efêmeras também e não para "long running tasks", apesar da transgressão conceitual eles são uma opção de estrutura para fazer um listener, dentro dele você terá acesso a todas as estruturas do Laravel, apenas tenha em mente que comandos do artisan consomem um tando de memória considerável.
Idempotência: As mensagens podem ser reenviadas, logo a mesma mensagem pode chegar no mesmo listener 2 vezes, seu listener precisa processar essa mensagem de forma Idempotente, imagine que ele crie um registro no banco com um id "auto increment", se a mensagem chegar novamente ele não pode criar um outro registro, talvez um upsert seria a saída nesse caso.
Rejeite a mensagem em caso de falha: isso vamos explicar no próximo item...

E quando as coisas dão errado?

Certamente em algum momento as coisas vão quebrar, o listener quebrado tenta reprocessar a mensagem o número de vezes que foi estipulado pela configuração do supervisor e depois vai morrer, nesse caso a mensagem ficará represada na fila até o listener ser corrigido, após o deploy da correção a mensagem é consumida corretamente e tudo volta ao normal.

A situação acima não é a ideal pois o listener muitas vezes morre apenas para uma determinada mensagem, o rabbitmq tem uma configuração de dead letter exchange que nos permite enviar a mensagem para um local específico em caso de falha, no nosso caso rejeitamos todas as mensagem que causaram alguma falha.

Agora recebemos todas as mensagens quebradas em um único lugar mas deveríamos dar mais visibilidade possibilidades para essas mensagens, então criamos o LetterThief(Ladrão de cartas), um serviço que tem como objetivo notificar toda a falha e nos dá a possibilidade de reenviar as mensagens que causaram essa falha.

A imagem acima mostra a interface do Ladrão, com algumas ações com destaque para a ação "Try again", esse botão nos dá a possibilidade de reenviar a mensagem para o serviço de onde ela foi originada.

Ao abrir uma mensagem temos várias informações como metadados, headers e body, isso vai nos permitir reproduzir e corrigir o erro em ambiente local, somente após o deploy do fix devemos reenviar a mensagem.

Somente represar erros em um lugar específico não adiante, temos que soar um alarme avisando esse erro, no nosso caso temos um canal do slack onde caem todos os erros, a figura a sseguir mostra como isso funciona:

Ao ver a notificação no slack sabemos qual desenvolvedor é responsável para corrigir a falha justamente pelo nome da fila, esse desenvolvedor focará imediatamente nesse fix.

Conclusão

Toda arquitetura distribuída será relativamente mais complexa que um serviço em um único repositório, mas acredito que conseguimos chegar em uma arquitetura relativamente simples e segura, se comparado com o padrão utilizado em microserviços no mercado, cada case tem uma necessidade específica então dificilmente isso funcionará completamente para você mas pode ser que você tire alguma ideia disso tudo, e principalmente, jamais distribua sua arquitetura se não for realmente necessário.

Espero ter contribuído de alguma forma....

Laravel, single table inheritance

Leonardo Lemos — Mon, 03 Aug 2020 12:28:18 +0000

Introdução

Olá pessoal, nesse artigo gostaria de compartilhar uma técnica de herança que utilizamos na ferramenta de folha de pagamentos da Convenia e que nos ajuda muito quando precisamos calcular coisas como totais e somas em tabelas.

Nossa aplicação de Folha é feita em Laravel então os exemplos que vocês vão ver são feitos em Laravel porém acredito que as técnicas podem ser reproduzidas em qualquer framework ou linguagem, não posso esquecer de ressaltar que para melhor compreensão os exemplos foram bem simplificados.

Implementar herança no seu design de classes é algo bem trivial, talvez uma das primeiras coisas que você deve aprender ao começar estudar orientação a objetos, mas quando essas heranças devem refletir no banco de dados (principalmente bancos de dados relacionais) logo você deve começar a perceber o quão desajeitado isso pode se tornar, isso em parte pelo fato dos bancos relacionais não terem um mecanismo de herança, normalmente o que se faz é linkar tabelas separadas que representam as classes.

Tanto para contextualizar como para aprofundamento acho importante citar as técnicas mais comuns de herança, que são Concrete Table Inheritance, Class Table Inheritance e Single Table Inheritance, esta última será a que iremos explorar nesse artigo, ambas são explicadas com bem mais propriedade no livro Patterns of Enterprise Application Architecture do Martin Fowler.

Mão na massa

Para começar vamos mostrar uma das primeiras telas no passo a passo de fechamento, a tela de seleção de colaboradores.

Nessa tela selecionamos quais colaboradores devem fazer parte do cálculo de fechamento, porém existe uma outra entidade que entra automáticamente no calculo do colaborador, o seu dependente, agora imagine que se esses registros fossem mantidos em tabelas separadas para pegar um simples "total de participantes" ou mesmo os "valores totais", teriamos que fazer muitos rodeios como "Joins" e até mesmo dois procedimentos separados e uma posterior soma já no lado do PHP, desajeitado certo? mas se isso fosse mantido em apenas uma tabela ajudaria bastante, dessa forma a implementação ficaria da seguinte forma:


    public function up()

    {

        Schema::create('participants', function (Blueprint $table) {

            $table->id();

            $table->string('type');

            $table->unsignedInteger('payroll_id');

            $table->unsignedInteger('parent_id')->nullable();

            $table->string('name');

            $table->string('active')->default('inactive');

            $table->string('job_description')->nullable();

            $table->string('department')->nullable();

            $table->timestamps();

        });

    }

Esse é o código da nossa migração que gera a tabela participants, esse código já nos revela algo importante, teremos a entidade mais genérica Participant, além da entidade Employee e Dependent então o raciocínio é trazer todos os registros ao buscar com a model Participant e trazer os registros específicos ao buscas com as models mais específicas.

O colaborador tem todos os campos com exceção do campo parent_id já o dependente tem apenas o nome e o campo parent_id, importante notar que todo campo que é obrigatório apenas para uma entidade, não deve ser marcado como obrigatório no banco, isso torna o seu modelo de banco de dados um pouco mais frágil então a boa prática aqui é sempre manter a disciplina utilizando as mais altas abstrações para manipular os registros, evitar ao máximo alterar o banco diretamente, dessa forma pode ser muito interessante implementar até mesmo uma camada de serviços para as operações, na nossa versão de produção utilizamos serviços de forma opaca para cada operação que precisamos fazer, isso significa que salvo algumas exceções não chamamos a model diretamente.

O campo type é muito importante é ele que discrimina qual é o tipo do registro, é muito importante manter o preenchimento de campo de forma automática, para que não haja chance de esquecer em manipulações futuras.

<?php

namespace App;

use Illuminate\Database\Eloquent\Relations\BelongsTo;

class Dependent extends Participant
{
    use InheritanceLock;

    protected $table = 'participants';

    protected $hidden = [
        'active',
        'job_description',
        'department'
    ];

    protected $fillable = [
        'payroll_id',
        'parent_id',
        'name',
    ];

    public function employee(): BelongsTo
    {
        return $this->belongsTo(Employee::class, 'parent_id');
    }
}

A model de Dependent é bem parecida com a model Employee com a exceção de que ela declara o relacionamento contrário, ela pertence a um employee.

Bem interessante notar também a declaração do array $hidden ele omite esses valores ao retornar uma model de dependente, os campos omitidos são referentes ao colaborador e não devem ser exibidos nos registros de dependentes

<?php

namespace App;

use App\Scopes\InheritanceLockScope;

trait InheritanceLock
{
    public static function bootInheritanceLock(): void
    {
        $typeSetting = function ($model) {
            $model->type = self::class;
        };

        static::creating($typeSetting);
        static::saving($typeSetting);
        static::addGlobalScope(
            new InheritanceLockScope(self::class)
        );
    }
}

Você deve ter notado essa trait inserida nas models mais específicas, ela é responsável por preencher automáticamente o campo type e aplicar automáticamente o filtro pelo type em um Global Scope

O ciclo de vida e operações de uma model emitem eventos no Laravel, assim é possível escutar e declarar listeners para esses eventos, esse código declara um listener para os eventos de criação que preenche o campo type com self::class, esse é o nome da classe que "usa" a trait.

<?php

namespace App\Scopes;

use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Scope;

class InheritanceLockScope implements Scope
{
    protected $type;

    public function __construct(string $type)
    {
        $this->type = $type;
    }

    /**
     * Apply the scope to a given Eloquent query builder.
     */
    public function apply(Builder $builder, Model $model): void
    {
        $builder->whereType($this->type);
    }
}

Essa é a classe do global scope, a função de um global scope é adicionar uma condição cada vez que acontece uma consulta, nesse caso cada vez que retornarmos os registros do banco ele deve adicionar um WHERE type = "ModelName" na consulta, isso nos garante que nunca vamos trazer um dependente no meio de colaboradores e vice versa.

Dessa forma nossa implementação está completa, a seguir a utilização:

Como pode ser evidenciado no tinker criamos um colaborador e um dependente em sequencia e ao buscar os registros nas models específicas apenas os registros epecíficos são selecionados

Ao chamar a model mais generica conseguimos todos os registros

Os relacionamentos também funcionam como esperado

Conclusão

Conseguimos ver os seguintes pontos positivos na utilização dessa técnica de herança:

Existe apenas uma tabela para você se preocupar.
Você não precisa fazer joins e unions para retornar os registros em uma única tacada.
se você precisar adicionar um campo que ja existia em um tipo de model no outro tipo, não será necessário criar uma nova migração.
Somas são bem facilitadas

Mas também devemos nos preocupar com os seguintes possíveis problemas:

A confusão gerada ao olhar a tabela uma vez que alguns campos fazem sentido e outros não
Colunas utilizadas apenas por um subtipo podem gastar espaço atoa dependendo do banco utilizado.
A tabela pode acabar ficando muito grande e cheia de indexes, o que pode ser um problema de performance.
E principalmente, a modelagem fica mais frágil na parte do banco de dados.

Na nossa experiência colhemos bons frutos com a utilização da técnica, cabe a você avaliar seus ganhos e implementar, ou não.

Espero ter contribuido de alguma forma!!