Então você se deparou com a necessidade de tomar decisões e está inseguro? Será que alguém já fez aquilo que você está pensando? Será que sua decisão é uma gambiarra ou não?
Bom, eu já me questionei sobre isso diversas vezes, e algumas decisões difíceis de fato já tomei com meus times ou sozinho em algum momento. Mas hoje em dia, com a quantidade de informação disponível, há boas chances de alguém no mundo ter passado pela mesma indecisão e mesmo problema. Talvez ela tenha pesquisado a respeito e não tenha achado nada quando precisava tomar uma decisão, também é provável que ela tenha pensado: Putz, tenho algo único aqui, deixa eu transformar em post e quem sabe posso ajudar alguém?!
Me chamaram de louco
Se eu te contar que eu já usei o MongoDB para armazenar XML você me chamaria de louco? Me chamaram assim na época, chamaram de “uma puta gambiarra”. Bom, na verdade não era realmente um XML que eu armazenaria no MongoDB, mas tudo havia começado com um XML.
Era uma integração onde cada arquivo de integração, um XML, era um mini database. Com todos os dados de uma música… TODOS! De compositor a staff, dependendo do cenário. Existia um standard internacional chamado DDEX, com umas 10 variantes (a cada 2 ou 3 meses saia uma versão nova, com um detalhinho novo). Toda a integração de conteúdo dependia desse formato. Formato ruim, complexo, e criar um parser também era algo inviável, principalmente pelo tamanho do projeto. Mas tentamos! Esse parser era parte da importação de conteúdo, e deveria ser algo simples, pequeno, mas com esse formato seria algumas vezes maior que a importação em si. Só para modelar banco, gastamos 15 dias para modelar mais de 100 tabelas e ao final não tínhamos nem 50% de um das N variantes.
As necessidades a respeito dessa integração eram poucas porém complexas:
- Realizar queries nesses metadados
- Indexar o Conteúdo
Lembra, era um XML, que eventualmente poderia chegar a 1 mega.
A solução
- Eleger uma das variantes do DDEX como principal
- Criar um parser XSLT para transformar variantes no formato eleito
- Criar um conjunto de classes que expressasse esse modelo, com base no XSD
- Deserializar o XML e serializar como JSON para armazenar no MongoDB
Resultado
Pronto. Simples assim! Todo o problema com codificação do parser foi eliminada na medida que gerei as classes com base em um XSD eleito. A confiabilidade desse tipo de solução é altíssima, e usado recorrentemente há pelo menos uma década (na época, né). Toda a dor de cabeça com as consultas, deixaram de existir. Isso abriu espaço para que pudesse me importar com o que realmente era relevante, a importação de dados em si.
Se não pareceu simples, vou te dar algumas dicas:
- Gerar classes a partir de um XSD é incrivelmente simples, e temos ferramentas aqui na plataforma .NET para fazer isso pra gente. Independente do tamanho do teu XSD, em menos de 5 minutos, todas as classes estão geradas. Você pode até levar umas 2 horas achando os parâmetros adequados para gerar exatamente como quer, mas é simples assim.
- Uma vez que você consiga desserializar um XML em instâncias de suas classes, colocar isso no mongo é ridiculamente simples.
- A propósito, uma vez no mongo, você tem uma infinidade de possibilidades de consultas, e de forma bem simples. É incrível como fica objetivo.
Riscos Técnicos: Tomar ou Declinar?
A forma fácil é: Você não deveria ter de tomar um risco. Mas a gente sabe que nem sempre isso é estratégico. O que quer dizer que eventualmente há situações em que você precisa tomar decisões, e estas decisões implicam em riscos.
A segunda forma de escolher tomar um risco em um projeto técnico é analisando as assimetrias entre ganhos e perdas. Em uma visão mais conservadora, a melhor você opta pela maior assimetria, desde que haja substituto que reduza a perda. Vamos ao exemplo do CosmosDB como um MongoDB. Teu risco pode, eventualmente ser o custo, mas em contrapartida você pode gerenciar suas próprias instâncias MongoDB, caso se confirme seu risco. Diferente do DynamoDB, da Amazon, onde se você escolher deixar de usar a solução deles, terá um custo de desenvolvimento elevado pela necessidade de manutenção, já que não há drop-in replacement para ele. Outro exemplo é o ElasticBeansTalk vs Kubernetes. Aliás…
Kubernetes, por exemplo, é um game changer quando se diz respeito à assimetria entre perdas e ganhos. Com ele você pode ir para qualquer cloud, ou mesmo usar uma infra sua, e isso tudo acontece de forma transparente para sua aplicação. Portanto você pode com 500 reais mensais ter sua primeira infra K8S na nuvem.
Outra forma de analisar riscos é entender quem está usando uma solução. Isso se chama prova social, isso facilita muito a tomada de decisão. Por exemplo, veja quais são os grandes players que investiram tempo e dinheiro para implantar Istio, Docker, Redis, RabbitMQ, avalie quem está usando e a quantidade de grandes nomes é um bom indício de que aquilo funciona. Pode até ser que você queira usar solução certa para o problema errado, mas a qualidade e confiabilidade embora não possa ser aferida, há bons indícios que sustentam uma decisão técnica a favor dela quando grandes players estão usando.
Afinal, onde encontrar soluções e ideias?
Bom, se você busca solução de problemas e ideias, o principal ponto de partida é o google. Mas calma, eu não escrevi esse texto todo para te mandar ir para o Google assim. Tenho alguns sites relevantes de acordo com o contexto.
Se você estiver buscando cases de escalabilidade, tem muita coisa publicada aqui no http://highscalability.com/
Se você estiver buscando stacks, e caçando plausibilidade a partir de quem está usando esse stack ou um elemento qualquer para adicionar ao seu stack, minha dica é o https://stackshare.io
Aproveitando que estamos falando do stackshare, temos uma novidade: o StackShare Decisions, área do site destinada a catalogar decisões. O link é esse https://stackshare.io/feed
Se falarmos principalmente sob a perspectiva de APM (Application Performance Management) temos o Open APM, que apresenta um landscape com todas as principais soluções open source para de apm, o link está aqui https://openapm.io/
Seguindo a mesma linha do Open APM, também mostrando um landscape, temos o CNCF (Cloud Native Computer Foundation) destinado a soluções Cloud Native, o link está aqui https://landscape.cncf.io/ há um menu na esquerda para você selecionar a categoria, são várias categorias, todas relacionadas a Cloud Native.
Gostei bastante do artigo, e ressalto que risco fazem parte da vida de um arquiteto ou gerente técnico. Analisar como outras pessoas resolveram o mesmo problema é muito bom, mas o profissional não pode se deixar levar apenas pelos caminhos dos outros, ele deve analisar bem as variáveis que possui em mãos no momento. Eu mesmo, uso AWS, e hoje tomamos a decisão de usar várias ferramentas deles, por ganhar na velocidade de implementação, e por ver que em pelo menos médio prazo, não vamos mudar. Aí, caso lá na frente, a direção resolva mudar, já sabemos de antemão qual vai ser o custo da mudança. E obrigado por compartilhar seu conhecimento e os links, alguns deles eu não conhecia! Mais uma vez, parabéns!
Obrigado Denis, e sim, você está super certo no seu ponderamento. A questão é que muitas vezes rola uma puta insegurança na hora de fazer algo que não é “padrão”. Qual o limite entre adaptação e gambiarra? Nesse caso específico do DDEX, eu pesquisei muito e não achei ninguém fazendo, passei muito tempo analisando, vendo pontos negativos, tentando invalidar, por mais que sozinho, minha própria solução. Até chegar em algum momento e dizer: Eu não achei pontos negativos a não ser o fato de ser um uso exótico para a tecnologia.
Outro ponto que ajudou a me resguardar foi o fato de ter feito isso como adição ao processo, isso quer dizer que os arquivos raw continuavam lá, e se algo desse errado, eu teria como pensar em alternativas, já que os arquivos continuavam por lá. Mas foi muito desconfortável tomar aquela decisão em um ambiente em que eu não tinha como trocar, debater, não havia que pudesse olhar para o problema e para a solução com um ponto de vista mais racional e menos emocional.
Ali, quem havia ouvido falar de NoSQL nunca havia visto implementações assim, e de fato eu também não, mas os fundamentos por trás de cada coisa faltavam na maioria.