Se você está nesse planeta ativo em alguma comunidade deve ter percebido que todo dia surge uma nova solução que dizem que devemos usar. Docker, Kubernetes, Redis, Jaeger, Helm, RabbitMQ, Kafka, ELK, Kong, NGINX, Traefik, Keycloak, Jenkins, SonarQube…

onde isso vai parar?

Como deixamos chegar nisso?

Isso é para vender cloud? Para vender curso?

É sobre isso que vamos debater hoje.

Tudo era baseado em tabelas

Essa era como o mercado fazia durante toda a década de 2000.

Naquela época era comum que os grandes investimentos fossem alocados em grandes clusters de bancos de dados, na Petrobras era um Oracle gigantesco para a época.

E outros clusters menores para as aplicações.

Poucas eram as soluções disponíveis no mercado, além de bancos de dados e plataformas/linguagens.

Autenticação e Autorização com tabelinhas

Em 2002 quando cheguei no mercado profissional, entrei na Petrobras e me deparei com um sistema para dar manutenção. Na semana de capacitação havia aprendido que existia um sistema de controle de acesso corporativo. Uma ferramenta que lidava com as permissões dos usuários sobre recursos de sistema e sobre dados.

A autenticação era feita com o Windows nos desktops e notebooks, a autenticação era propagada para o IIS, via Internet Explorer e faltava somente programar as chamadas ao controle de acesso para que ele lidasse com a autorização.

Fazíamos pergunta-a-pergunta a ele, ao longo de um request. Em alguns casos, diversas vezes.

Essa era a solução da Petrobras, com mais de 20 mil funcionários ativos na época.

Cheguei a trabalhar no CA (Controle de Acesso) por algum tempo antes de sair.

Bom, essa era a solução para autenticação e autorização da empresa, assim como ela, milhares de outras empresas criaram suas próprias soluções.

Eu não estou falando de framework corporativo, estou falando de serviços infraestrutura corporativos.

Muitas empresas não usavam essa integração do AD com o IIS, e implementavam autenticação na mão, com tabelas de usuários etc.

Cache com tabelinhas

Usávamos o banco de dados para produzir cache de dados do banco de dados.

Calma, não é tão louco assim, mas poderíamos evitar consultas complexas com muita carga, pré-processando esses dados.

Me recordo de ter feito, mas dessa vez eu não me recordo o momento exato. Mas me recordo de já ter criado uma tabela no sql server contendo colunas de chave-valor, para 2 finalidades: Cache e Configuração. Cada uma em momentos distintos. No próprio Controle de Acesso Petrobras, tínhamos uma tabela no Oracle dedicada à cache.

Era uma estrutura rudimentar sem TTL, por exemplo.

Filas com tabelinhas

Outra solução típica, é a utilização de tabelas para implementação de filas.

Em muitas implementações o conceito de fila era pautado em queries que analisavam status, datas e associações para determinar cargas de trabalho a serem processadas.

Não era incomum encontrarmos jobs nos bancos de dados para solucionar essas questões. Esses jobs chamavam procedures.

Aliás, muito código em procedure era produzido nessa época sob o pretexto de ser o melhor lugar e o mais otimizado.

Esse primeiro desenho é o desenho de jobs pautados em estados. Um estado mágico nasce e daí, a partir dele, damos vasão ao fluxo de negócio.

Havia também casos muito longínquos em que novas tabelas eram criadas, sem conexão direta com o dado de negócio. Tabelas exclusivamente usadas para filas.

Aqui já temos uma evolução para um mecanismo independente. De certa forma, se bem abstraído, poderia dar lugar a ferramentas de MQ, no banco ou fora dele. Mas era uma exceção. No início de século, JSON não era tão comum e XML era o padrão.

Log com tabelinhas

Quantas e quantas empresas em que vi tabelas destinadas a Logs. Alguns casos mais sofisticados usavam também para fazer auditoria, monitorando mudanças de estado.

Quantas vezes vi reclamações e mais reclamações de falta de espaço em banco, de necessidade de alocação de mais infra, mais disco, para conseguir atender as demandas de log.

Para quem só sabe usar o martelo,
todo problema é prego!

Viva o SGDB!

Durante muito tempo, resolvíamos tudo com o SGDB. Todo problema era resolvido com algumas tabelinhas. Durante um bom tempo eu também resolvia meus problemas assim.

Experimentamos a evolução dos bancos de dados que tinham essas demandas nada nobres.

Até a Microsoft

A Microsoft não ficou de fora, ela criou o ASP.NET Session State que tinha como persistência possível também o no SQL Server.

Você pode ver a documentação aqui.

Esse mecanismo serviu de argumento para muitos projetos construírem suas tabelinhas de [Cache, Fila Etc etc].

Em toda empresa, em todo projeto, em todo lugar

Essas soluções não eram exclusividade da Petrobras, eram demandas naturais de muitas aplicações, presente em quase todas as empresas que desenvolviam software naquela época. Isso porque estamos falando de assuntos básicos.

Embora sempre convergíssemos para um SGDB, cada empresa, ou até cada projeto fazia do seu jeito.

Um mesmo profissional que trocasse de empresa, sofria com uma grande curva de aprendizado, e a cada nova empresa/projeto, boas eram as chances de encontrar algo completamente diferente para resolver o mesmo problema.

Quem conta um conto aumenta um ponto.

Ditado popular

Um ponto que merce a atenção é que além dos criadores, os usuários diretos desses componentes eram desenvolvedores.

O pedreiro se passando por engenheiro.

Não era incomum, um desenvolvedor usuário de um determinado componente na empresa anterior. Se colocar à disposição para recriar a solução em uma nova empresa, assim que contratado.

Fazendo parecer com que ele tivesse o conhecimento para isso.

Muitas vezes se portando como se tivesse feito parte da concepção do projeto, na empresa anterior.

No meu mundo isso é motivo de demissão!

Esse fenômeno de adicionar complexidade por conta de algo que viu em algum lugar, e simplesmente querer fazer sua versão daquilo, não é uma dinâmica recente.

O agravante é que por não ter feito parte do time que criou a solução original na empresa anterior, esse desenvolvedor possuía apenas conhecimento superficial do que ressaltava aos olhos.

Com a perspectiva de um usuário, de um consumidor do serviço, com reclamações, talvez, mas sem entender rumo do projeto pelo lado de dentro. Sem entender os requisitos funcionais e não funcionais em sua plenitude.

Presenciei esse fenômeno algumas vezes, em algumas empresas.

Aliás, presenciei também um amigo meu, por telefone, em uma entrevista por telefone, usando algo que eu havia concebido do zero, como argumento de contratação, como se ele tivesse feito.
Isso é história para outro papo.

Sempre sob pressão de um grande problema, sob o questionamento a respeito do fundamento de uma decisão, o falso-idealizador era desmascarado. Quando não, ele não estava mais na empresa.

A real é que na busca de projeção e relevância, resolvendo um problema entre sistemas, se obtém como produto: status e capital político.

Acredito que uma boa forma de começar uma carreira meteórica em uma nova empresa é adquirindo status e capital político, certo??!!

Mas qual é o problema?

Uma vez que toda empresa possuía uma solução própria para problemas comuns. O resultado óbvio desse cenário é o desperdício.

Recursos demais empenhados em infraestrutura em praticamente todas as empresas que desenvolviam software.

Com soluções muito diferentes, pouco ou até nenhum conhecimento era reaproveitado, aumentando a curva de aprendizado em todo lugar.

Sem tempo para produzir soluções profissionais para os problemas em questão, soluções mal feitas, e mal projetadas, dominavam o mercado.

Me recordo de uma empresa famosa daqui do Rio de Janeiro, que tinha seu ORM próprio baseado em XML. Era famosa pelos problemas de N+1.

O que víamos eram verdadeiras rodas quadradas, mais quadradas ainda quando superficialmente copiadas.

A falta de dedicação exclusiva a esses projetos, obrigando a embutir a criação desses componentes nas tarefas de projetos de negócio era comum.

Falhas de segurança, encontrávamos aos montes.

No final das contas nós jogamos uma fortuna pelo ralo, produzindo projetos porcos, vergonhosos, nada profissionais: meros paliativos.

Era o que dava para fazer com as migalhas de tempo que nos sobrava.

O ponto é que muito pouco em infraestrutura era resolvido de forma séria e profissional.

Qual foi a resposta do mercado para isso?

Infelizmente eu também fui acometido por essa ideia de que as coisas estavam ficando complicadas demais.

Entretanto, a meu favor, eu não passei muito tempo pensando assim.

A resposta do mercado foi profissionalizar todos esses componentes de uso comum.

Por alguns anos me dediquei a restruturação de projetos. Projetos fracassados ou em vias de fracassar, que precisavam de algum tipo de retorno muito diferente do que era possível realizar com as variáveis que tinham. Time, infra, budget etc.

Ao mesmo tempo, em que eu buscava esses projetos, os smartphones ganhavam mercado e mudavam as forma e o como aplicações e API’s eram consumidas.

Aplicações com milhões de usuários e milhares de acessos simultâneos se popularizavam além das redes sociais.

Com a experiência que adquiri desenvolvendo e reestruturando projetos .NET, não era difícil entender que meus truques, minha técnica, conseguiam produzir saltos muito expressivos. Porém, limitado a poucos milhares de usuários e acessos simultâneos.

Eu já tinha meu passo-a-passo para otimizar código e arquitetura para sair de 100 para 500 usuários. Com ajuda de algumas ferramentas, alguns milhares de usuários. Mas nada perto do que uma aplicação de fato projetada para milhões.

Estava claro que eu precisava entender como essa galera que produz aplicações com centenas, milhões de usuários, como essa galera consegue lidar com esse workload.

Definitivamente eu não conseguia chegar lá com o que eu conhecia.

Toda essa complexidade de ferramental nascia exatamente para dar suporte a essas aplicações. A esse volume de tráfego de atividades. Que não vinha apenas com uma demanda grande em volume, mas também em uptime.

Ali saquei que além das ferramentas, eram necessárias técnicas.

Conhecendo as técnicas foi possível identificar algumas que daria para aplicar em absolutamente qualquer tamanho de projeto.

E esse novo ecossistema, esse novo universo, do que se trata?

O que vemos hoje é uma resposta direta ao que fazíamos no passado.

Agora ao invés de tentarmos reinventar rodas, produzindo rodas quadradas, simplesmente adicionamos uma tecnologia ou ferramenta ao stack.

O ponto negativo é o natural aumento da complexidade, no entanto, agora conseguimos reaproveitar o que aprendemos. Quando aprendemos sobre Keycloak, Kong, Docker, Kubernetes, aprendemos algo que é idêntico em todos os lugares.

Nós amadurecemos e aprendemos que não podemos criar soluçãozinha, gambiarrazinha por aí.

Agora para cada problema, buscamos uma solução especialista.

E quando podemos e somos especialistas em algo, produzimos essas soluções especialistas em cada uma das áreas. Nós produzimos projetos que se tornarão open source no futuro. Se quiser, claro!

Por isso

• a tabelinha que servia de de fila dá lugar ao RabbitMQ
• os logs armazenados em tabelas de eventos dão lugar ao Kafka e RabbitMQ
• a tabelinha de usuário, senha e role dá lugar ao Identity Server e Keycloak
• A tabelinha de cache dá lugar ao Redis

e por aí vai.

Entendemos que desperdiçamos mais energia e tempo produzindo projetos de infraestrutura, produzindo projetos ruins, minimalistas ao nível de ser porco.

Embora soluções Open Source de mercado tragam complexidade, elas estão se tornando universais. Basta olhar para as vagas. Há certa uniformidade nos requisitos.

Na era CLOUD NATIVE, privilegiamos a adoção de ferramentas especialistas em detrimento da pseudogenialidade de criar tabelinhas aqui ou acolá para resolver porcamente problemas sérios que mereciam atenção e dedicação.

Nesse ponto a arquitetura de solução toca na arquitetura de software que toca no desenvolvimento, forçando-nos a entender esse universo para podermos fazer parte dele, seja propondo, ou simplesmente consumindo esses recursos.