Olhando para o Redis: somos mesmo desenvolvedores que inventam coisas?

Ao olhar para o ecossistema do Redis, volto a pensar se posso realmente dizer com convicção que sou um desenvolvedor que inventa coisas.

O nascimento do armazenamento Key-Value

• A partir dos anos 2000, com a era da Web 2.0, empresas de serviços web passaram a enfrentar a necessidade de suportar um número enorme de usuários
• Para aguentar esse tráfego gigantesco, tornou-se necessário um sistema distribuído em larga escala, pequeno e barato, em vez de um servidor grande e parrudo
• Felizmente, a maioria das estruturas de dados era simples (ex.: buscar informações de userid = 1234)
• Usar um banco de dados relacional (RDBMS) era pesado demais, caro demais e complexo demais
• Surge o teorema CAP
• Então, mesmo abrindo mão da consistência, dava para priorizar disponibilidade e velocidade
• Nasce um banco de dados simples que, ao receber uma key, devolve um value (Memcached-2003, Amazon Dynamo-2007)

O nascimento do Redis

• Na Itália, terra do macarrão, um desenvolvedor chamado Salvatore Sanfilippo tocava uma startup chamada LLOOGG (sim, o nome de log está mesmo com duas letras duplicadas)
• A LLOOGG oferecia um serviço de rastreamento em tempo real de visitantes de sites
• Era pequena, mas tinha usuários reais
• Na época, análise em tempo real era um trabalho bastante difícil
• Os dados começaram a se acumular → o RDBMS existente foi ficando cada vez mais lento → a responsividade em tempo real deixou de existir
• Para ter resposta em tempo real, era preciso usar memória → o Memcached na época só suportava GET e PUT simples em formato de string
• Precisava de funções de dicionário um pouco mais avançadas, como INCR, DECR e LIST, mas não existia um banco assim? → porra, então eu mesmo faço
• Nasce a versão inicial, rodando sobre um servidor TCP ultrassimples (sem recursos avançados como cluster, AOF ou replicação)

A evolução do Redis

• O Redis não nasceu com o objetivo de ser um cache, e sim um armazenamento de estruturas de dados para processamento em tempo real
• Mas as pessoas começaram a usá-lo como cache
• As demandas por estruturas de dados que iam além de cache por parte dos gigantes existentes (Facebook, Twitter, GitHub, Stack Overflow etc.) aumentaram
• A adoção começou de forma gradual, com pequenas funcionalidades como armazenamento de sessão, gestão de tokens de login, contadores em tempo real, sistemas de ranking e número de likes
• Os diversos recursos necessários e estruturas de dados foram sendo adicionados de forma evolutiva (Sorted Set, HASH, Cluster, persistência...)
• E ele acabou se tornando uma plataforma flexível de processamento de dados

Comunidade, UX e a filosofia do desenvolvedor

• O Redis se baseia na filosofia de que mesmo com muitos recursos, não deve ser complexo
• A documentação oficial oferece exemplos executáveis imediatamente com base em CLI e explicações claras de funcionamento
• Os comandos intuitivos (SET, GET, LPUSH, ZADD, HGETALL etc.) permitem entender rapidamente sua função só de bater o olho na documentação oficial
• Essa intuitividade vai além da simples conveniência: ela reduz a barreira psicológica em relação à ferramenta e aumenta a produtividade dos desenvolvedores
• A versatilidade que surge dessa estrutura beneficia usuários, provedores de nuvem e contribuintes de open source
• Em um ecossistema composto pelos interesses de todos, o Redis se consolidou como padrão de fato dos bancos de dados in-memory por meio de uma escolha não forçada

Olhando para o ecossistema do Redis

• O Redis começou como um meio de implementar a análise em tempo real de visitantes, uma ideia talvez até comum
• Superou as limitações da abordagem existente chamada SQL (lenta e cara) com uma nova abordagem
• Não foi uma otimização das regras existentes, como explorar networking do setor, espremer fornecedores, tuning de hardware ou limitar uso
• Foi a criação de uma nova regra: transformar a memória no elemento central do banco de dados
• Para projetar a ferramenta com as próprias mãos, propor um fluxo que não existia antes e fazer o mundo inteiro adotá-lo, o conhecimento fundamental para aplicação é importante
• Basta olhar para o Amazon Dynamo, projetado para resolver o problema de armazenamento de carrinho de compras: foi preciso aplicar conhecimento complexo de sistemas distribuídos
• Quando algo se torna um padrão da indústria por escolha voluntária de todos, gera-se um enorme valor agregado e muitos empregos
• Dá para perceber isso ao ver profissionais especializados em Redis, infraestrutura de hardware, conteúdo educacional, serviços gerenciados (AWS, Azure) e soluções especializadas (Redis Enterprise)
• Nada disso foi criado por políticas públicas ou leis do tipo “salvar tal indústria” ou “ajudar pequenas e médias empresas”

Precisamos refletir se ainda não estamos vivendo com uma mentalidade da era industrial, embora por fora pareçamos um país desenvolvido, e confundindo desenvolvedores com trabalhadores da indústria de serviços de conhecimento.

• Conseguimos provar com resultados por que tecnologia fundamental (ex.: algoritmos) é importante?
• Temos uma cultura de desenvolvimento e um sistema educacional capazes de formar desenvolvedores que sabem criar ferramentas para resolver problemas?
• Todos dizem que é preciso cultivar uma cultura que tolere falhas, mas eu mesmo não fico com raiva ou xingo quando outra pessoa comete um erro?
• Entendemos de verdade o valor agregado da indústria de serviços de conhecimento e conseguimos insistir nisso com persistência?

Volto a gravar na mente que um desenvolvedor de verdade não é apenas alguém que sabe usar bem ferramentas, mas alguém que, ainda que de forma imperfeita, projeta por conta própria as ferramentas de que precisa e as torna fáceis para que outros também possam usá-las, expandindo o ecossistema e gerando valor agregado.

[roxie]

Acho que sou uma fraude também T_T

[iolothebard]

A invenção da utilidade…