Desenvolvimento, Gestão, Arquitetura de Software, Estratégia, Cultura, Devops e afins
O post desvela não apenas uma metodologia técnica, mas uma visão filosófica sobre a construção de sistemas distribuídos. Os princípios fundamentais de transferência de estado, a linguagem universal do HTTP e a aplicação do conceito HATEOAS não apenas conectam sistemas, mas redefinem a própria essência da interconectividade digital. Além disso, o Modelo de Maturidade de Richardson oferece uma bússola, que embora questionável ela é didática, guiando as implementações.
O entendimento do TCO (Total Cost of Ownership) não apenas traz visibilidade para os custos completos de um ativo de TI, mas também estende sua utilidade a diferentes setores e ativos empresariais. Assim, ao identificar os custos contínuos associados à manutenção, treinamento, atualizações e outros, as organizações podem tomar melhores decisões. Além disso, a compreensão das distinções entre CAPEX e OPEX, bem como o impacto sobre o ROI, fornece uma visão holística dos investimentos e custos operacionais. Portanto, adotar uma abordagem abrangente do TCO oferece meios para otimizar investimentos, reduzir custos desnecessários e aumentar o valor a longo prazo, contribuindo para uma gestão financeira mais eficaz e sustentável.
À medida que exploramos os meandros da otimização prematura, torna-se evidente que essa prática pode ser uma armadilha sutil que pode prejudicar mais do que beneficiar o desenvolvimento de software. Infelizmente nem sempre a vaidade dos desenvolvedores se atém a isso. O renomado cientista da computação Donald Knuth nos alerta que a otimização prematura é a raiz de todos os males, destacando a importância de evitar decisões precipitadas e buscar um entendimento completo dos requisitos do projeto.
O Hadoop é o pai do bigdata. Ele possui um ecossistema próprio com diversas ferramentas com propósitos diferentes. Aqui em Top 25 Ferramentas do Hadoop vamos dar uma visão geral sobre diversas dessas, tais como Hive, Pig, Sqoop, Kafka, Zookeeper. Note que nem todas essas ferramentas são dependentes do Hadoop, mas são relevantes para o ecossistema e por isso aparecem na lista.
O Apache Spark atualmente é a principal ferramenta na computação distribuída quando o assunto é bigdata. Diferentemente do passado hoje há um mercado muito vibrante com concorrentes, mas não tiram o brilho desse. Ele suporta linguagens de programação diferentes, algo fundamental para atrair programadores, engenheiros ou cientistas de dados. Suas estratégias internas são rebuscadas, como é o caso da LazyEvaluation e suas DAG’s criadas sob medida. Além disso ele possui diversas bibliotecas públicas ao invés do tooling do Hadoop que tinha uma manutenção complicada. O artigo Entendendo o Apache Spark explora um pouco de tudo isso.
O Hadoop materializou o conceito de bigdata e modificou toda a forma em que o mercado encara os dados. Ele tem uma arquitetura muito bem feita para suportar grandes volumes. Ele possui um sistema de arquivos distribuidos, o HDFS, que lida com esse problema. Além disso há o map-reduce que em alinhamento com o HDFS produz cálculos em massas inacreditáveis de dados: Ainda que utilizando vários computadores de desempenho mediano. Por fim o Yarn possibilizou uma maior extensibilidade do produto, dando abertura para novas ferramentas como o Zookeeper, Pig ou Spark. O Essencial do Hadoop dá uma visão panorâmica sobre o produto além de pequenos exemplos.
Ambas as arquiteturas são capazes de lidar com dados massivos, volumosos etc. com características particulares. O uso da Lambda é o mais popular, mas que exige mais tecnologias envolvidas, tem uma manutenção mais difícil; ao contrário da Kappa que simplifica tudo, porém pode não ter o histórico dos dados. Como de costume, trata-se de analisar um caso em específico para saber qual arquitetura se parece mais adequada.
Em resumo há muitos bancos de dados. Alguns deles existem há muito tempo mas se popularizaram a partir de 2010 para suportar o aumento crescente dos dados, das variedades dos dados e das arquiteturas emergentes. O Teorema CAP é uma estratégia para pensar em como selecionar bancos de dados para as arquitetura que se apresentam.
Nada impede de amanhã um novo tipo de banco de dados ganhar força, tendo em vista a variedade de dados que é crescente nos tempos atuais. Note que alguns desses bancos suportam múltiplos conceitos ao mesmo tempo. Mas ao final de tudo, analise com cuidado considerando as necessidades tecnológicas, as necessidades de negócio/custo, e as capacidades do time na hora de decidir por utilizar um tipo ou outro.
O artigo Notification Pattern no DDD é interessante mas levanta algumas questões importantes sobre o design de código. Não é raro encontrar desenvolvedores defendendo que ele deveria ser utilizado para tudo eliminando o uso de exceptions. Por outro lado, há uma outra corrente que usa exceptions para todas as validações de negócio. Particularmente prefiro um caminho intermediário, utilizando as exceptions que interrompem o fluxo do código quando isso é fundamnetal, caso contrário entidades poderiam ficar não estáveis. Mas também utilizando o notification pattern para validações simples de entidades e quando há a construção de entidades complexas. Bom, o artigo mostrou exemplos e sobrevoou essa polêmica.