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