Post on 22-Jan-2018
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios
Mayara CamposCIOKickante
Handrus NogueiraDiretor ComercialTaller
Handrus
Floripa! -SC / BR
Business Developer / Consultant @ Taller
Web & Open-Source & Agile
~12 anos de estrada
Drupaleiro a ~8 anos
Dev with Passion!
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
As vezes esse símbolo remete a lágrimas...
Como vamos analisar os problemas?
DescriçãoO problema encontrado
Custo1 dia de desenvolvimento1 dia de consultoria = 2 dias de desenvolvimento
Causa RaizAonde começou o problema e como evita-lo.
Solução propostaResolução do problema de vez.
Revisions
DescriçãoO 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!
Revisions
CustoMapear 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)
Revisions
Causa RaízDrupal é despreparado para escalar revisões que necessitam permanecer armazenadas por longo período de tempo.
Revisions
Solução PropostaCurto 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)
Diff
DescriçãoNã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 usar3. Impossível fazer um dump ou gerar evidências textuais (arquivo
.diff seria muito a pedir?)
Diff
CustoDescobrir o problema e arrumar as pressas
Só que isso aconteceu 16 vezes!
Diff
Causa RaízInterface de diff nada amigável!Log é mais do que uma lista de usuário e data de alteração!Busca? Hein?
Diff
Solução PropostaCurto 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.
Metamodelagem de banco e escalabilidade
DescriçãoOne 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!
Metamodelagem de banco e escalabilidade
CustoTunar 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
Metamodelagem de banco e escalabilidade
Custo
460dias
Metamodelagem de banco e escalabilidade
Causa RaízMuuuuuuitas 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
Metamodelagem de banco e escalabilidade
Solução PropostaCurto 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!)
Falhas de desenvolvimento…
(não de desenvolvedor!)
Dependencia de variáveis de ambiente
DescriçãoVerificaçõ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.
Dependencia de variáveis de ambiente
CustoPesquisar alterações, gerar relatórios, encontrar evidências diretamente em Banco…
Imprevisibilidade - furos em estimativas, custo de oportunidade!
Dependencia de variáveis de ambiente
Causa RaízPressão para entregas rápidas.Falta de documentação e gerenciamento de débitos técnicos.
Dependencia de variáveis de ambiente
Solução PropostaCurto 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).
Más práticas
Descrição/CustoDuplicaçã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)
Más práticas
Causa RaízPressão por entregas.Codificar de madrugada.Falta de documentação e gerenciamento de débitos técnicos.
Más práticas
Solução PropostaDefinitiva: Remover módulos duplicados, atualizar módulos, verificação com módulo “Hacked!”. Muito trabalho. Retestar toda a aplicação.
Agenda
a. Necessidade de escaladas verticaisi. ⅓ do seu hardware (EC2 front e back) - 61ii. Máquina cron - 10,20iii. Instancia maior de RDS - 3 dias
b. Impossibilidade de escalari. Onde a kickante estaria se conseguisse manter o crescimento? - 209
1. Conclusão
Acúmulo de problemas
DescriçãoO 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...
Acúmulo de problemas
CustoConversas e reuniões com discussões intermináveis sobre prazo.
Reuniões e relatórios explicando atrasos.
Vendas perdidas (pelo cliente)
35x
Acúmulo de problemas
Causa RaízPressão por resultados em cima de um sistema instável e desconhecido.EXTREMA INCERTEZA
Acúmulo de problemas
Solução PropostaCompartilhar prejuízos.
Vamos arrumar os problemas causados
pelo Drupal?
Porque??
Compensa ter tanto trabalho?
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.
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!
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...
Conclusão
Quantos sites enfrentam problemas assim?
23.026dias de desenvolvimento!!
Conclusão
15,22 anosDe um time de 6 pessoas (sem gerentes).
Conclusão
Mas… e o Drupal 8?1. Mesmo modelo de revisions2. Mesma forma de usar diff3. Mesma meta modelagem4. Alto acomplamento (por enquanto)
= Mesmos problemas!
Conclusão
Vamos fazer algo a respeito?
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??
Conclusão
Perguntas?
Obrigado!
Handrus NogueiraDiretor ComercialTaller
@handrus
handrus at taller.net.br
https://br.linkedin.com/in/handrus
https://branded.me/handrus