Apresentação realizada por Handrus Nogueira (Taller) com participação de Mayara Campos (Kickante) na DrupalCamp Campinas 2016.

1. Os pecados mortais de escalabilidade em
Drupal e seus efeitos nos negócios
Mayara Campos
CIO
Kickante
Handrus Nogueira
Diretor Comercial
Taller

2. Handrus
Floripa! -SC / BR
Business Developer / Consultant @ Taller
Web & Open-Source & Agile
~12 anos de estrada
Drupaleiro a ~8 anos
Dev with Passion!

3. Somos um ateliê de negócios digitais que
transforma
ideias em projetos inovadores.
55 modulos
2 temas
710 commits em módulos
3 commits no Drupal 8 Core e 1 commit no Drupal 6 core.
http://oqueedrupal.org http://drupaldeelite.com.br
http://blog.taller.net.br

4. As vezes esse símbolo remete a lágrimas...

5. Como vamos analisar os problemas?
Descrição
O problema encontrado
Custo
1 dia de desenvolvimento
1 dia de consultoria = 2 dias de desenvolvimento
Causa Raiz
Aonde começou o problema e como evita-lo.
Solução proposta
Resolução do problema de vez.

6. Revisions
Descrição
O sistema de revisions do drupal adiciona um peso enorme ao banco
de dados e não é flexível.
1. Tudo ou nada - Todos os campos de uma entidade têm
revisões… ou nenhum deles tem revisões
2. Não existe uma forma simples de remover revisões antigas ou
criar regras para dizer que estão obsoletas
3. Crescimento linear do número de tabelas
Banco de dados lento, sistema lento, instancia de DB crescendo sem
parar!

7. Revisions
Custo
Mapear entidades que não necessitavam de revisions
Implementação de módulo, deploy, execução de scripts de deleção
em lote (de madrugada), pesquisa de solução
Infra-estrutura - Instancia de RDS acima do necessário (últimos 6
meses)

8. Revisions
Causa Raíz
Drupal é despreparado para escalar revisões que necessitam permanecer
armazenadas por longo período de tempo.

9. Revisions
Solução Proposta
Curto prazo: Field SQL No Revisions, script para deleção manual de
revisions.
Definitiva: Fields deveria ter a opção de permitir ou não revisions.
Implementar uma solução para deletar revisions integrada com
rules (deletar após x tempo, após alteração de status, definir
quantidade máxima de revisões no sistema etc)

10. Diff
Descrição
Não há um log listando usuário, data e alterações feitas que seja
amigável para buscas. Mudanças em field collections e entidades
relacionadas não são exibidas
1. Procurar alterações (para termos legais por exemplo) é difícil e
as vezes requer buscas diretamente em banco.
2. Logs nada amigáveis e interface dificil de usar
3. Impossível fazer um dump ou gerar evidências textuais (arquivo
.diff seria muito a pedir?)

11. Diff
Custo
Descobrir o problema e arrumar as pressas
Só que isso aconteceu 16 vezes!

12. Diff
Causa Raíz
Interface de diff nada amigável!
Log é mais do que uma lista de usuário e data de alteração!
Busca? Hein?

13. Diff
Solução Proposta
Curto prazo: Chorar?!
Definitiva: Armazenar “snapshots” das alterações em formato .diff.
Gerar um log mais extenso (autor de cada modificação por campo,
data, histórico por field) e repensar toda a interface! Blame seria um
ótimo começo!
Arquivar revisions e gerar diff em ferramentas especializadas.

14. Metamodelagem de banco e escalabilidade
Descrição
One size does not fit all!.
Só temos uma opção de metamodelagem padrão. Caso você queira
assumir o controle disse você deve declarar storage, tratar
persistência… para cada entidade, sem reaproveitamento!
Banco de dados lento, sistema lento, instancia de DB crescendo sem
parar!

15. Metamodelagem de banco e escalabilidade
Custo
Tunar mysql para *muitas* tabelas, joins, adicionar indíces.
Impossibilidade de gerar relatórios com ferramentas externas
otimizadas para isso
Combinar relatórios diferentes em ferrametas externas
294x
160x

16. Metamodelagem de banco e escalabilidade
Custo
460
dias

17. Metamodelagem de banco e escalabilidade
Causa Raíz
Muuuuuuitas tabelas, dados dificeis de mapear, estouro de memória pela
quantidade de joins.
PS.: Não estamos falando de exibir informações… estamos falando de BI

18. Metamodelagem de banco e escalabilidade
Solução Proposta
Curto prazo: Hook em entity save salvando dados em um DB
noSQL?
Definitiva: Deveria ser mais fácil declarar entidades com diferentes
storages, e estratégias de modelagem. Idealmente criariamos uma
interface extensível. A mesma classe implementando a interface
poderia ser reaproveitada em quantas entidades fossem
necessárias. (Hard Core! MUITO hard core!)

19. Falhas de desenvolvimento…
(não de desenvolvedor!)

20. Dependencia de variáveis de ambiente
Descrição
Verificações feitas em cima de strings que definem URL, arrays de
domínios, vset sem formulário administrativo etc
1. Subir um ambiente de dev, stage...
2. Criar uma solução whitelabel...
3. Alterar servidor, domínio, URL, senha, chave de integração etc.

21. Dependencia de variáveis de ambiente
Custo
Pesquisar alterações, gerar relatórios, encontrar evidências
diretamente em Banco…
Imprevisibilidade - furos em estimativas, custo de oportunidade!

22. Dependencia de variáveis de ambiente
Causa Raíz
Pressão para entregas rápidas.
Falta de documentação e gerenciamento de débitos técnicos.

23. Dependencia de variáveis de ambiente
Solução Proposta
Curto prazo: Arrumar às pressas. Documentar os débitos técnicos.
Definitiva: Negociar tempo para resolução de débitos técnicos.
Investir tempo e dinheiro nas resoluções.
Aumentar risco do projeto (X% a mais em estimativas).

24. Más práticas
Descrição/Custo
Duplicação de módulos
Diferenciação de módulos duplicados
Updates parciais de módulos (aplicar patches de diferentes versões,
ao invés de fazer o update)

25. Más práticas
Causa Raíz
Pressão por entregas.
Codificar de madrugada.
Falta de documentação e gerenciamento de débitos técnicos.

26. Más práticas
Solução Proposta
Definitiva: Remover módulos duplicados, atualizar módulos,
verificação com módulo “Hacked!”. Muito trabalho. Retestar toda a
aplicação.

28. Agenda
a. Necessidade de escaladas verticais
i. ⅓ do seu hardware (EC2 front e back) - 61
ii. Máquina cron - 10,20
iii. Instancia maior de RDS - 3 dias
b. Impossibilidade de escalar
i. Onde a kickante estaria se conseguisse manter o crescimento? - 209
1. Conclusão

29. Acúmulo de problemas
Descrição
O time de desenvolvimento fica com medo de estimar.
O comercial fica com medo de passar um prazo.
O cliente precisa reservar budget… logo ele precisa de uma
estimativa e um prazo...

30. Acúmulo de problemas
Custo
Conversas e reuniões com discussões intermináveis sobre prazo.
Reuniões e relatórios explicando atrasos.
Vendas perdidas (pelo cliente)
35x

31. Acúmulo de problemas
Causa Raíz
Pressão por resultados em cima de um sistema instável e desconhecido.
EXTREMA INCERTEZA

32. Acúmulo de problemas
Solução Proposta
Compartilhar prejuízos.

33. Vamos arrumar os problemas causados
pelo Drupal?

34. Porque??
Compensa ter tanto trabalho?

35. Conclusão
Quantos sites enfrentam problemas
assim?
365.039 sites feitos em Drupal 7.
576.399 sites feitos em Drupal.
604 entre os 10k maiores sites do mundo.

36. Conclusão
Quantos sites enfrentam problemas
assim?
Vamos assumir que… menos de 0,1% dos sites enfrentem
problemas parecidos, causados pelo Drupal (vamos deixar erros de
customização/extensão do Drupal).
58 sites!

37. Conclusão
Quantos se gasta com problemas assim?
Vamos assumir que… esses sites tenham tido somente metade dos
custos que tivemos.
(794 dias de Dev/2) * 58...

38. Conclusão
Quantos sites enfrentam problemas
assim?
23.026
dias de desenvolvimento!!

39. Conclusão
15,22 anos
De um time de 6 pessoas (sem gerentes).

40. Conclusão
Mas… e o Drupal 8?
1. Mesmo modelo de revisions
2. Mesma forma de usar diff
3. Mesma meta modelagem
4. Alto acomplamento (por enquanto)
= Mesmos problemas!

41. Conclusão
Vamos fazer algo a respeito?

42. Conclusão
Vamos fazer algo a respeito?
1. Sua empresa investiria?
2. Você investiria (tempo ou dinheiro)?
3. Vamos organizar hackathons, grupos, mentorias…?
4. Vem pra Kickante! Vem pra Taller! Vem pras iniciativas
virtuais!
5. Crowdfunding??

43. Conclusão

44. Perguntas?
Obrigado!
Handrus Nogueira
Diretor Comercial
Taller
@handrus
handrus at taller.net.br
https://br.linkedin.com/in/handrus
https://branded.me/handrus