No post passado eu citei alguns elementos que precisam ser levados em conta, e não detalhei muita coisa. Só narrei causa e efeito. Hoje eu vou listar o material que já produzi que tem alguma ligação com o tema. Direta ou indiretamente, são elementos que vão ajudar a esclarecer como essa jornada, e mostrar como tudo começou para mim. Eu me proponho a elucidar alguns pontos que vão ajudar a esclarecer e te ajudar a construir soluções melhores.

No post Isso não é microsserviço! eu uso uma palestra do Martin Fowler que detalha como microsserviços são. A intenção desse post é mostrar que seus serviços não possuem mais ou menos essas características, você não está no caminho certo. Você não tem microsserviços. Se esse for o caso, o mínimo a ser feito é parar de dizer que são microsserviços. Depois alinhe a direção e execute as ações necessárias para seus serviços sejam microsserviços. E nesses aspectos estamos falando de implantação, automação, estruturação, escopo, forma de exposição. Além de outros aspectos estruturais que são muitos tópicos legais também.

Em Sobre Formula 1 e Microsserviços eu tento usar uma analogia para mostrar como no automobilismo tecnologias de ponta chegam ao uso cotidiano, e como microsserviços chegam para nós. Boa parte do mercado de quer se espelhar em NETFLIX e Amazon, mas quase a maioria ignora o fato de que esses grandes players não são grandes pelas tecnologias que usam. Eles usam essas tecnologias exatamente por serem grandes. Esses grandes players tem muito dinheiro e investem muito para conseguir fazer o que fazem. Uptime de 99.9% é algo insano (em complexidade e custo). Mas isso não é um problema, é uma característica. Só não pode ser negligenciada.

Já no post Consciência Crítica vs Comportamento de Manada eu me ancorei na nova página sobre Microservices do site do Martin Fowler para desconstruir algumas falácias como: “Monolitos nunca mais”, “Microsserviços servem para tudo e para todos”, “Monolitos são lixo”, “Nunca comece por um monolito”. Usando textos do próprio Fowler em que apontam, com naturalidade, a possibilidade de criação de monolitos, sem nenhum peso na consciência por isso.

Não que a intenção do post fosse fazer alguma uma apologia ao monolito, só que alguém precisava se sujar e falar deles para desconstruir essas falácias. Monolitos existem e continuarão existindo. O feio é usar um monolito para atender um E-Commerce, por exemplo! Um cenário clássico em que um monolito não atende bem. Mas pasmem, até 2010, muito e-commerce era monolítico, viu…. eu conheço um gigante que até 2014 era um monolítico modular.

A minha jornada começa muito, muito antes do hype…

Primeiro ponto, é que preciso me reapresentar. Meu primeiro trabalho em times de arquitetura se deu em 2003, anos antes, ainda no segundo grau, eu havia aprendido a programar sozinho, havia caçado alguns cursos para conseguir um diplominha daqueles de conclusão de cursinho. Algo que pudesse me ajudar na construção mínima de autoridade, algo que pudesse expressar: Ok, é jovem, mas concluiu um curso de programação.

Junto com o ingresso na faculdade em 2002, pouco tempo depois eu estava na petrobras, meu primeiro emprego. Logo (8 meses) depois, consegui chegar ao time de suporte ao desenvolvimento. Era o time da galera que falava, desenhava e definia arquitetura.

Naquela época não existia o termo arquiteto. Não era usado, não fazia sentido era esquisito chamar alguém de arquiteto. Mas eu era tipo um aprendiz ali, estava em plena migração de júnior para pleno, pois havia sido fácil entender as dinâmicas do desenvolvimento corporativo, entender as regras do jogo e jogar conforme as regras.

Como eu cheguei no time de arquitetura? Simples! Entender como as coisas funcionam sempre me motivou a sempre melhorar o que estou fazendo. Para que pudesse fazer mais com o mesmo tempo que tinha. Assim me sobrava tempo para estudar. Aliás, eu questionava perguntava demais! Eu tentava entender o ponto de vista de quem decidiu algo. Para entender os argumentos de uma decisão, a decisão em si e suas implicações.

Aquilo era como uma matrix: Causa, efeito, ação, reação… e Eurekas!

Então não me conformava em usar um include ASP (classic ASP), eu queria saber o que estava dentro dele, como e quais técnicas haviam sido usadas para sua construção. Eu buscava entender o que ele fazia e como fazia, para ver se tinha alguma sacada ao meu alcance que me ajudasse. Outro ponto importante é que essa busca nunca estava ligada a problemas, ou tentativa de copiar algo para fazer outra coisa. Era por pura curiosidade. Queria absorver todo o conhecimento possível. Para conseguir entender algumas coisas novas, eu também lia muitos manuais e guias de referência. Como os que você vê abaixo.

Era uma época que não tínhamos muitas opções. Os indexadores eram outros, a internet era outra. Mas essa pequena decisão de ter esses livretinhos ajudava demais no entendimento das coisas. Isso me ajudou na compreensão de tudo que estava ao meu redor. Essas referências, me ajudaram a entender como as coisas funcionavam, e cada vez mais eu perguntava menos e respondia mais. Nesse time de arquitetura, eu dividia a responsabilidade de gestão dos servidores de Desenvolvimento, Testes e Homologação, todos Windows Servers. Isso me ajudou a ter essa visão do todo, conectando ponto-a-ponto e me permitindo entender não somente o código, mas como isso acontecia do lado do servidor.

Meses mais tarde esse conhecimento me ajudou na forma como eu estudei .NET, mais ou menos em 2003 para 2004. Aliás em 2005 tive meu primeiro contato e fiz minha primeira recomendação oficial apontando o uso do NHibernate.

Essa forma de lidar com o aprendizado, precisando entender como as coisas funcionam, serviu para que eu tivesse uma compreensão única a respeito das tecnologias que uso. Essa é a forma como meu aprendizado performa melhor. Entendendo como os pontos se conectam, do mais básico para o mais complexo. Somente quando as coisas fazem sentido, é que me sinto a par do assunto. As ações e conseqüências precisam ser óbvias na minha cabeça, e essa obviedade só é possível entendendo os fundamentos e a base que concebe cada objeto de estudo.

Preenchendo lacunas…

Minha jornada com microsserviços se confunde com minha jornada sobre serviços. Ao percorrer esse caminho precisei estudar muito. Por exemplo, no final de 2015 eu decidi que aprenderia Docker. Como arquiteto, e como responsável técnico, entender docker foi fundamental para que pudesse entender como provisionaria serviços e recursos nos próximos anos (acredito que décadas). Mas entender Docker era, antes de mais nada, um desafio. Havia uma “singela” premissa que me distanciava muito da compreensão de Docker. O Linux!

Para entender Docker, era necessário antes, entender Linux. E assim essa jornada resultou no Docker de A a Z, que está aqui no site, e agora no Docker Definitivo, que é um produto que cuido junto com meu amigo Renato Groffe.

Em outro extremo, como parte do processo de garantir escalabilidade horizontal, RabbitMQ entra como resultado de um estudo que fiz por volta de 2014. Hoje tenho uma série aqui, com 8 posts e algumas lives dedicadas ao tema. Meu conhecimento sobre RabbitMQ somado ao conhecimento sobre mensageria em geral, somado a um podcast que escutei na última sexta-feira (20/09), me ajudaram a entender Kafka. Novamente, ação, reação, conseqüências. O que estava faltando para a compreensão de Kafka, foi sanado podcast Tudo sobre Kafka – Hipsters On The Road #14. O ciclo de descoberta, entendimento, dúvidas e agora: Eureka! Saquei, faz todo sentido. Agora os elementos de sua arquitetura estão claros. Mas pra isso, eu tinha perguntas claras e objetivas que careciam de respostas. Aliás, o podcast ajudou a preencher essa lacunas, pois eu já havia passado superficialmente por kafka algumas vezes nos últimos 2 anos.

Eu apresentei no DevHero, como eu lido com o aprendizado:

1. Entender superficialmente do que se trata
2. Voltar consistentemente para entender mais (Sem deixar ficar tempo demais distante do assunto ao ponto de esquecer algo)
3. Aprofundar
4. Questionar
5. Eureka!

Voltando no tempo, exatamente para 2011, uma thread em um grupo do Google Groups, onde e fui massacrado por falar em Schemas para JSON, me motivou a criar o grupo de arquitetura do facebook e também resultou no post Contratos são garantias – JSON Schema. Enterprise Integration sempre foi um tema divertido. A respeito desse assunto, minhas premissas sobre integração e contratos rígidos, me ajudaram a sustentar essa narrativa que hoje é usada em escala por todos os grandes players.

Voltando agora os esforços para a codificação, mais especificamente para modelagem e patterns, em especial Dependency Injection e Inversion Of Control sempre foram temas aos quais me dediquei bastante. Posts que gosto como IOC / DI – Você está fazendo isso errado! onde abordo Service Locators antipattern ou IoC e Dependency Injection – Os erros comuns emergem de experiências do dia-a-dia. Esses patterns têm muito potencial quando bem usados, esses patterns tem papel fundamental na criação de uma arquitetura de alta escalabilidade. Eles alicerçam outros padrões que ajudarão a garantir resiliência, discovery, dynamic configuration e uma infinidade de padrões. SOLID é o caminho (mas o I do SOLID não é de IoC, ok?!)

Voltando a 2007, com ajuda desses e outros patterns, desenvolvi a primeira versão do Oragon Architecture, uma arquitetura de serviços pautada na composição de padrões e regras. O projeto foi evoluindo ao mesmo passo que eu, projeto-a-projeto, restruturação-a-restruturação. Por falar nisso, já em 2014/2015 eu mostrei alguns tradoff’s de restruturação em Roadmap de Arquitetura – Um exemplo real e em Por onde andei, andei frustrado onde apresento um roadmap intenso de restruturação, ações e muito mais.

Na época desse último post eu resolvi detalhar como eu tomava decisões, daí produzi um dos posts que mais me orgulho: Como definir a Arquitetura de um Software.

E nesse roadmap, surgiu uma boa necessidade que demandou uma infraestrutura de hosting de processos descrita no post Escalando Horizontalmente com Oragon Architecture Application Server. Era naquele momento que eu havia aprendido de fato a lidar com AppDomains, algo que hoje não faz mais sentido (David Fowler informa em 2014 que não teremos AppDomain no .NET vNEXT, que mais tarde virou .NET Core). Por volta dessa época eu havia escolhido RabbitMQ como minha infraestrutura padrão de mensageria,

Eu já estava, nessa época, com Linux no radar. Satya Nadella havia assumido a Microsoft no mês anterior, ainda não fazíamos ideia do que estava por vir, mas eu já falava de Redis, MongoDB, RabbitMQ, Sentry e muito mais que o mundo Linux pode oferecer para aplicações .NET. Soluções que hoje, ao falarmos de escalabilidade e monitoramento, continuam muito presentes. A única exceção é o Sentry, que deu lugar para o ElasticSearch, no meu cinto de utilidades, empenhado na centralização e consolidação de logs.

Por falar nisso, log e monitoramento é um tema que cuido com carinho. Logs Estruturados foi um post a respeito do assunto onde mostro falo sobre questões envolvendo logs, e principalmente como usar técnicas de estruturação de dados complexos em logs, de forma a estabelecer um rastro para facilitar o troubleshooting. Coisas que facilmente vemos hoje no Firebase ou Crashlytics da Google, mas naquela época, eles só existiam há 3 anos. Mas também apresentei RabbitMQ e ELK Stack em Docker – de A a Z – 15 – RabbitMQ, ElasticSearch , LogStash e Kibana, que acabou virando projeto que mantenho até hoje e ganhou uma página em EnterpriseApplicationLog @ Docker Gallery.

Com exceção do Oragon (que hoje defino com conjunto de premissas/regras para a construção de serviços), todos os temas são pertinentes a todo desenvolvedor que está nessa jornada. E mais, todos esses assuntos dizem respeito ao desenvolvimento de soluções que escalam, independente de serem monolitos ou microsserviços.

Antes do tema microsserviço, Cloud Native foi um tema que me chamou a atenção, então daí surgiram posts sobre a CNCF, com uma enorme área de cobertura em serviços para cloud native apps, assim como Consul – DNS – Visão Geral, Envoy ganha novo amigo: Consul, onde falo de service discovery e mais tarde falo sobre serviços agnósticos já falando sobre modelagem de serviços e em O fim do IIS quando falo de hospedagem de API’s. Mas outro ponto, outra característica que são pertinentes a 2019: Utilização de protocolos binários, como apresentado quando falo gRPC no ASP.NET Core – Guia Introdutório e novamente reforça o conceito por trás de posts como Contratos são garantias – JSON Schema.

As demandas de Cloud Native, Serviços, Containers e Microsserviços pela perspectiva de hosting e deployment são muito parecidas. Claro, serviços disponíveis como PaaS no Azure eliminam diversas das preocupações. Mas eu sempre defini algumas premissas e limites para meus objetivos: Tudo que eu queira definir como arquitetura, eu devo, necessariamente saber fazer on-premise. E note, saber fazer é muito diferente de recomendar. Eu só não quero passar vergonha e dizer que só sei fazer com Azure. Azure é uma mão na roda, mas é o tipo de serviço que mima o desenvolvedor. Dá muito poder para quem não faz ideia do que está fazendo. Mas sua missão é essa: Empower Developers! Eu só resolvi jogar outro jogo.

Sobre a perspectiva de automação, apresentei jenkins algumas vezes, entrego projetos inteiros no github, como feito em Underwater – Construindo Libraries .NET Standard Profissionais ou em lives e vídeos onde apresento Jenkins para CI & CD, como no vídeo Docker – de A a Z – 14 – ASP.NET Core from Scratch to Production with docker & jenkins. Também tentei trazer o assunto Blue/Green e Canary com o post Booking.com – Shipper – BlueGreen e Canary Deployents no Kubernetes.

Conclusão

O caminho é longo, há muita coisa a ser detalhadas, mas eu tenho feito o que posso para elucidar esses pontos.

Esse foi um apanhado do que venho produzindo de conteúdo. Mas há muita coisa legal a falar.

Temas que eu ainda não abordei:

• Roadmap e mindset sobre grandes projetos de refactoring
• Aspect Oriented Architecture em profundidade
• Serviços Agnósticos – exemplo e prática
• Clean Code e Clean Architecture
• Enterprise Application Log 2 (com Graphite e Grafana)
• Envoy e Open Tracing
• APM com Elastic APM
• Ebix WBOT – O middleware de Chatbots que construí para a Ebix
• Nosso moderador do telegram, feito com NodeRED

Fora as experiências com angular, Ionic, Computer Vision, OpenALPR e muitos outros, que venho acumulando nos últimos anos, mas que não faz sentido abordar no site.