APIX Stories POA - Maximizando o potencial do seu negócio

E a ideia é explorar como são as melhores práticas, quais são os pilares que definem uma integração moderna. Quais são as práticas que devemos observar, quais são as ideias centrais, pensando em integração, como maximizar o potencial disso, como tirar o melhor proveito. Eu sou Rafael Cardoso, sou gerente de soluções da Sensedia, e o Leonardo é o nosso arquiteto da área de serviços profissionais. A nossa ideia é fazer uma breve viagem ao passado, entender uma fotografia de diferentes momentos da indústria, da história, da integração entre sistemas. Depois, chegando num momento atual, quais são os desafios que hoje nos impulsionam, que nos apresentam. Apresentar esses pilares e, por fim, inclusive apresentar um case. Então, vamos nessa. Alguns momentos da indústria. Procuramos aqui recortar quatro fotografias. Existem inúmeros pontos que a gente poderia trabalhar quando a gente pensa em como evoluiu a integração, como a indústria se comportou ao longo das últimas décadas quando esse tema está presente. Então, se a gente pensar em quatro pontos, quatro momentos:

‍

Troca de arquivo: lá no início, ainda havia muita troca de arquivo. Essa troca de arquivo, o pessoal mais antigo, cabelo branco que nem eu, vai lembrar. A gente tinha lá um sistema, um momento em que era gerado um arquivo, esse arquivo era enviado para processamentos. Algumas vezes esse processamento até era automatizado, tinha alguma espécie de job ali. Em outros momentos, inclusive, era necessário que um operador fosse lá e disparasse esse processamento do arquivo. Então, não raro, esse processamento levava às vezes 24 horas, até que o arquivo fosse enviado, um operador ou um job disparasse o processamento, gerasse um arquivo de resposta. Essa resposta era devolvida para quem demandou. Às vezes esse ciclo elevava 24 horas ou mais. Por que é importante falar disso? Porque isso nos remete à ideia de que era possível esperar 24 horas para que se fizesse uma integração. A agilidade não era tão acelerada como nos dias de hoje. Então, a gente poder esperar um arquivo ser processado em 24 horas, era até se a gente falasse isso hoje, meu Deus, eu estou no paraíso. Eu não tenho a necessidade de ter algo online, instantâneo. Cliente-servidor: a indústria evolui, tudo evolui. E aí, falando em integração, chegou o momento lá do cliente-servidor. Essa sopa de letrinhas acredito que muitos de nós aqui já passamos. O RPC, o Complus, o Corba. Caramba, agora eu consigo executar uma rotina lá no computador destino, no servidor, e essa resposta vem instantaneamente. Eu já sei se integrou, se não integrou, se o registro entrou, se não entrou, se deu falha, por que deu falha? Porque eu acabei de mandar e eu recebo na hora. Então, já foi uma evolução. Esse tempo foi encurtando. Eu agora estou no real time, vamos pensar assim.

‍

Web services: uma outra fotografia que a gente vai pegar ali adiante, web services em sopa. Caramba, agora eu executo esse RPC, entre aspas, agora eu passo do firewall. Então eu consigo expor serviços para qualquer um consumir. Olha como ficou mais fácil. Agora eu tenho um padrão para fazer isso. APIs REST: e esse padrão evolui para a nossa quarta fotografia. Agora eu já tenho também APIs REST, ficou tudo mais facilitado, ficou mais difundido, ficou mais fácil de fazer. Então, a indústria veio trabalhando esses aspectos, respondendo às necessidades do negócio. Que é eu conseguir fazer as coisas de uma forma mais rápida, mais prática, mais eficiente. Então, a gente teve lá desde o data transfer, P2P, isso veio exercitando diferentes paradigmas, diferentes ideias de integração. Então, hoje a gente fala muito em APIs e micro serviços. E isso nos impulsiona a desafios. Tempos modernos, né? Vocês já pararam? Esseslide até estava na tua apresentação. Então, só relembrando, né? O que nos impulsiona atualmente? Qual é a demanda que nos empurra para nos tornarmos mais eficientes? Então, a transformação digital e eu diria a evolução da indústria, ela é inexorável, ela vai acontecer a gente aceite ou não. Então, como a gente se prepara para melhor responder a isso? Aqui a gente vai falar da ideia de composable. Então, o objetivo certamente não é técnico, mas é a gente pensar que viemos de uma evolução onde tudo era centralizado e agora tudo é distribuído. E essa distribuição nos traz alguns desafios que é como eu mantenho essa malha que está aqui na direita coesa. Como eu mantenho isso através de uma governança adequada? Quais são as práticas que eu preciso para que se antes eu tinha um ponto central que era responsável por todo o meu negócio, vamos dizer assim, agora esse negócio está distribuído. Como é que a gente faz isso?

‍

Então, a composibilidade, e a gente poderia ter aqui uma tarde inteira, né Antônio, só falando de composibilidade. Mas e a gente pensar de uma forma prática em decompor tanto o nosso parque tecnológico, a parte tecnológica que vai responder por isso, mas também o nosso negócio em pequenas peças, em pequenas caixinhas que são independentes, são reutilizáveis e a gente consegue escalar isso de uma forma eficiente para criar outros negócios, para criar outros produtos, para responder outras demandas. Então, dentro dessa ideia de composibilidade, a gente pode trabalhar esses cinco pilares, né Leonardo? E aqui o Leonardo vai contar para a gente um pouquinho de como que se trabalha este framework, pensando em excelência operacional, pensando em segurança, confiabilidade, eficiência e performance e principalmente uma redução de custos com prevenção de falhas. Então, aqui a gente tem uma visão da indústria, né? Então, pessoal, falando um pouquinho de jornadas modernas, né? Quando a gente está falando de jornadas modernas hoje, né? Como o Rafa falou anteriormente, a gente tinha uma tecnologia centralizada, onde a gente tinha um único ponto, né? Que deveria ser feito toda a parte de gestão, de governança e hoje, quanto mais real-time que a gente atende nos nossos processos, nossas jornadas digitais, a gente precisa criar tantos times, processos e quanto mais granular a nossa aplicação, ela acaba sendo entregue aqui nesse espectro, né? A gente tem uma complexidade muito maior. Então, quanto mais distribuída é a nossa jornada, é maior ainda a nossa complexidade. O Web Architecture Framework, por exemplo, ele não é algo inventado, cunhado pela Sensedia, né? É uma prática de mercado. Então, quando a gente fala de Web Architecture, isso é, cada uma das clouds, basicamente, vem e traz o seu modelo de operação próprio das suas próprias boas práticas quando a gente está falando de arquiteturas distribuídas e arquiteturas modernas.

‍

Então, trazendo aqui para você, né? Basicamente, né? um market share da infraestrutura cloud, né? A gente fala muito que a infraestrutura cloud hoje é um mercado de um trilhão de dólares, né? Então, a gente tem aqui hoje, né? Três grandes clouds que dominam, basicamente, o mercado, mas ao mesmo tempo que a gente tem dominância, a gente tem outras clouds surgindo e surgindo muito forte no mercado, né? A gente tem um exemplo da Oracle, por exemplo, que acabou trazendo recentemente que fechou parceria com o Uber, né? Então, ao mesmo tempo que a gente tem essa dominância de clouds, ela é muito aberta. Então, como é que a gente cria modelos de trabalho para que a nossa organização seja resiliente, inclusive, às transformações de mercado, né? Então, aqui a gente fala muito mais sobre como que a gente garante que esse fundamento seja muito bem estruturado e não fique à mercê exclusivamente deuma cloud, né? Então, a gente, como Sensedia aqui, né? A gente fala muito dentro das frentes de Professional Services aqui e nas jornadas com os nossos clientes a gente tem vários tipos de pontos que a gente atende dentro do nosso contexto que apoiam o nosso cliente focado unicamente nos princípios, fundamentos para que a gente entregue produtos com maior qualidade de entrega e atenda as expectativas de negócio principalmente. Então aqui esse ponto é muito mais focado na estratégia digital junto com a estratégia tecnológica. Então falando sobre os pilares de Well Architected aqui, a gente trouxe basicamente as três maiores clouds que existem hoje, não é uma anonimidade aqui, cada uma tem seus próprios pilares, todas de forma geral tem os pilares muito similares. Com exceção da AWS, a AWS recentemente, no ano passado, lançaram o pilar de sustentabilidade. Então tirando a AWS, todos os demais possuem os mesmos pilares, incluindo a Oracle Cloud que fica nesse mesmo conjunto, certo?

‍

Então quando a gente fala aqui de excelência operacional, o que a gente está falando aqui basicamente? É como que a gente garante que a nossa aplicação vai ser entregue em ambientes produtivos e não produtivos. Então basicamente dentro dessa jornada a gente tem quatro grandes grupos, que é o grupo de como que a gente constrói e a gente entrega a nossa aplicação. Então a gente entra muito nos processos de pipelines, de CICD, de infraestrutura como código, externalização das configurações para que a gente consiga ter a possibilidade de ser versátil, tanto no ambiente produtivo quanto no ambiente não produtivo. Então isso garante que a gente possa antecipar as nossas falhas. Então a gente consegue criar ambientes controlados para a gente poder fazer cargas de teste, processos em ambientes não produtivos, teste end to end. E incluindo isso a gente consegue ter uma melhor garantia de prevenir e ter uma cultura de melhoria contínua no nosso processo de trabalho.

‍

Então o primeiro pilar basicamente é focado exclusivamente em como nós entregamos as nossas aplicações. O segundo pilar aqui basicamente ele é o pilar da segurança. Então aqui a gente fala de segurança em ambas as camadas. Então ele entra desde a camada de redes até como os nossos times de desenvolvimento fazem parte e entram dentro da nossa jornada digital. Principalmente aqui depois quando a gente está falando do home office, que a gente teve que criar políticas, teve que adequar muitas coisas para que os times de desenvolvimento estivessem conectados dentro da nossa infraestrutura corporativa em um ambiente que a gente não conseguiria controlar. Então aqui entra desde a questão de identity provider, federação, single sign on, multi-factor authentication. Entra também a camada de como que a gente garante a autenticação e autorização das nossas aplicações. Entra dentro como que a gente garante que não sejam esfiltrados nossos dados. Então aqui a gente fala tanto do tráfego que entra de borda, quanto o nosso tráfego last to end. Nosso tráfego de borda basicamente é aquilo que entra do mundo externo para dentro dos nossos contextos, das nossas aplicações, sejam elas sistemas legados, sejam elas nossos monolitos. E o tráfego last to end entra na questão de como as nossas aplicações internas se comunicam entre os nossos microserviços. Então trazendo lá no contexto do passado, dos slides anteriores, que a gente falou que uma jornada composta, ela é formada de processos, times e tecnologias, quanto mais granular é a nossa aplicação, e hoje cada vez mais os nossos times são mais granulares, fazem partes compostas de uma única jornada, como que eu vou expor o meu serviço, a minha aplicação, para que eu consiga garantir políticas de segurança, não apenas para fora da empresa, mas para dentro da organização, entre equipes próximas. Então aqui a gente fala tanto da parte de data loss prevention, a parte de como que a gente entrega dentro de uma jornada do nosso microserviço que vem do pilar anterior, e garantir que, por exemplo, as boas práticas de segurança sejamaplicadas através de um quality gate, como que a gente garante através dos princípios cloud, dos 4Cs de segurança, e por último como que a gente não perde que os nossos dados sejam expostos para sejam filtrados. Então a gente entra com uma série de princípios e políticas aqui.

‍

Falando um pouco sobre o pilar da confiabilidade. O pilar da confiabilidade é basicamente como que a gente garante que a estratégia da nossa aplicação ela esteja resiliente e garanta o máximo de uptime possível dentro da nossa jornada. Aqui a gente tem um grande contexto que o pilar da confiabilidade e o pilar do financeiro acaba entrando em conjunto em conflito em alguns momentos. Porque quanto maior é a confiabilidade das nossas aplicações maior é o custo operacional. Então a gente acaba sempre tendo que balancear que a gente é meio que um cobertor curto. Se a gente tapa a cabeça a gente tapa os pés. Então a gente tem que estar sempre balanceando entre um e outro. Então quando a gente fala aqui de como que a gente garante a arquitetura dos nossos workloads vem desde a nossa jornada de monolitos, a nossa jornada de serviços legados, a nossa jornada de micro serviços e por último a nossa jornada de funções ou até mesmo jornadas de lâmbidas ou produtos similares. Então aqui basicamente é como que a gente garante que a nossa aplicação ela vai poder estar distribuída, seja em uma zona, região, multiregião. E a gente tem aqui também, além da confiabilidade a gente tem ferramentas que podem nos auxiliar e compor a nossa jornada de confiabilidade. Um exemplo que nós temos aqui é o próprio Service Mesh, que ele aplica políticas de engenharia do caos e garante que as nossas aplicações possam ser feitos testes e simulações em ambientes produtivos e não produtivos, por exemplo. Então se eu quiser poder fazer uma simulação de o que acontece se um dos meus micro serviços parar de responder ou o que acontece se um dos meus micro serviços simplesmente gerar uma latência maior. Onde é que vai quebrar? Então a gente consegue balancear através desse princípio como que a gente garante a maior confiabilidade das nossas aplicações. E por último, a gente tem a garantia da escalabilidade, trabalhando de forma preventiva para que quando esses cenários aconteçam, quais são os possíveis processos que a gente pode melhorar e automatizar para que não aconteça futuramente.

‍

Falando aqui então do pilar de eficiência e performance. O pilar de eficiência e performance basicamente é como que a gente utiliza e maximiza a nossa arquitetura e nossos serviços de uma forma que a gente consiga extrair o máximo de performance e o turning das aplicações. Então aqui muitas vezes a gente comenta que quando a gente está numa jornada de estratégia, de estrangulamento de um monolito, de estrangulamento de uma aplicação legada, será que é a melhor abordagem a gente sempre ir para o cenário de microserviço? Será que não é melhor a gente poder aproveitar outros produtos e ferramentas que as próprias clouds oferecem dentro do nosso contexto? Então o ponto que a gente traz aqui é, será que sempre quando a gente vai resolver um problema dentro da nossa organização, a gente sempre tem que usar o mesmo tipo de tecnologia e recurso? Então aqui a gente acaba falando um pouco mais sobre os trade-offs de cada um dos nossos modelos de atuação. Então aqui a gente entra sobre tanto a parte de performance de arquitetura, que trata um pouco sobre como que a gente entrega de uma forma performática as nossas aplicações. A gente fala sobre eficiência de arquitetura, então quanto que junto com a nossa confiabilidade, a nossa arquitetura, ela consegue estar sendo eficiente dentro do nosso contexto de negócio.

‍

A experimentação, basicamente é como que a nossa aplicação vai se comportar em ambientes que a gente não conhece. Então entra um pouco junto com o pilar de confiabilidade e eficiência. E o dimensionamento da capacidade, será que os meus serviços sempre precisam estar operando no maior volume possível, no limite de uma aplicação, no limite do meu cluster, no limite do meu nó de serviço? Ou não, eu posso ter uma infraestrutura que possa ser escalável. Então assim, a gente trata a eficiência e performanceaqui dessa forma. E por último, não menos importante, acho que esse é um pilar que entra muito em voga, que hoje é uma dor que a gente vê. Vai entrar muito em voga que hoje é uma dor que a gente vê diariamente dentro dos times, que é como que a gente consegue gerir os nossos recursos de tecnologia e garantir a melhor eficiência e custo das nossas aplicações, né? Então, um exemplo aqui que a gente pode tratar é basicamente se eu vou ligar uma aplicação em ambiente não produtivo e produtiva 24x7 e eu troco simplesmente isso em ambiente não produtivo para 8x5, eu posso ter um saving aqui de mais de 50% dentro da minha jornada de negócio, né? Então, a gente fala como que a gente consegue garantir que essa otimização de custos ela siga sendo tratada e evoluída a ponto de que será que sempre a minha aplicação precisa estar sendo no limite, né? Sempre numa maior infraestrutura para sustentar minha operação? Eu consigo ter esse tipo de monitoração para eu conseguir medir se eu estou sempre no meu limite ou está numa capacidade aceitável? E aqui basicamente a gente trouxe para vocês um cenário de como que a gente apoiou um dos nossos parceiros dentro da Sensedia aqui, no ano passado, onde o nosso cliente tinha um produto que foi lançado no MVP de passagem de praças de pedágio. Então, o nosso cliente no primeiro MVP foi feito um simples teste de como que eles conseguiriam, para ver se ia ter adesão ao mercado, como que iria se comportar esse produto dentro da jornada deles e rapidamente o produto foi um sucesso. Então, foi uma dor boa que cresceu muito rápido e eles precisavam ter a possibilidade de disponibilizar e melhorar a sua arquitetura através de diversos gaps técnicos. Então, eles tinham muitos problemas, por exemplo, com altas volumetrias em horários inesperados, altas volumetrias em horários esperados, por exemplo, feriados, finais de semana, enfim, e como é que eles conseguiriam garantir que esses gargalos fossem adequados nas melhores horas.

‍

Então, aqui basicamente essa foi uma das soluções que nós trabalhamos. Então, basicamente a gente tem três momentos da nossa jornada aqui:

A passagem das praças de pedágio.

Automaticamente, toda passagem transacional quando chegava, ela era assíncrona, o nosso cliente não ficava pendente de uma resposta, a gente emitia que a resposta seria ser retornada de forma assíncrona.

Em paralelo a isso, disparava uma série de eventos e outros produtos.

Então, em momentos separados da nossa jornada, nós trabalhamos com:

Cluster, Kubernetes EKS

Lambdas Functions

Serviços de ETL

Serviços de bancos de escrita versus bancos de leitura

‍

Então, nem sempre a forma com que a gente abordou aqui nessa solução foi orquestrada e formada diretamente e exclusivamente para a gente poder atender clientes diferentes em jornadas diferentes com os mesmos produtos. Então, o produto que o nosso time de negócio, que dentro da nossa organização estava sendo construído um Data Lake na época, tinha uma formatação que expurgava os dados para um bucket que custava um quinto do que custava a operação num banco de dados não relacional. Então, nem sempre a solução quando a gente vai tratar, ela vai ser o mesmo tipo de solução para todos os nossos usuários. O usuário transacional aqui sempre vai acabar sendo o usuário principal porque é o usuário que precisa da resposta em tempo real, ou o tempo mais próximo possível do real. Já o nosso usuário que vai consultar informações, ele não precisa daquele dado extremamente quente, ele pode ter um dado um pouco mais atrasado para ele poder consumir a informação. Já o nosso cliente que vai estar fazendo a parte analítica dentro do nosso processo de negócio, ele pode ter um dado com 24 horas de atraso. Então, nem sempre quando a gente vai tratar as nossas soluções são sempre focadas sempre na mesma jornada ou os mesmos produtos.

‍