Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - DrupalCamp Campinas 2016

209 visualizações

Publicada em

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

Publicada em: Software
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
209
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Total 11
  • Total 11
  • Total 11
  • Total 11
  • Total 11
  • Total 11
  • Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - DrupalCamp Campinas 2016

    1. 1. Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios Mayara Campos CIO Kickante Handrus Nogueira Diretor Comercial Taller
    2. 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. 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. 4. As vezes esse símbolo remete a lágrimas...
    5. 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. 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. 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. 8. Revisions Causa Raíz Drupal é despreparado para escalar revisões que necessitam permanecer armazenadas por longo período de tempo.
    9. 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. 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. 11. Diff Custo Descobrir o problema e arrumar as pressas Só que isso aconteceu 16 vezes!
    12. 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. 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. 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. 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. 16. Metamodelagem de banco e escalabilidade Custo 460 dias
    17. 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. 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. 19. Falhas de desenvolvimento… (não de desenvolvedor!)
    20. 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. 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. 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. 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. 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. 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. 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.
    27. 27. 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
    28. 28. 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...
    29. 29. 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
    30. 30. Acúmulo de problemas Causa Raíz Pressão por resultados em cima de um sistema instável e desconhecido. EXTREMA INCERTEZA
    31. 31. Acúmulo de problemas Solução Proposta Compartilhar prejuízos.
    32. 32. Vamos arrumar os problemas causados pelo Drupal?
    33. 33. Porque?? Compensa ter tanto trabalho?
    34. 34. 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.
    35. 35. 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!
    36. 36. 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...
    37. 37. Conclusão Quantos sites enfrentam problemas assim? 23.026 dias de desenvolvimento!!
    38. 38. Conclusão 15,22 anos De um time de 6 pessoas (sem gerentes).
    39. 39. 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!
    40. 40. Conclusão Vamos fazer algo a respeito?
    41. 41. 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??
    42. 42. Conclusão
    43. 43. Perguntas? Obrigado! Handrus Nogueira Diretor Comercial Taller @handrus handrus at taller.net.br https://br.linkedin.com/in/handrus https://branded.me/handrus

    ×