Este é um artigo traduzido originalmente publicado dia 05/01/2023 no blog do Britton LaRoche: "Effective Digital Transformation with the New "Kafcongo" Tech Stack: Kafka, Confluent & MongoDB".
O que está por trás da empolgação crescente com essa nova stack de tecnologia que conquistou a indústria? A resposta são resultados do mundo real, porque oferece transformação digital e modernização do legado em tempo recorde. A nova stack de tecnologia é baseada em tecnologia de código aberto de ponta, amplamente adotada e testada em batalha, que levou duas novas empresas a lançar seus IPOs públicos nos últimos 5 anos. Estou falando das enormes sinergias entre MongoDB ( MDB ) e Confluent ( CFLT ).
Especificamente, estou falando sobre o Apache Kafka em execução no Confluent Cloud e no MongoDB Atlas. O Confluent Cloud é um serviço totalmente gerenciado para Apache Kafka e executado em AWS, GCP e Azure. O MongoDB Atlas é o serviço totalmente gerenciado nativo da nuvem para o MongoDB, também em execução no AWS, GCP e Azure. Essas duas tecnologias trabalhando juntas transformaram inúmeras empresas em muitos setores. Neste artigo, vou me aprofundar em alguns casos de uso anunciados publicamente com os quais trabalhei pessoalmente. Vou levá-lo através do que aprendi pessoalmente e vi em primeira mão desde 2017, também apoiado por fatos de outros artigos.
Vamos falar sobre transformação digital. A transformação digital é a integração da tecnologia digital em todas as áreas de um negócio, mudando fundamentalmente a forma como você opera e entrega valor aos clientes. É também uma mudança cultural que exige que as organizações desafiem continuamente o status quo, experimentem, sintam-se à vontade para cometer erros a fim de aprender e adotar novas formas de fazer negócios. Isso leva naturalmente a uma discussão sobre a quebra de aplicativos monolíticos e silos de dados. Também leva a discussões sobre modernização do legado e, em alguns casos, migração para a nuvem.
O direcionador de valor por trás de todas as discussões são os dados. O que impulsiona o desenvolvimento de aplicativos modernos são os dados. Dados que descrevem quem comprou o quê, quando e onde compraram ou o que estão procurando literalmente impulsionam a nova economia moderna. Não se pode falar sobre a importância dos dados sem considerar como acessá-los na empresa, como movê-los e onde armazená-los. Armazenar dados para análise naturalmente leva a uma discussão sobre tecnologia de banco de dados.
Por que precisamos de um novo Tech Stack para a Transformação Digital?
Que tal algo tradicional como o Oracle Relational Database Management System (RDBMS) e sua ferramenta de integração de dados GoldenGate? O banco de dados relacional Oracle foi e ainda é o rei de um vasto império de sistemas de banco de dados relacionais locais que alimentam muitos aplicativos legados. Hoje ela ainda detém 30% da participação no mercado de todos os aplicativos de banco de dados locais.
Os tempos mudaram e a tecnologia evoluiu desde que o primeiro banco de dados relacional, Oracle, foi lançado em 1979. Um número cada vez maior de pessoas em tecnologia acredita que o tempo para desenvolver novos aplicativos em bancos de dados relacionais e especificamente Oracle RDBMS chegou ao fim. Em grande parte, isso é verdade, pois a velocidade e o volume impressionantes de dados necessários para operar nas demandas de tecnologia de “gratificação instantânea” em tempo real de hoje estão muito além da capacidade dos bancos de dados relacionais.
O Oracle, assim como o Mainframe, não morrerá. É tão difundido que estará por aí de uma forma ou de outra nas próximas décadas. Ele irá desaparecer lentamente em segundo plano e perderá a relevância quando os desenvolvedores selecionarem qual banco de dados usar em novos projetos de missão crítica em que a nuvem ou a escala massiva é importante. Os bancos de dados relacionais serão relegados para onde pertencem, em antigos aplicativos legados locais.
Para obter mais detalhes sobre por que o relacional não funciona em escala agora ou no futuro, confira meu artigo sobre por que mudei do Oracle para o MongoDB . É uma boa leitura, mas não quero sobrecarregar este artigo discutindo a velha stack de tecnologia.
É importante ver o quadro geral. Vou citar um artigo do blog do Gartner que mostra que a Oracle perdeu a nuvem e que reduziu sua participação total no mercado de banco de dados de 36% em 2017 para 20% em 2021. Novamente, esse é o mercado total de banco de dados (NoSQL, Columnar, loja Key Value etc. bem como RDBMS). A Oracle perdeu 16 pontos percentuais de participação total no mercado de banco de dados durante esse período de 5 anos. Presumo que a tendência constante continuará e, no final de 2022, eles cairão em torno de outros 4% para uma perda de 20% da participação de mercado total em 6 anos.
Por que a Oracle perdeu tanto mercado? Isso ocorre em parte porque os bancos de dados relacionais não são capazes de escalar de acordo com as demandas da nuvem. Para citar um meme de 2010, os sistemas relacionais não são "escala da web". Para piorar a situação, a Oracle perdeu a oportunidade de adotar adequadamente o licenciamento de software de banco de dados Oracle em todos os principais provedores de nuvem. Em vez disso, eles se concentraram em mover os clientes para seu próprio "Oracle Cloud". Durante o mesmo período desde o ano de $ 38,6 bilhões de 2017, o mercado de DBMS adicionou $ 40 bilhões - em 2021, dobrando em 5 anos.
A maior história do mercado de banco de dados continua sendo o enorme impacto da mudança de receita para a nuvem. Em 2021, a receita para serviços de nuvem gerenciada (dbPaaS) aumentou para US$ 39,2 bilhões - no final de 2021, representou mais de 49% de toda a receita de DBMS. O crescimento foi impressionante:
Podemos ver que quase metade dos bancos de dados estão na nuvem em 2021 e sabemos que a nuvem dobrou o tamanho do mercado geral de bancos de dados. Em breve saberemos a tendência para o final de 2022. Mas as estimativas da atual taxa de crescimento do banco de dados em nuvem aumentam de 39 bilhões para cerca de 49 bilhões, com outro crescimento de 25%. Acho que veremos que os bancos de dados em nuvem no final de 2022 representam cerca de 62% do mercado total de bancos de dados.
A Oracle manteve a maior parte de sua participação no mercado local, mas perdeu o crescimento fenomenal do banco de dados oferecido pelos três principais provedores de nuvem (AWS, Azure, GCP). Talvez a pesquisa mostre em breve que sua participação total no mercado de banco de dados caiu mais 4 pontos para cerca de 16% no final de 2022. Essa é uma perda impressionante de mais de 50% da participação total no mercado de banco de dados da Oracle desde 2017. Este é o lento desbotamento no obscuro em premissa apenas, como zumbi, esquecimento morto-vivo de que estou falando. Não é que a Oracle tenha perdido clientes existentes, eles perderam a maior parte do novo mercado de nuvem.
Fim de vida alcançado para bancos de dados relacionais
O relacionamento nesse novo mundo digital está... bem, praticamente morto. Se você tiver alguma dúvida sobre o fim da vida útil do gerenciamento de banco de dados relacional (Oracle, MySQL, SQL Server, Postgres etc...), então você deve realmente ouvir a apresentação NoSQL de Rick Houlihan no AWS re: invent 2022. Ele foi o líder mundial de bancos de dados NoSQL na AWS e agora é o diretor de relações com desenvolvedores em contas estratégicas do MongoDB. Ele sabe do que está falando e explica de onde veio o crescimento da AWS que vemos nos gráficos acima. A escolha do NoSQL em vez do relacional na AWS foi em grande parte uma decisão dele. Em suma, ele afirma que os bancos de dados relacionais atingiram a capacidade da lei de Moore em chipsets de silício modernos e não podem mais ser computacionalmente eficazes. O tamanho dos conjuntos de dados modernos combinado com o número de junções computacionalmente caras necessárias para recuperar os dados torna os bancos de dados relacionais tão lentos que agora estão enfrentando a verdadeira obsolescência.
Rick apóia cada afirmação com evidências convincentes em sua apresentação. Ele fez parte do grupo responsável pelo projeto "Rolling Stone" que migrou os principais serviços da AWS de todos os bancos de dados Oracle. Outras empresas estão fazendo a mesma coisa hoje com o Confluent Cloud e o MongoDB Atlas.
A palestra abaixo vale a pena (se você tiver cerca de uma hora), depois de assistir, você terá uma compreensão abrangente de por que os bancos de dados relacionais estão no fim de sua vida útil de uma perspectiva técnica e por que o banco de dados relacional Oracle está perdendo rapidamente a participação total no mercado de bancos de dados.
Então, qual é o grande problema do NoSQL? Por que tanto crescimento na nuvem? A resposta é tempo para avaliar. Os dados têm um ciclo de vida de valor. O que está acontecendo agora é tremendamente valioso, o que aconteceu no passado distante, nem tanto. O tempo de lançamento no mercado com novos aplicativos também é um fator importante. Há uma espécie de “corrida do ouro” para migrar para a nuvem, especialmente quando se trata de dados valiosos. Isso aumentou a necessidade de um banco de dados em nuvem escalável como nunca antes. Além disso, aumentou a necessidade de um tecido conjuntivo em tempo real, um “sistema nervoso central” inteligente de comunicação entre sistemas como nunca antes.
A complexidade envolvida para configurar um grande banco de dados em escala e um cluster Kafka para comunicação em tempo real geralmente leva meses no local. Mas na nuvem, mesmo com a dificuldade de obter os administradores certos na sala para permissões de rede, leva menos de um dia. Além disso, a nuvem oferece banco de dados como um serviço em que o failover e a correção dos backups de infraestrutura são feitos para você. O tempo rápido para obter valor, escalabilidade e alta disponibilidade por normalmente menos do que você gasta agora no local é o que está por trás da imensa atração para a nuvem.
Mostrarei como a mudança de processos lentos de ETL em lote para um sistema nervoso central de comunicação com dados em tempo real, juntamente com um enorme banco de dados de documentos, transformou e continua transformando as empresas de maneiras nunca antes possíveis. Bem-vindo à era da nova stack de tecnologia Kafka/MongoDB.
Eu sinto que a nova stack de tecnologia precisa de um nome cativante, mas ao mesmo tempo extravagante. Devemos chamá-lo de Kafkango? Hmm, nada mal, mas acho que tem a inflexão errada do “ongo” em mongo. Talvez Kafkongo? Adicione uma hashtag #kafkongo . A chave aqui é o fato de que Kafka tem muitas partes móveis complexas e precisamos de um serviço totalmente gerenciado como o Confluent Cloud. Deve ser Kafcongo soletrado com um "C" para Confluente, que desliza bem para o "ongo" de Mongo. O nome próprio e a hashtag são, portanto, #kafcongo.
Diga olá para a nova stack de tecnologia
A nova stack de tecnologia consiste em duas tecnologias de nuvem modernas: The Confluent Cloud e MongoDB Atlas. Nas próximas seções, apresentarei os principais conceitos de cada tecnologia e mostrarei como eles funcionam juntos. Por fim, darei exemplos do mundo real de transformação digital usando essas tecnologias.
Apache Kafka e a Confluent Cloud
A comunicação de dados entre sistemas sempre foi primordial desde o advento das redes, e ainda mais com a internet pública. Normalmente, isso é feito por meio de comunicação ponto a ponto entre sistemas para pequenas quantidades de dados leves e com processos ETL em lote para grandes e pesadas quantidades de dados. A ideia é que um sistema se comunique com outro diretamente. Isso funciona até que um sistema precise se comunicar com vários. Então você tem uma confusão de espaguete e gargalos e problemas de desempenho. Pior, há o medo de fazer uma alteração em seu modelo de dados porque você não tem ideia do impacto que uma alteração no modelo de dados em um sistema terá em outro. Por exemplo, há um exemplo do mundo real de um fabricante de automóveis que não poderia vender um carro acima de $ 100.
A comunicação ponto a ponto começa a se parecer com a bagunça desajeitada mostrada abaixo, à medida que aplicativos e bancos de dados se entrelaçam, misturados com data warehouses e aplicativos SaaS que, por sua vez, alimentam outros aplicativos.
Não seria ótimo ter uma maneira de um sistema publicar dados como uma mensagem ou um evento e ter outros sistemas assinando um tópico? As filas de mensagens foram inventadas para esse fim e funcionam relativamente bem. Mas eles têm uma desvantagem fatal, pois normalmente não persistem os dados. Se você quiser saber o número de mensagens relacionadas a "pedidos de clientes", por exemplo, você deve consultar um banco de dados para isso ... a fila de mensagens não mantém os dados ... opa, estamos de volta ao ponto para apontar o mundo da comunicação novamente.
Em 2010, desenvolvedores do LinkedIn como Jun Rao e Jay Kreps estavam tentando resolver essa confusão de dados e o problema de que as filas de mensagens daquele período não persistiam nos dados da mensagem. Eles criaram o projeto Apache Kafka de software livre para colocar dados de eventos em tópicos e manter esses eventos em logs. Como os dados foram armazenados nos logs, qualquer aplicativo que precise da contagem atual de dados de "pedidos de clientes" está disponível diretamente no log para o tópico persistido nos brokers do Apache Kafka. É um balcão único para toda a empresa.
O Apache Kafka decolou como um dos produtos de código aberto de maior sucesso até hoje. Está em uso por mais de 70% das empresas da Fortune 500 hoje. Essas empresas passaram da confusão de espaguete acima para uma bela arquitetura acima, onde o Apache Kafka opera como um sistema nervoso central em todos os aplicativos e bancos de dados que precisam de acesso em tempo real aos dados do evento. Os aplicativos publicam e assinam tópicos. Os conectores de banco de dados recebem eventos de captura de dados alterados (CDC) de um banco de dados e os colocam em um tópico. Esse tópico pode ser lido de outros aplicativos ou outro conector de banco de dados que move dados de um banco de dados para outro em tempo real. Já se foram os dias de processos lentos de ETL em lote para mover dados todas as noites de um banco de dados para outro. Hoje, com o Apache Kafka, os dados podem fluir livremente pela empresa em tempo real.
A única desvantagem é que o Apache Kafka tem muitas partes móveis complexas. Ele consiste em muitos corretores altamente disponíveis, conectores de banco de dados, um registro de esquema, talvez algumas instâncias do ksqlDB e muito mais. É preciso uma equipe altamente qualificada e bem paga para implementar e manter o Apache Kafka de código aberto. Eles são responsáveis por mantê-lo em funcionamento e adicionar nós para lidar com novos requisitos para novas cargas de trabalho em escala. É como se eles tivessem que trabalhar em um carro enquanto ele está rodando em uma pista de corrida, para manter o Apache Kafka de código aberto em produção. A faca de dois gumes de "dados em tempo real" também significa "sem tempo de inatividade". Muitos aplicativos de missão crítica são executados em dados de eventos do Apache Kafka, e uma janela de manutenção que dura algumas horas pode custar milhões em receita perdida.
Jay Kreps reconheceu isso como uma oportunidade de negócio e com outros do LinkedIn, que criaram o Apache Kafka, ele abriu uma nova empresa pública chamada Confluentque teve sua oferta pública inicial na NASDAQ em junho de 2021. A resposta para o problema de implementar e manter uma implantação Kafka de missão crítica altamente complexa é fornecida em grande parte com o "Kafka as a Service" totalmente gerenciado oferecido na nuvem Confluent . Todo o patch e monitoramento são feitos para você pelo Confluent. Além disso, o Confluent Cloud é dimensionado automaticamente para cima e para baixo para corresponder às suas cargas de trabalho, para que você pague apenas pelo que precisa. O Confluent Cloud é executado em todos os principais provedores de nuvem AWS, Azure e GCP em praticamente todas as regiões do mundo. Com o "Cluster Linking", os clusters Confluent Cloud Apache Kafka podem replicar dados de tópicos entre regiões, mesmo entre provedores de nuvem.
Entrei para o Confluent quando reconheci o fato de que todos os meus clientes corporativos tinham Apache Kafka e Confluent em sua futura arquitetura de estado. Até então, eu nunca tinha visto uma tecnologia ser adotada por todos os meus clientes em toda a minha carreira como engenheiro de pré-vendas. Estar na indústria me deu a percepção de que o Apache Kafka e a Nuvem Confluente é um daqueles que mudam o jogo uma vez em uma geração que praticamente todas as empresas precisam.
Não é apenas a eliminação de integrações ponto a ponto que levam a uma confusão de integrações que precisam ser resolvidas. Essa bagunça de espaguete foi pelo menos em tempo real. A razão pela qual essas integrações ponto a ponto surgiram foi para eliminar o lento e complexo processamento em lote Extract Load and Transform (ETL). Os processos lentos de ETL em lote são a marca registrada dos aplicativos legados. O processo ETL em lote foi desenvolvido para realizar levantamento pesado de grandes quantidades de dados que podem levar horas.
A solução para processos lentos de ETL em lote, acima de tudo, é resolvida por Kafka no Confluent Cloud . Os dados não apenas fluem em tempo real, mas também em escala, volumes extremamente grandes de dados podem fluir em tempo real a centenas de gigabytes por segundo. Mais uma vez, a nuvem confluente aumenta e diminui automaticamente para que você pague apenas pelo que precisa, quando precisa.
Além disso, o Confluent Cloud possui um registro de esquema totalmente gerenciado que pode ser usado por todos os produtores e consumidores de dados que se comunicam com o corretor Kafka. Lembre-se que o esquema do modelo de dados mudou para todos os sistemas que levaram 6 meses para vender um carro acima de $ 100.000? Imagine a rapidez com que essa mudança poderia ter sido feita se eles usassem o Schema Registry na Confluent Cloud. Eles teriam que fazer a mudança em apenas um lugar.
Reserve um momento (6 minutos) para ouvir Jay Kreps explicar o que é Confluent e por que é tão popular.
MongoDB AtlasName
O MongoDB foi desenvolvido especificamente para lidar com grandes cargas de trabalho em escala. O nome "Mongo" é a abreviação de "enorme". Os criadores do MongoDB queriam abordar todas as limitações que os bancos de dados relacionais estão sofrendo e o fizeram com relativa facilidade. Eles decidiram usar uma estrutura de documento para aninhar relacionamentos sem ter que fazer junções complexas. Eles selecionaram JavaScript Object Notation , mais comumente conhecido pelo acrônimo JSON para o modelo de documento. JSON é um formato popular de intercâmbio de dados abertos que pode ser lido por humanos e por máquina. A maioria dos desenvolvedores está familiarizada com REST e GraphQL e é bastante capaz de criar e usar documentos JSON.
Bancos de dados relacionais não lidam muito bem com JSON. Você tem algumas opções para armazenar JSON como uma string de comprimento de caractere variável ou BLOB ou dividir o objeto em tabelas. É muito trabalho para os desenvolvedores e para o banco de dados. Não escala. Não são apenas os documentos JSON que o banco de dados relacional tem problemas. Todo relacionamento nesse documento JSON deve ser modelado de forma que rapidamente se torne muito complexo. Extrair dados de um banco de dados relacional requer junções entre tabelas com base em valores-chave e é o verdadeiro desafio computacional. Um banco de dados relacional normalizado não pode lidar com 100 bilhões de linhas, por exemplo.
O MongoDB armazena o documento JSON como está depois de convertê-lo em um formato binário chamado BSON e cria índices em campos em documentos para consultas extremamente rápidas. Coloque um documento JSON no MongoDB, consulte um documento e recupere o documento. Não há sobrecarga com este método e é super rápido. Reserve um momento (5 minutos) para saber por que o MongoDB é tão diferente assistindo ao vídeo abaixo.
Isso dá ao MongoDB a capacidade de realmente superar um banco de dados relacional em grandes conjuntos de dados. Adicione a capacidade de fragmentar dados em vários servidores e o MongoDB realmente faz jus ao seu nome, "Hu mongo us".
O MongoDB armazena seus relacionamentos no documento. É a maneira natural e intuitiva que os desenvolvedores pensam. Ele aborda todas as preocupações que estão fazendo com que os bancos de dados relacionais cheguem ao fim de sua vida útil quando se deparam com a velocidade moderna e o tamanho do conjunto de dados.
Mas isso é apenas MongoDB. Vamos falar sobre o MongoDB Atlas. MongoDB Atlas é uma solução de nuvem totalmente gerenciada para MongoDB. Ele é executado nos três principais provedores de nuvem AWS, Azure e GCP em praticamente todas as regiões do mundo. Ele possui vários recursos inovadores realmente excelentes integrados, como dimensionamento automático, pesquisa de texto completo, Atlas SQL, armazenamento infinito, tabelas e gráficos e muito mais. Quero esclarecer um equívoco sobre relatórios no MongoDB. O equívoco é que NoSQL significa que você não pode fazer relatórios SQL no MongoDB. Com o Atlas SQL , você pode usar um driver JDBC que permite relatórios SQL completos diretamente em uma instância do MongoDB Atlas.
O MongoDB Atlas fornece uma solução totalmente gerenciada que garante disponibilidade e escalabilidade, backup e recuperação com pouco ou nenhum esforço da equipe de devops para mantê-lo funcionando.
Usando a nova stack de tecnologia "Kafcongo"
O que torna essa stack de tecnologia específica tão poderosa é a interação entre Kafka no Confluent Cloud e o MongoDB Atlas. Por um lado, temos um sistema nervoso central com comunicação em tempo real através de uma arquitetura de conectores e, por outro lado, temos um enorme banco de dados escalável. A nuvem Confluent possui mais de 170 conectores totalmente gerenciados na nuvem e um deles é o MongoDB. O MongoDB Source Connector lê os dados à medida que eles mudam em uma coleção do MongoDB e coloca os documentos no Kafka Broker. O MongoDB Sink Connector grava dados de um tópico Kafka em uma coleção MongoDB. O conector funciona tanto em versões de código aberto e comunitárias do Kafka e MongoDB quanto nas versões em nuvem totalmente gerenciadas do software.
O poder aqui são as enormes sinergias entre os dois produtos. O Confluent Kafka atua colocando os dados em movimento, tomando decisões e detectando anomalias à medida que elas ocorrem. O MongoDB atua como a plataforma de aterrissagem perfeita para dados em repouso para ver o que aconteceu e estudar todo o histórico. Entre essas duas tecnologias, você captura todo o ciclo de vida dos dados de um evento.
Modernização Legada
Muitas vezes não é possível para uma organização abandonar os aplicativos legados. Esses aplicativos estão entrincheirados de tal forma em organizações, terceiros e parceiros de negócios que não é possível remover e substituir. O que vejo em muitos clientes é um descarregamento do trabalho de sistemas legados e, ao mesmo tempo, a modernização das ofertas de negócios.
No diagrama acima, podemos ver que os corretores Confluent Cloud Kafka estão recebendo dados de um mainframe IBM em relação aos pagamentos dos clientes. Os aplicativos de mainframe aplicam pagamentos ao banco de dados DB2. O agente IMB DB2i CDC lê os logs do DB2 e produz esses eventos de pagamento para os corretores Kafka em execução na nuvem confluente. Uma vez no Confluent Cloud, duas coisas acontecem em tempo real. O pagamento do cliente é enviado ao Salesforce para que o cliente possa ver que o pagamento foi aplicado à sua conta. Ao mesmo tempo, a cobrança de pagamentos do MongoDB é atualizada pelo conector do coletor MongoDB Atlas.
Uma vez no MongoDB Atlas, todo o conjunto de pagamentos está disponível para análise e geração de relatórios. Relatórios personalizados podem ser executados durante a vida útil de um empréstimo. A base de clientes pode ser analisada para um histórico de pagamentos atrasados por informações demográficas. Isso abre a porta para que um microsserviço esteja disponível para sistemas de terceiros para consultar os dados de pagamento do cliente para estabelecer o valor do crédito para um determinado cliente. Esse novo recurso de pontuação de pagamento do cliente baseado em nuvem agora é uma nova fonte potencial de receita para a empresa.
Embora este seja um exemplo de arquitetura, ele é baseado em vários exemplos do mundo real em uso hoje em bancos e instituições financeiras. A economia de custo é obtida descarregando a maior parte das leituras do mainframe no Confluent Cloud e no MongoDB Atlas. Esse descarregamento é significativo, na minha experiência, isso equivale a reduzir o MIPS em cerca de 60% a 70%, pois a maioria dos MIPS no mainframe geralmente está relacionada a leituras de aplicativos.
Neste exemplo, usamos o Confluent Cloud para migrar dados do DB2 para o MongoDB. Mas há muitos mais exemplos. Para obter mais informações, consulte nossa página de parceiros destacando recursos diretamente relacionados a este artigo. Modernize as arquiteturas de dados com Apache Kafka® e MongoDB
A longo prazo, descarregar as leituras do mainframe é apenas o primeiro passo para a transformação digital. Mas, é um primeiro passo enorme e permite vários novos casos de uso imediatamente. Vamos dar uma olhada em alguns casos de uso do mundo real que utilizaram essas tecnologias para criar novas ofertas e modernizar sistemas legados, tudo em nome da transformação digital.
Trabalhei por cinco anos como Consultor de Vendas (SC) na Oracle, Arquiteto de Soluções (SA) no MongoDB por quatro anos e agora, nos últimos dois anos, trabalho como Engenheiro de Soluções (SE) na Confluent. Os casos de uso a seguir são dois clientes com os quais trabalhei pessoalmente no MongoDB e no Confluent, que têm implementações publicamente referenciadas.
A maioria das discussões arquitetônicas termina com sucesso. Com isso, quero dizer que é difícil argumentar com um exemplo de trabalho do mundo real. Até então, você pode resolver praticamente qualquer problema com qualquer tecnologia e pode facilmente ser pego em discussões intermináveis e sessões de quadro branco. Os quadros brancos não vêm com um compilador. Em outras palavras, todos os diagramas de arquitetura funcionam no papel, mas nem todos funcionam no mundo real.
Com isso em mente, há várias empresas com as quais trabalhei pessoalmente que usaram a nova nuvem confluente e a stack de tecnologia MongoDB Atlas para alcançar a transformação digital, criando um novo serviço ou trazendo nova vida a um serviço legado. Uma pequena lista dessas empresas inclui 7-Eleven, AT&T, JB Hunt, Mr. Cooper e Toyota Financial Services. Estou fornecendo uma recapitulação detalhada das informações públicas disponíveis na web por JB Hunt e Toyota Financial Services nas seções a seguir. Ficarei feliz em fornecer mais detalhes e cores se nos encontrarmos como parte de minha função como engenheiro de soluções na Confluent.
Casos de uso do mundo real com a stack de tecnologia Kafcongo
JB Hunt — Caminhões com capacitores de fluxo
Abaixo, o vídeo de 30 minutos com Donovan Bergin (um engenheiro de software especialista da JB Hunt Transport Services, Inc) é altamente envolvente e divertido de assistir. É um caso de uso do mundo real que permite a transformação digital na JB Hunt para rastrear e monitorar todos os contêineres de caminhões em tempo real, bem como relatar toda a viagem com a stack de tecnologia Kafcongo.
Usei minha própria licença artística para simplificar e aprimorar seu diagrama (com base em seu caso de uso) no meu diagrama abaixo.
Os dados de telemetria de mais de 100.000 contêineres (caminhões, remessas e cápsulas) em toda a América do Norte são rastreados a cada segundo. Tudo, desde a localização do GPS até várias leituras relacionadas à remessa, como temperatura para gerenciamento da cadeia de frio, é coletado a cada segundo de cada contêiner. Além disso, o contêiner de transporte atrás do caminhão vai de vários motoristas do local de coleta original para um depósito para outro motorista para uma viagem cross country para outro depósito para outro motorista na última milha. A JB Hunt também trabalha com a ferrovia BNSF para transporte intermodal, o que significa que o caminhão pode entregar o contêiner para percorrer grande parte da viagem de trem nas ferrovias BNSF.
A ingestão de dados transacionais por si só era muito alta para os sistemas relacionais manipularem. A JB Hunt iniciou uma busca por um sistema ou conjunto de sistemas que pudesse ser usado para alertas em tempo real e relatórios de séries temporais de longo prazo contra os dados de telemetria IoT coletados de seus motoristas com aplicativos móveis, caminhões e seus contêineres.
Donovan usou um exemplo inteligente de envio de cerveja IPA por todo o país, onde a cerveja tinha que ser mantida abaixo de uma certa temperatura para preservar seu sabor. Dois requisitos principais estão em jogo. Um: manter a carga abaixo de uma determinada temperatura e avisar o motorista em tempo real se houver algum problema, e dois: providenciar um relatório de cada etapa da viagem para garantir que em nenhum momento a temperatura no contêiner ultrapassou um limite.
A qualquer momento, o JB Hunt pode ser alertado se a temperatura estiver subindo rapidamente para notificar o motorista para verificar o contêiner. Um exemplo simples pode ser alguém que deixou a porta aberta em uma parada. Ou talvez um fusível tenha queimado no sistema de resfriamento do contêiner. O Confluent Cloud e ferramentas como ksqlDB permitem uma maneira fácil de definir limites para colocar eventos de telemetria em tópicos de alerta especiais lidos por um aplicativo que pode notificar o driver. Este é um exemplo de como as notificações de alerta em tempo real podem permitir que o motorista tome uma ação corretiva. Além disso, todas as métricas podem ser usadas para notificações em tempo real, por exemplo, se o motorista estiver indo para o local errado ou viajando muito rápido ou muito devagar.
Mas o segundo requisito de acompanhar cada etapa da jornada em um banco de dados de séries temporais é um problema real. Donovan convocou três voluntários durante a apresentação. Travis era o motorista do caminhão que pegava no local de origem para entregá-lo ao trem. Philip era o maquinista. Monan era o caminhoneiro que entregava a cerveja no destino final. Donavon disse que é muito fácil obter dados IoT de cada um desses condutores e motoristas e seus equipamentos porque eles estão trabalhando para ele e ele pode ver facilmente os dados em tempo real.
Donovan mudou de marcha, "agora você é o cliente e quer saber a que temperatura sua cerveja estava durante cada trecho da viagem. Você tem acesso a uma API de descanso para poder consultar os dados. Você sabe os nomes dos motoristas ? Você conhece o ID do contêiner? Você conhece algum dos IDs de algum dos dispositivos? Você sabe o período de tempo para consultar cada etapa da jornada? Como cliente, você não tem acesso a essas informações, não deseja consultar os IDs do dispositivo, vá para um banco de dados de séries temporais e consulte esse ID várias vezes para cada trecho da jornada.
O MongoDB oferece muita flexibilidade no design por causa de seus índices secundários nas coleções de séries temporais. Você não precisa saber todas essas informações para juntar tudo porque pode pesquisar o que possui usando índices secundários e o MongoDB fornecerá todas as outras informações. Ele também disse que é bastante útil para o gerenciamento de equipamentos da casa porque é fácil verificar e ver se há problemas ou se as remessas estão sendo entregues no prazo.
Uma observação final sobre a importância da compatibilidade entre nuvens. Todo o recurso de negócios desenvolvido por JB Hunt é fornecido por meio do serviço Kafka totalmente gerenciado em execução na nuvem Confluent e na instância MongoDB Atlas totalmente gerenciada no GCP. Originalmente, JB Hunt havia iniciado este projeto no Azure. Como o MongoDB Atlas e a nuvem Confluent são executados em todos os principais provedores de nuvem (AWS, Azure e GCP), JB Hunt conseguiu evitar o bloqueio do fornecedor com a Microsoft. Eles conseguiram migrar todos os seus sistemas e entrar no GCP em questão de seis semanas.
Se eles tivessem desenvolvido em algo como os hubs de eventos do Microsoft Azure e o Cosmos DB, eles não seriam capazes de mudar para outro provedor de nuvem sem reescrever completamente seus aplicativos. Esta é outra consideração importante ao desenvolver software de aplicativo, tente evitar o caminho "fácil" das ofertas específicas do fornecedor de nuvem. O GCP não oferece suporte a hubs de eventos e o Azure não oferece suporte ao fluxo de dados do Google. O GCP também não oferece suporte ao Cosmos DB.
Serviços Financeiros Toyota
Em fevereiro de 2019, a Toyota Financial Services (TFS) subiu ao palco ao lado da IBM para uma apresentação sobre uma enorme conquista para a modernização do legado do TFS. O TFS conseguiu descarregar uma porcentagem significativa de leituras do mainframe e do Oracle aproveitando o Confluent e o MongoDB. A solução também forneceu informações para soluções de clientes SaaS para aplicar pagamentos em tempo real.
Antes dessa solução, o TFS gastava muito tempo, dinheiro e esforço para reduzir MIPS de mainframe com stacks de tecnologia tradicionais e tinha resultados ruins. Um dos muitos problemas que eles enfrentavam era que o ciclo de lote que extraía as informações de pagamento do mainframe IBM Z Series para serem processadas no Oracle demorava mais de 24 horas para concluir e enviar os pagamentos ao Salesforce. Os clientes que pagavam o financiamento do veículo em dia recebiam notificações de atraso no pagamento devido à lentidão do processamento em lote.
Ken Schuelke, o gerente nacional da fábrica de APIs corporativas, selecionou essa arquitetura porque ela era diferente de muitos outros envios baseados em tecnologias legadas. Essa nova stack de tecnologia permitiu prototipagem rápida com tecnologias modernas como Confluent Platform (Kafka) e NoSQL com MongoDB. Eles chamaram essa nova abordagem usando microsserviços com Confluent e MongoDB de "Enterprise Integration Platform" (EIP).
A apresentação (link acima) foi publicada publicamente pelo arquiteto executivo do IMB Slobodan Sipcic no slideshare.net em 2019. As citações abaixo ecoam tudo o que discutimos anteriormente neste artigo.
Abaixo estão algumas citações e diagramas do artigo.
“A solução inovadora da TFS & IBM para EIP é baseada em ... várias tecnologias de código aberto implantadas sobre ela. A solução é independente da nuvem e utiliza o estilo de arquitetura de microsserviço.”
“A camada de entrega é responsável por otimizar a entrega de eventos e dados entre os componentes da plataforma. NiFi e Kafka constituem um backbone de entrega escalável orientado a eventos da arquitetura EIP."
“EIP utiliza o banco de dados de documentos NoSQL - MongoDB - para manter informações relacionadas a contratos Harmonizados e Materializados por vários motivos, incluindo: Arquitetura de armazenamento alinhada com a estrutura de informações de contrato, Simplicidade de recuperar todos os atributos para uma conta específica - sem necessidade de unir várias tabelas em banco de dados relacional. Capacidade de lidar com grandes volumes de dados, arquitetura escalável e eficiente em vez de arquitetura monolítica.”
A nova plataforma EIP descarregou com sucesso grandes quantidades de leituras do mainframe e ajudou um processo em lote desatualizado executado em um antigo sistema Oracle herdado a atingir o fim de sua vida útil e ser desativado. O projeto começou com a edição comunitária de código aberto do MongoDB, mas desde então migrou para o MongoDB Atlas.
Resumindo, a solução passou de um caro e antigo processo em lote para um processo em tempo real em que os pagamentos dos clientes eram postados no Salesforce assim que eram processados no mainframe. O TFS é mais um exemplo de sucesso do uso da stack de tecnologia Kafcongo no mundo real.
Migrando de Oracle para MongoDB com Confluent
Esta seção deveria ser chamada de “migração de legado: usando a nova stack de tecnologia Kafcongo para sair da velha stack de tecnologia”, mas é muito longa para um bom título. Durante o evento MongoDB .local em Dallas, Texas, em 27 de outubro de 2022, encontrei vários clientes conjuntos entre o MongoDB e o Confluent. Encontrar empresas que usam MongoDB e Confluent juntos é muito mais comum do que você imagina. Não é por acaso que a Confluent ganhou o prêmio de parceiro de tecnologia do ano em 2022 do MongoDB. O motivo são as enormes sinergias entre os produtos e o fato de as duas novas startups terem o mesmo foco no cliente e trabalharem bem juntas além das tecnologias. O gerente de produto e as equipes de vendas formaram uma grande parceria.
Abaixo está um canal do youtube dedicado ao evento MongoDB .local em Dallas em 2022. Sinta-se à vontade para assistir às apresentações dos clientes e ver quantas vezes Confluent ou Kafka é mencionado.
O interessante é que muitos desses clientes estavam muito ansiosos para modernizar os sistemas legados. Muitos deles fizeram exatamente a mesma coisa como prova de conceito. Eles usaram o Apache Kafka de código aberto e a edição da comunidade do MongoDB para testar se era possível migrar dados do Oracle por meio do Kafka para o MongoDB. Falei com 5 empresas diferentes fora da JB Hunt que concluíram este mesmo POC com sucesso.
Foi muito fácil. A prova de conceitos funcionou muito bem e utilizou alguns dos componentes da arquitetura básica que apresentei anteriormente. Vou colá-lo aqui novamente por conveniência.
A estratégia básica é criar uma visualização materializada no Oracle que junte várias tabelas-chave. A visualização materializada é definida para atualização automática. Quando qualquer alteração é feita nas tabelas base, a visualização materializada também é atualizada. Em seguida, implantamos o conector JDBC totalmente gerenciado do Confluent Cloud para ler a visualização materializada no Oracle e publicar esses dados no formato JSON em um tópico.
Em nosso exemplo abaixo utilizamos o tópico "Pedidos de Clientes". O conector JDBC detecta alterações na visualização Oracle e tem a capacidade de converter automaticamente cada evento em um documento JSON. Ele faz essa tradução relacional para JSON automaticamente e desenvolve um esquema com todos os tipos de dados preservados. Esse esquema é acessível por meio do serviço Schema Registry totalmente gerenciado do Confluent e permite que qualquer consumidor do tópico leia, obtenha o esquema e leia os dados do evento em tempo real no formato JSON.
O simples fato de obter dados Oracle em tempo real no Confluent Cloud já é poderoso o suficiente por si só. Os desenvolvedores podem começar a criar aplicativos imediatamente com dados em tempo real no tópico Pedidos do cliente. Mas não seria ótimo colocar esses dados no MongoDB para outros aplicativos, relatórios e análises?
A etapa final é implantar o conector MongoDB para ler os dados diretamente do tópico de pedidos do cliente onde a Oracle produz seus dados CDC. Depois que o conector consome dados do tópico, ele grava esses dados no MongoDB. O resultado foi muito direto, a captura de dados alterados em tempo real agora está fluindo do Oracle direto para o MongoDB.
O melhor dessa solução é que ela não requer código. Para tudo fora da visualização do Oracle, basta configurar conectores e fornecer informações de conectividade. Nenhum agente, ouvinte ou qualquer coisa é implantado no Oracle. Se alguém utiliza um conector totalmente gerenciado na nuvem, a configuração do conector é realizada em questão de minutos. Todos esses dados fluem em tempo real, sem processo lento de ETL em lote. Nenhum conjunto separado de código ETL para manter.
Ao falar com os desenvolvedores e arquitetos que fizeram o POC acontecer, perguntei sobre a quantidade de pessoas da equipe de desenvolvimento que participaram do POC. Na maioria dos casos, foram apenas um ou dois desenvolvedores que fizeram tudo acontecer. Isso gerou bastante burburinho na empresa e novos projetos já estavam em andamento para aproveitar essa migração de legado.
Minha única advertência para eles foi: "Você percebe que isso provavelmente será bem-sucedido e terminará em produção, certo?" Os desenvolvedores com quem falei concordaram.
Eu disse: "E quando ele quebra porque está rodando em produtos de código aberto que você mesmo instalou nas instalações, quem você acha que eles vão ligar às 3h da manhã porque está fora do ar?" Eles reviraram os olhos em reconhecimento.
"Não seria melhor entrar em operação com serviços totalmente gerenciados, como o MongoDB Atlas e o Confluent Cloud? Se cair, nós recebemos a ligação, não você." Eles concordaram novamente. Serviços totalmente gerenciados são fáceis de vender para a equipe de devops sobrecarregada.
Vejo isso como uma tendência que está decolando na base de clientes, começando com versões de código aberto e depois migrando para serviços de nuvem totalmente gerenciados. Este mesmo POC Oracle -> Confluent -> MongoDB foi executado de forma independente em 5 clientes diferentes. Todos tiveram a ideia por conta própria. Isso me faz pensar que um dia será mainstream. Espero que este artigo espalhe a ideia ainda mais.
Conecte comigo e com o Britton no LinkedIn e vamos discutir isso!
Encerrando o artigo com algumas hashtags relevantes: #legacymodernization #oracle #mongodb #digitaltransformation #confluent #kafka #mongodbatlas #kafkaconnect #kafcongo
Comments