No último sábado terminamos (eu e meu grupo) o MBA da FIAP de Arquitetura de Software como campeões do desafio principal. Preciso confessar que estávamos completamente céticos em relação a qualquer prêmio por dois motivos. O primeiro é que não entregamos o que foi pedido e o segundo é que a nossa proposição de arquitetura era o mais simples possível. Mas vou descrever essa jornada.

O Desafio

Na verdade era um Chalenge, mas como eu me recuso a usar termos estrangeiros se temos bons termos em pt-BR, mas vou chamar de desafio mesmo! 😀

Um banco que existe antes das FinTechs, mas que cresceu na era das FinTechs, apresentou uma proposta de melhoria da sua gestão de infraestrutura: “queremos AIOps”. A proposta parecia genérica, e realmente era. Tudo que eles pediam era uma apresentação da arquitetura proposta com um demonstração. Eles focaram que era algo HandsOn! Queriam ver funcionando no dia da entrega. Não havia nada mais especificado.

Durante as mentorias, conseguimos levantar alguns pontos da infraestrutura do banco. Eles usavam um provedor de Cloud que já tinham escolhidos como principal fornecedor. E usavam duas ferramentas, uma para APM e outra para monitoramento de rede. Não conhecíamos e nunca tínhamos usado nenhuma dessas ferramentas, para ser sincero, durante minha carreira eu tive pouco contato com software em produção, então monitoramento é uma fraqueza. Só usei o NewRelic e fiz alguns deploys usando a plataforma ELK. Mas isso não me dá a visão de uma infraestrutura completa para um banco.

Decisões iniciais e Definições

Na conversa com o grupo chegamos a primeira conclusão: o desafio é vago. Se entregarmos algo HandsOn, é bem provável que cubra todos os requisitos e podemos até ganhar, mas ao encarar o primeiro trade-off, pode ser completamente descartado. Então fizemos a primeira pergunta: como entregar algo que com certeza não vai ser jogado fora? Era hora de pesquisar.

A primeira definição que encontramos foi do Gartner, na verdade foi a única que fomos atrás. Não fomos atrás de outras definição por um motivo bem simples: fugir do papo de vendedor. Normalmente quem escreve sobre um assunto é quem vende um produto relacionado, e muitos desses “white-papers” estão na verdade não apaixonados pelo problema, mas vendendo uma solução.

AIOps combines big data and machine learning to automate IT operations processes, including event correlation, anomaly detection and causality determination.

Segundo o Gartner, AIOps envolve eventos. AIOps começa quando eventos podem ser colocados dentro um algoritmos de Machine Learning. Nesse ponto informamos claramente para a equipe do banco: pode tirar o cavalinho da chuva que não vai ser fácil. Pois é, ao invés de vendermos nossa solução, falamos a verdade. Para criar um solução robusta de AIOps era preciso catalogar dados, criar eventos e treinar uma rede neural.

“Conhece-te a ti mesmo”

O segundo passo foi criar um meio de auto avaliação. Não faz sentido apresentarmos uma solução para uma empresa e ela mesmo não conseguir avaliar se a solução permitia AIOps ou não. Logo procuramos se existe algum modelo de maturidade para AIOps.

Se você nunca parou para olhar o que é um modelo de maturidade, recomendo fortemente que procure algum. Você pode encontrar facilmente para Metodologias Ágil e DevOps. Na maioria dos casos começar a fazer algo não significa apenas usar ferramentas, mas entender o problema e saber como a ferramenta pode de ajudar a implementar uma politica.

Ao procurar um bom modelo de maturidade tivemos o mesmo problema com a definição: papo de vendedor. Normalmente quem produz um modelo de maturidade quer validar a própria ferramenta e não avaliar a adequação do problema com a solução. O problema é que a solução proposta vai sempre levar ao nível mais alto, pois todas as deficiências da solução serão propositadamente omitidas. Então passamos a segunda, terceira, quarta, etc… página do google para encontrar um modelo que fosse realmente abrangente.

Assim pudemos propor o seguinte modelo:

• Nível 0 - Caos
  • Sem dados
  • Sem análises
  • Sem automação
• Nível 1 - Coleta
  • Serviços com suporte a coleta de informações de operação
• Nível 2 - Consolidação
  • Dados da operação centralizados
  • Identificação manual de erros
  • Construção manual de dashboards
• Nível 3 - Contextualização
  • Extração de informações dos dados
  • Identificação automática de erros
  • Estatísticas não supervisionadas
  • Automação bi-direcional (ITSM)
• Nível 4 - Conselho
  • Recomendação de fontes de dados
  • Recomendações de análises e correlações
  • Automação de múltiplos passos
• Nível 5 - Autômato
  • Otimização proativa
  • Tuning de performance
  • Solução automática de problemas
  • Automação Closed-Loop

É muito importante que o modelo de maturidade seja devidamente apresentado a empresa, porque muitos entendem que podem chegar ao nível máximo apenas usando algumas ferramentas. ISSO É UM MITO! Todo maturidade chega através de muito esforço e mudanças graduais. É bem provável que a maioria das empresas esteja no nível 0, mas se simplesmente falarmos que elas vivem o Caos já perdemos o cliente. Porque na verdade nenhuma empresa séria vive o Caos, eles podem até estar nessa fase, mas já criaram uma série de processos para garantir que o caos seja controlado. O que acontece é que a empresa caminha para o lado no modelo de maturidade, ao invés de andar para o nível 1, ela vai criar processos que engessem o caos tornando ele extremamente burocrático.

Quer um exemplo dessa burocracia? Uns 5 anos atrás eu vi uma palestra de um IT Leader (termo genérico, não!?) contando como foi a migração de todos os serviços da empresa para nuvem. A apresentação de cerca de 50 minutos não contou com nenhuma definição, padrão estabelecido ou mesmo conceito. Não falaram de Cloud Native, Microservices, etc… Como a empresa fez? Replicou tudo na nuvem e foi verificando se o serviço replicado na nuvem era igual ao executado on-premise. Ora, qual foi o custo disso?!!? Depois eles migraram pra nuvem e mantiveram o on-premise ainda em atividade para garantir um fallback. Eu não quero saber quantas noites esses infelizes perderam por não estudar o conceito de Cloud Native que já tem uns 10 anos, ou por não ter estabelecido um padrão para toda a aplicação.

Com o modelo de maturidade acima, a empresa poderia criar um planejamento para andar entre as fases.

Escolhas de ferramentas

O próximo passo era escolher ferramentas que pudessem possibilitar a implantação de cada nível do AIOps. Para isso fizemos um grande levantamento. Quem pode ajudar em cada linha do nosso modelo de maturidade? Fizemos a lista de todos os nomes e começamos a jogar em um diagrama. Mas para fazer uma integração não é só criar uma seta num diagrama ArchiMate, é muito fácil criar diagramas mas é bastante complexo colocar eles em funcionamento.

Logo começamos uma busca intensiva por toda a documentação de todas as ferramentas com a seguinte pergunta: como eu integro a ferramenta A na ferramenta B? Com essa análise simples, já pudemos dividir as ferramentas em conjuntos de possíveis soluções. Mas já no começo sabíamos de algumas limitações, pois o banco já usava duas ferramentas e escolhido o provedor Cloud. Assim todas as soluções deveriam incluir essas duas ferramentas e esse provedor cloud.

A decisão difícil

Entre as várias opções arquiteturais, tínhamos algumas plataformas Open Source e várias empresas oferecendo serviços.

Escolher uma solução open source seria minha escolha de coração, mas isso requer bastante trabalho para implantar. Muitas vezes acreditamos que é fácil montar uma equipe com bons desenvolvedores que entendem de plataformas open source e são hábeis em pesquisar soluções na internet. Mas na verdade o mercado é bem diferente da nossa bolha. A grande maioria dos desenvolvedores não tem essa habilidade, não conseguem entender os protocolos e muitos não entendem nada em inglês. Logo a solução precisava ser provida por uma empresa que daria um bom suporte.

E sobre ter várias empresas, isso é realmente bom… MAS… O que observamos no passo anterior foi que as próprias empresas que proveem serviços de observabilidade estão se fechando em silos propositadamente. A empresa sabe que se ela os produtos A e B, se ela prover integração do produto A com o B da concorrência, ela vai perder mercador. Logo as empresas que tem produtos lideres de mercado estão removendo possibilidades de integração. Nós verificamos isso fazendo uma correlação de datas de lançamento de produtos, posts de blogs e documentação. Quando a empresa lança um produto, ela retira a possibilidade de integração da documentação e os posts de blogs anteriores a data de lançamento do produto vão possuir links inválidos. O que isso significa?

Se escolhêssemos as melhores ferramentas para cada passo, teríamos uma grande dificuldade de evoluir pois cada integração seria custosa. Então era mais fácil aceitar o Vendor Lock-In para podermos propor uma arquitetura fácil e rápida de se implantar. Depois de implantada a empresa poderia avaliar uma troca de serviço. Assim decidimos que todas os serviços deveriam ser do próprio provedor de Cloud, que nesse caso era a AWS.

Usando o mesmo provedor de serviços evitamos silos de dados. Se a ferramenta de AIOps só precisar olhar para um local é muito mais fácil de manter e evoluir a solução.

Criação de um plano

Eu sempre digo que se temos um plano, temos tudo. Ter um plano é como viajar para um lugar desconhecido com um mapa, mesmo se pegarmos o caminho errado, é possível reavaliar e propor uma nova rota. Todo plano pode ser reavaliado.

Dados os níveis de maturidade começamos a escolher ponto a ponto de como integrar. Primeiro era preciso ter dados! Por isso propusemos um escolha que todos os microsserviços deveriam expor seus dados em formato Prometheus. Não vamos usar o Prometheus, mesmo sendo uma das possibilidades, mas percebemos que todos os serviços estão abertos a se integrar com soluções open source. Todo serviço deve ser Cloud Native, seguir os 12 Fatores e usar um framework moderno. Como exemplo criei um serviço de registro de pagamento bem simples usando Quarkus.io, PostgreSQL com JPA Panache, Jakarta Bean Validation, MicroProfile Metrics, MicroProfile Health e OpenAPI. Usando o esqueleto de microsserviço já atingimos o nível 1, habilitando a coleta de informações.

O próximo passo é consolidar todos esses dados em um só local. É muito importante que seja um só local, pois isso facilitará a implementação. Para isso escolhemos o AWS CloudWatch, porque ele é o serviço que faz isso nativamente para Amazon. Se precisamos coletar dados de servidores on-premise, podemos usar o AWS CloudWatch Agente para coletar todos os dados e salvar no mesmo “lake”.

Lembra que a empresa já possuía alguns serviços de monitoramento? Esses serviços não poderiam ser facilmente integrados, não há suporte. Por isso propusemos exportar os dados em formato Prometheus, que podem ser coletado pelo AWS CloudWatch Agente e, além disso, criar eventos e alarmes que podem ser enviados via API para o AWS CloudWatch. Esses serviços podem ser usados, mas a integração não vai ser nativa.

Usando apenas o AWS CloudWatch já é possível criar um dashboard com as informações principais do ecossistema. É possível também identificar erros e criar eventos e alertas baseado em padrões de logs, correlação de eventos, etc… A escolha do AWS CloudWatch por se só já leva ao nível 2, mas será preciso uma fase de criação de dashboards, eventos e alertas para chegar a plenitude do nível 2 e depois chegar ao nível 3, contextualizando dados e logs.

Um ponto interessante que eu não tinha nem ideia, é que o sistema bancário é super regulamentado. Agradeça a essa regulamentação por não termos tido crise nos anos 2008/09. Essa regulamentação vem lá dos anos 90, quando vários bancos quebraram por pura picaretagem dos seus diretores. Quem tem mais de 35 vai se lembrar de vários homens branco classe AAA+++++ sendo presos, mansões sendo leiloadas, etc… Bom, dessa regulamentação vem um rígido processo de ITSM, isso significa que nenhuma operação na produção deve ser feita sem um rastreamento. Por isso precisamos escolher uma ferramenta de ITSM externa a AWS, mas que pode ser integrada vai API usando Lambda. Com alertas e funções lambdas é possível automatizar várias operações tanto na nuvem quanto em on premise.

Para finalizar, propomos o uso do AWS DevOps Guru, um produto da própria AWS que promete magicamente habilitar o AIOps. Mas fomos bem cético nesse uso. Ao propor já avisamos que nenhuma solução de Machine Learning vem de graça, tem que ter uma base tageada e treinamento de modelos. Não fizemos nenhuma PoC usando o DevOps Guru, apenas propomos e ainda dissemos para só habilitar quando todo o dever de casa estiver feito.

Essa solução é propositadamente simples.

Outras soluções

Não tínhamos nenhuma esperança de ganhar e quando começaram as apresentações percebemos claramente que não iriamos ganhar. Todas as soluções eram extremamente complexas, usavam ao menos 10 produtos diferentes. Teve um grupo que chegou a propor uma integração plugando um Apache Kafka no AWS CloudWatch, nessa hora eu peguei minha garrafa de água pra ver se alguém tinha colocado drogas ou se o grupo realmente não tinha parado para avaliar o nível de dificuldade da solução proposta.

Muitos quando era questionados das escolhas gaguejavam ou dava desculpas esfarrapadas. Nossa solução não era a cereja do bolo, no documento que entregamos ela ocupava poucos parágrafos (algo como uns dois a mais que a sessão anterior) com alguns links de documentação. O ponto principal era o modelo de maturidade.

Outras aplicações reais

Você pode achar que isso só funciona para infraestrutura de aplicações, mas é bem provável que seu acesso ao mundo será controlado por uma solução AIOps. As especificações 5G já preveem algo chamado como SDMN (Software-defined mobile networking) onde a estrutura da rede é definida por software. Isso possibilita que seja também alterada por software, assim há alguns casos de AIOps já estudados, que nesse caso se chama Closed Loop. Para maiores informações leia AI-driven Closed-loop Automation in 5G and beyond Mobile Networks ou Towards Closed Loop 5G Service Assurance Architecture for Network Slices as a Service.

Mas vou descrever como isso pode acontecer no futuro. Imagina que alguma empresa lance um jogo que sobrecarrega toda a rede de telefonia. É preciso de muito tráfego pra isso, mas vamos supor que esse jogo seja mesmo um grande desperdício. Se a rede não se reorganizar, a latência e velocidade de todos os usuário da rede será afetada. Usando Closed Loop, a própria rede pode perceber que apenas um serviço está causando um impacto enorme (normalmente 20% dos usuários usam 80% da rede), então a rede é dividida (network slicing) e esses usuários são direcionados para uma rede exclusiva. Deste modo, se o uso está abusivo, apenas eles vão sentir o impacto, evitando que outros usuários sejam impactados. Isso é muito importante em 5G pois nessa rede não estarão somente usuários, mas equipamentos importantes de fábricas, hospitais e locomoção.

Conclusão

Complexidade e papo de vendedor vende. Mas verdade e simplicidade convencem muito melhor. Muitos arquitetos gostam de complexidade porque eles acreditam que ela vai dar elegância a solução. Mas o conceito de elegância vem da simplicidade, fazer o básico bem feito.

Ao propor uma arquitetura leia toda a documentação, evite passar vergonha de propor a solução errada. Pode ser que quando você for apresentar ninguém realmente saiba do que você está falando, mas pode ser que exista um especialista no assunto. Existe até um conto centenário chamado O homem que sabia javanês que mostra como uma pessoa pode parecer inteligente apenas sendo cara de pau. Não seja essa pessoa, isso é leviano e injusto. Creio que nós só ganhamos esse prêmio porque ao vender as dificuldades de implementação e fazer uma pesquisa séria no tema implodimos todas as soluções impossíveis e colocamos uma bomba relógio na complexidade desnecessária.