Pular para o conteúdo principal

Arquitetura evolutiva no Qual Canal

Ontem eu falei de Arquitetura Evolutiva, então nada melhor que dar um exemplo de como isso já ocorreu comigo na prática. Já que nos últimos anos estive trabalhando no Qual Canal, vou usá-lo como exemplo, mas isso já aconteceu comigo em diversos outros sitemas e serviços. Para quem não conhece, o QC é uma ferramenta que fornece inteligência em cima dos comentários presentes nas redes socias sobre programas de televisão.

Quando comecei no projeto ele já possuía um código existente. Consistia em um protótipo feito pelo Farinha e Anderson para experimentar como tratar os dados do twitter. Este protótipo já realizava a coleta de dados, inseria em uma base MySQL e gerava um ranking, usando Django. Para quem conhece um pouco de processamento de Big Data sabe que essa não é uma arquitetura ideal esse tipo de serviço. Talvez para alguém mais versado no meio, a primeira decisão seria de jogar esse protótipo fora e começar algo mais robusto. Porém, esse protótipo atendia perfeitamente a nossa necessidade na época. Essa era de validar como agregação em ranking influenciava o público, então eu decidi usar aquele código como base para continuar os trabalhos.

Essa decisão permitiu que tivéssemos um foco maior na formatação dos dados e como o usuário interagia com ele. Essa era a decisão mais barata naquele momento, pois esse era nosso foco de aprendizado na época. Apesar disso, eu não estava disposto a deixar o sistema com jeitão de protótipo. Minha experiência mostra que esse tipo de dívida cobra juros caros no futuro. Por isso, decidi também investir em dois ajustes que considerei cruciais. Primeiro, em separar o consumo [e agregação] de dados sociais da interface web. Dessa forma permitindo que o back-end fosse independente de como nosso usuário fosse interagir com os dados. Segundo, criar um conjunto de testes para me proteger de mim mesmo de besteiras que eu pudesse fazer, e possibilitar nosso deploy contínuo. Nesse ponto, comecei criando os casos para as funcionalidades mais importantes já existente, enquanto garantisse que as novas fossem sempre cobertas.

Esta estrutura permitiu que o aprendizado evoluisse de forma gradativa por diversos meses, com a inclusão de diversas funcionalidades. Até que sofremos a primeira cobrança por não seguir uma arquitetura de Big Data. Naquele momento, nós tínhamos passado de alguns milhares de registros por dia, para esporádicos milhares por minuto. O que fazia nossa estrutura "congelar" por diversas horas. Converter nossa arquitetura para se adequar parecia muito caro. Nossa decisão foi de quebrar o processo de tratamento em vaŕias fases, além de multiprocessá-lo (além de alguns truques na base de dados). Com isso, conseguimos manter a mesma base de código e chegar no patamar que desejávamos. Além disso, com uma estrutura multiprocessada podíamos distribuir - mesmo que rudimentarmente - em diversas máquinas, conforme a necessidade.

Essa estrutura durou mais de um ano sem apresentar problemas. Tempo esse que permitiu que muito aprendizado ocorresse. Inclusive tendo uma nova troca no mercado atendido pela ferramenta, além das formas agregação, interface e fontes de dados coletados. Neste tempo, a maior parte do esforço foi gasto no front-end e no auxílio da administração da ferramenta. Tarefas que a estrutura com Django/MySQL atendia perfeitamente bem.

Mas nem tudo são flores, como era esperado, chegou o momento em que nossa escala de comentários tornou-se um gargalo novamente. Dessa vez, precisávamos que nosso ritmo de processamento saltasse para dezenas de milhares por minuto, em tempo real. Realizamos diversos testes e vimos que não tinha mais "truques baratos" a nossa disposição, era a hora de ir para a famigerada arquitetura de Big Data. Fizemos alguns experimentos e decidimos por usar o Apache Storm¹ com Cassandra. Já era esperado que migração saísse caro, e para minimizar esse custo ela foi realizada em passos, migrando um elemento por vez (comentários, contagens, agregações). Isso permitiu que mantivéssemos ambas as estruturas rodando juntas, avaliando o desempenho e resiliêncoa. Isso durou seis meses, até que o processamento em Python fosse completamente desligado. Apesar dessa mudança, a interface e administração permaneceu em Django/MySQL onde esta tecnologia brilha.

Hoje a produto passa por mais um ajuste de mercado, porém esta estrutura se mantém. Mas o que fica dessa história é que, apesar da arquitetura de Big Data ser a resposta certa desde o início, ela não era a mais adequada para o caso. Ser capaz de adiar essa decisão (e custo) por alguns anos permitiu que muito aprendizado ocorresse, antes que ela se provasse realmente necessária. Aprendizado este que foi muito importante não apenas para o negócio, mas para se amadurecer em como a tecnolgia podia realmente contribuir para ele.

Bem, até aqui eu contei como entregar a solução mais barata foi interessante. Mais ainda por que o pessoal que cuida do negócio adora receber funcionalidades baratas e rápdas. Mas ontem eu também falei que deletar código era igualmente importante. E aí que entra um novo desafio. Se essa tarefa já é difícil pra desenvolvedores, imagina pra quem está de olho no mercado. A primeira vez que eu sugeri que a gente retirasse uma funcionalidade da nossa base de código, ocorreu o drama já esperado. Um medo de que isso representasse uma perda de difícil remediassão. Bem como o velho questionamento "Não dá só pra desabilitar? Deixar comentado?".

Pois bem, eu tinha que educar essa prática e isso veio claro quando estávamos na primeira mudança de mercado. A sugestão foi de se livrar de tudo de interação com usuário que não estava relacionado com o novo cliente. Pra deixar os demais mais tranquilos, assumi a responsabilidade de voltar com as funcionalidades de maneira rápida, se elas se provassem úteis no futuro. Mesmo asism ouve receio, o que levou aceitar a remoção completa, menos o ranking (filho histórico do sistema). Passou-se um tempo e a aposta se pagou, nenhuma das funcionalidades foi ao menos cogitada de retornar. No fim, até mesmo o ranking acabou conhecendo seu destino no /dev/null. Com isso, a empresa ganhou aprendizado, e eu (e gerações futuras) me livrei de um legado pra cuidar.

¹ Hoje eu trocaria a escolha do Storm pelo Akka devido a sua maior flexibilidade de deploy. Mas a decisão se mantém funcional e estável. Quem sabe esse custo se justifica em no futuro.

Comentários

Postagens mais visitadas deste blog

A experiência de software

Hoje em dia está muito em voga se falar sobre o desenvolvimento de produtos e serviços de software. Sendo assim as iniciativas e startups estão alta. Mas para quem está no mercado de Brasília (e de alguns outros centros do país) como eu, sabe que a prestação de serviços nas famigeradas "Software Houses" ( me recuso a chamar de Fábricas de Software ) é bem comum. Porém, este trabalho costuma ser renegado ou, como eu vejo, tratado sob um ponto de vista um pouco equivocado. Uma fábrica de software artesanal Onde se enganam tais pessoas é em que elas estão vendendo. Muitas empresas acreditam, de fato, que vendem software. Eu porém digo que isso é não de todo verdade. Se você é um prestador de serviços e constrói software sob demanda, você não vende apenas o software. Aqui não me refiro aos milhões de outros "artefatos" que são empurrados goela abaixo entregues aos nossos clientes. O que vejo é que vendemos algo que não está limitado ao software que vai pra mão (ou se

Formando pessoas desenvolvedoras na bxblue

Eu sempre fui apaixonado por ensinar. Trabalho com a formação e ensino desde 2003, indo desde o ensino das bases de computação até lecionar em cursos de pós-graduação. Estar no dia-a-dia com pessoas que estão no começo da carreira é um mix de satisfação e desafio. Satisfação por você ter a oportunidade de contribuir com um pedacinho tão especial da história daquela que será uma pessoa desenvolvedora no futuro. Desafiadora pelo fato de precisarmos nos despir de aprendizados já superados em nossas mentes e nos esforçamos por enxergar novamente pelos olhos de quem ainda não tem a mesma vivência que você. Por onde passei, eu sempre acreditei que um bom equilíbrio entre profissionais experientes e em formação é a melhor combinação para um time de tecnologia. Isso é benéfico não apenas para a retenção, como também é estímulo para uma cultura de aprendizado e humildade. Cultura essa que favorece o compartilhamento e interação não apenas entre quem faz o software, mas também as demais áreas da

WorkChopp Intacto

Olá pessoal! Sou o @andersonfer_ e tô invadindo o blog do Fabricio pra contar sobre um evento muito legal que organizamos na @IntactoSoftware . Como eu ainda não tenho blog (shame on me), pedi permissão pra falar por aqui! Espero que gostem! Depois do #agileBR , todos nós voltamos naquela vontade de distribuir o conhecimento adquirido lá entre toda galera. Então tivemos a ideia de organizar um workshop baseado em uma dinâmica que eu assisti, apresentada pelo Emilio Gutter e pela Alejandra Alfonso . Eu sempre fui muito favorável às dinâmicas, jogos e afins pq acho que têm um poder muito grande de quebrar as resistências das pessoas e fazê-las enxergar os benefícios das metodologias e técnicas ágeis para além dos contextos e projetos em que estão inseridas e consequentemente tentar aplicar esses conceitos no seu dia-a-dia. Optamos por relizar a dinâmica Construindo A Cidade Ágil. Os 2 grupos tinham à disposição papeis coloridos, tesoura e cola pra construir, em 4 sprints de 3 min