Web appOpen in Telegram
MMicroServices Brasil

MicroServices Brasil

@microservicesbr · group · Tech · indexed since 2026-07-30
633members+7 in a week
3writing in 30 days
4messages in 30 days
11 129messages in the index
L
Link
click to show
𝗠𝗶𝗻𝗶𝗺𝗮𝗹 𝗔𝗣𝗜𝘀 𝗽𝗮𝗿𝗮 𝗥𝗮𝗯𝗯𝗶𝘁𝗠𝗤: 𝗰𝗼𝗻𝘀𝘂𝗺𝗶𝗻𝗱𝗼 𝗳𝗶𝗹𝗮𝘀 𝗲𝗺 .𝗡𝗘𝗧 𝘀𝗲𝗺 𝗰𝗼𝗺𝗽𝗹𝗶𝗰𝗮𝗰̧𝗼̃𝗲𝘀 𝗰𝗼𝗺 𝗢𝗿𝗮𝗴𝗼𝗻.𝗥𝗮𝗯𝗯𝗶𝘁𝗠𝗤! 📆 HOJE, quarta-feira, dia 26/02 ⏰ 21h (horário de Brasília) 📺 Canal .NET - Youtube Acompanhe neste novo evento ONLINE e GRATUITO do Canal .NET como simplificar a implementação de aplicações .NET que consumam mensagens do RabbitMQ, utilizando o projeto open source Oragon.RabbitMQ. Esta solução - lançada de forma oficial recentemente (Dezembro/2024) - é similar às Minimal APIs do ASP .NET Core, evitando assim dezenas de linhas de código na implementação de Workers para consumo de mensagens... Mensageria, arquiteturas distribuídas e microsserviços, boas práticas e muito mais! 🎯 https://share.gago.io/URz7 🐊 🚨 Minimal APIs para RabbitMQ: consumindo filas em .NET sem complicações com Oragon.RabbitMQ! https://share.gago.io/URz7
2 · 1.1K ·
L
Link
click to show
Não são poucos os momentos de indignação quando me deparo com narrativas construídas sobre o vazio. Usar do desconhecimento e da preguiça para construir argumentos falsos é um absurdo. Dizer que "A AMAZON ABANDONOU MICROSSERVIÇOS" por conta da volta para o monolito no caso do 𝘀𝗲𝗿𝘃𝗶𝗰̧𝗼 𝗱𝗲 𝗶𝗻𝘀𝗽𝗲𝗰̧𝗮̃𝗼 𝗱𝗲 𝗾𝘂𝗮𝗹𝗶𝗱𝗮𝗱𝗲 𝗱𝗲 𝗮́𝘂𝗱𝗶𝗼/𝘃𝗶́𝗱𝗲𝗼 do Amazon Prime é de uma desonestidade intelectual gritante. Temos muitos outros exemplos, mais plausíveis, como o da Segment. Entenda a análise que fiz na época sobre do que se trata esse projeto, é muito importante entender o contexto para não usar como alicerce, um argumento que só convence quem está redondamente perdido sobre o assunto. Um argumento inadequado ou falacioso tem o poder de comprometer toda a sua defesa, portanto, honestidade intelectual é o primeiro requisito de uma sustentação de ideias. Ser pego de calças curtas, quando se falta com a verdade é apenas uma questão de tempo... Segue a análise... https://share.gago.io/Ub1D https://share.gago.io/Ub1D
2 · 1.2K ·
L
Photo
click to show
Concorrência e Race Condition com Cache Distribuído: O Workflow correto e a importância de Double-checked locking Se você está vendo cache distribuído pela primeira vez, talvez tenha deduzido qual é a forma adequada de trabalhar com ele. A pergunta que fica é: você levou em conta a concorrência? A questão é que, quando o cache expira, devemos usar o recurso “lento” para produzir o dado que será cacheado. Mas, se estamos falando de aplicações distribuídas, o que impede de 100 usuários de chegarem a uma página que não possui cache no mesmo instante? O que acontece se essas 100 navegações demandarem o acesso ao recurso “lento” para pegar os mesmos dados, fazendo as mesmas queries para obter o mesmo objeto centenas de vezes? Race condition, ou condição de corrida, é uma falha de software que ocorre quando duas ou mais operações são executadas simultaneamente, de forma não coordenada, sem que devessem ser executadas simultaneamente. Como acontece? Ocorre quando várias threads acessam e modificam dados compartilhados ao mesmo tempo. Pode parecer difícil acontecer, mas não, é mais comum do que se imagina. Basta uma pequena contenção, como causada por um deploy, ou a subida de novas instâncias de uma aplicação para que o problema, que é de difícil análise, aparecer. Nesse post temos exemplos com código e um playground para você ver o impacto direto no browser. https://share.gago.io/X0ic
4 · 1.2K ·
V
Photo
click to show
Já imaginou mergulhar nos bastidores do C6 Bank e ainda sair com a chance de construir um novo capítulo na sua carreira? De 26 a 29 de maio, vamos abrir nossas portas para a primeira edição da C6 Tech Week — uma semana feita por quem respira tecnologia de verdade, com temas como Inteligência Artificial, Cyber Security, Data & Analytics. Uma agenda intensa, técnica e pensada para quem acredita que dá pra fazer diferente. Quer fazer parte? Inscreva-se aqui: ➡️ 26/5 às 18h | Por trás do App: Como o C6 construiu uma tecnologia de ponta https://lnkd.in/d5aizyJE  ➡️ 27/5 às 18h | Como a IA impulsiona o C6 para o futuro https://lnkd.in/dU2u7f-j  ➡️ ️28/5 às 18h | Cyber Security https://lnkd.in/djEBqbGs  ➡️ 29/5 às 18h | Decifrando dados: Como o C6 transforma informação em decisão https://lnkd.in/dbAXJZ8d
R
Link
click to show
🟠 [Online|13:30|Microservices + Grafana + OpenTelemetry: monitoramento|Gratuito] Fala galera! Daqui a pouco - a partir das 13:30 - horário de Brasília - estreia mais um vídeo gratuito - com chat ao vivo para dúvidas - no Canal .NET. Confira neste conteúdo um novo exemplo de monitoramento da comunicação entre aplicações via tracing distribuído, utilizando desta vez Grafana (dashboards de monitoração), Tempo (traces), OpenTelemetry (instrumentação), Alloy (coletor de traces e logs) e Loki (logs)... Uma implementação simplificada com .NET 9 + ASPNET Core + PostgreSQL + Docker Compose, mas bastante útil para compreender melhor a adoção de práticas de observabilidade em cenários que envolvam aplicações distribuídas e microsserviços nas mais variadas stacks: https://www.youtube.com/watch?v=zYCwEynYwKI
4 · 1.5K ·
R
Link
click to show
🟠 [Online|13:30|Microservices + Elastic + OpenTelemetry: monitoramento|Gratuito] Fala galera! Daqui a pouco - a partir das 13:30 - horário de Brasília - estreia mais um vídeo gratuito - com chat ao vivo para dúvidas - no Canal .NET. Confira neste conteúdo um novo exemplo de monitoramento da comunicação entre aplicações via tracing distribuído, utilizando OpenTelemetry (instrumentação), Docker Compose, PostgreSQL, MySQL e a stack Elastic - APM (traces), Kibana (dashboards de monitoração), Elasticsearch (persistência)...E desta vez com implementações que se comunicam entre si e baseadas em .NET 9 + ASPNET Core, Java + Spring + Apache Camel e Node.js: https://www.youtube.com/watch?v=ZRLjxnVtHPM
2 · 1.6K ·
R
Link
click to show
[Online|13:30|Microservices + Jaeger + OpenTelemetry: monitoramento|Gratuito] Fala galera! Daqui a pouco - a partir das 13:30 - horário de Brasília - estreia mais um vídeo gratuito - com chat ao vivo para dúvidas - no Canal .NET. Confira neste conteúdo um novo exemplo de monitoramento da comunicação entre aplicações via tracing distribuído, utilizando OpenTelemetry (instrumentação), Docker Compose, PostgreSQL, MySQL e Jaeger (dashboards de monitoração + traces)... E desta vez com implementações que se comunicam entre si e baseadas em .NET 9 + ASPNET Core, Java + Spring + Apache Camel e Node.js: https://www.youtube.com/watch?v=oF3HKHTZkEg
1 · 1.8K ·
L
Photo
click to show
Reduzir a burocracia na hora de consumir filas, e ainda assim manter essência do RabbitMQ foi o ponto de partida para a criação do Oragon RabbitMQ. Com a missão de ser Resiliente by Default, inverto a lógica natural e começamos com todas as garantias habilitadas. Em um fluxo tão simples, quanto uma Minimal API. Acompanhe neste novo evento ONLINE e GRATUITO do Canal .NET como simplificar a implementação de aplicações .NET que consumam mensagens do RabbitMQ, utilizando o projeto open source Oragon.RabbitMQ. Esta solução é similar às Minimal APIs do ASP .NET Core, evitando assim dezenas de linhas de código na implementação de Workers para consumo de mensagens... Mensageria, arquiteturas distribuídas e microsserviços, boas práticas e muito mais! Palestrante: Luiz Carlos Faria (Microsoft MVP, MTAC) Hoje: 21h https://share.gago.io/gNsJ
1 · 1.1K ·
R
Link
click to show
🟢 [Online|18:15|Microservices + Jaeger + OpenTelemetry: monitoramento|Gratuito] Fala galera! Daqui a pouco - a partir das 18:15 - horário de Brasília - estreia mais um vídeo gratuito - com chat ao vivo para dúvidas - no Canal .NET. Confira neste conteúdo um novo exemplo de monitoramento da comunicação entre aplicações via tracing distribuído, utilizando Jaeger (dashboards de monitoração + traces), OpenTelemetry (instrumentação), Docker Compose, PostgreSQL, MySQL e Redis... E desta vez com implementações que se comunicam entre si e baseadas em .NET 9 + ASPNET Core, Java + Spring + Apache Camel e Node: https://www.youtube.com/watch?v=ow0GZiAdJI4
3 · 2K ·
A
Link
click to show
Você realmente confia nos seus sistemas distribuídos? Muita gente acredita que distribuir um sistema é “só adicionar mais servidores". A maior falha começa quando assumimos que tudo vai funcionar e aí a realidade vem com aquele tapa técnico na cara. Muita gente entra no mundo de microsserviços e arquiteturas distribuídas acreditando que basta escalar, replicar e colocar tudo em containers que magicamente tudo vira alta disponibilidade e resiliência. Mas existe um conjunto de falácias que continuam derrubando equipes, sistemas e egos até hoje. Nesse meu vídeo, eu falo sobre essas Falácias dos Sistemas Distribuídos: ideias equivocadas que surgem quando projetamos sistemas complexos e assumimos que tudo vai se comportar de forma perfeita (principalmente quando o profissional é iniciante). Um exemplo? A crença de que “a rede é confiável”. Se você já teve timeouts inexplicáveis, latência inesperada, mensagens perdidas, partições de rede ou simplesmente um “funcionava na minha máquina”, você sabe do que estou falando. Sistemas distribuídos não perdoam suposições. E entender essas armadilhas é essencial para qualquer desenvolvedor ou arquiteto que queira construir software robusto, escalável e resiliente de verdade. No vídeo eu comento sobre cada falácia, trago reflexões e práticas de uma lista que foi elaborada há muito tempo, mas que ainda se mostra muito atual. Esse é o tipo de conteúdo que, na minha opinião, pode abrir os olhos de quem acha que tudo é mil maravilhas e que pode evitar muitos erros caros lá na frente. 📽️ Assista agora: https://www.youtube.com/watch?v=IE3_a6M6gxQ
R
Photo
click to show
🟡 [Ao Vivo|21:00|.NET Aspire: Microservices, containers...|Gratuito] Fala galera! Daqui a pouco - por volta das 21:00 - horário de Brasília - teremos mais um evento ONLINE e GRATUITO no Canal .NET. Acompanhe nesta nova live uma visão em profundidade da implementação de microsserviços e aplicações distribuídas com .NET Aspire -> práticas de observabilidade, cloud native, containerização, integrações com mensageria, serviços de bancos de dados, caching e muito mais: https://www.youtube.com/watch?v=042ENxqERGQ
2 · 1.4K ·
M
MicroServices Brasil
unsupported
click to show
M
MicroServices Brasil
Photo
click to show
Uma dica importante para quem quer fazer conta sobre escala, ou volume de operações. Em alguns tipos de sistema o volume crítico é condensado em uma janela de tempo que representa uma fração do dia. Quem já viu na mentoria as planilhas que levam em conta a hora do dia, vai lembrar. Esse é um gráfico de produção, real. Então projetar o workload como se fosse diluído ao longo do dia, gera inconsistência com a realidade. Fazer a conta com X operações por dia para deduzir Y operações por hora, geraria um número irreal. Saber que 50%, 75% até 90% do workload será realizado durante uma janela de pico, faz pensarmos em números mais realistas. Essa é uma lembrança de que esse entendimento importa.
2 · 460 ·
M
MicroServices Brasil
Photo
click to show
Estratégias de alocação em SaaS multi-tenant (maturidade nível 4) Em modelos SaaS que atingem o nível 4 de maturidade: multi-tenancy pleno, com instância única compartilhada e escalabilidade horizontal. A distribuição da alocação de tenants pode ser escolhida conforme a demanda e os objetivos do negócio. Há duas estratégias fundamentais, e elas expressam filosofias opostas de arquitetura: 1) Consolidação (bin packing): saturar um nó antes de abrir o próximo. Toda a capacidade de um nó é ocupada e, somente ao atingir seu limite, um segundo nó entra em cena. Nesse caso, privilegiamos densidade e, por consequência, eficiência econômica: máxima utilização de recursos, menor número de nós ativos, menor custo de infraestrutura e de licenciamento, possibilidade de desligar nós ociosos (scale-to-zero parcial). É a lógica do utilitarista: o maior aproveitamento pelo menor custo. 2) Espalhamento (spreading): distribuir os tenants por diversos nós desde o início. A carga é diluída horizontalmente, mantendo todos os nós com folga operacional. Nesse caso, privilegiamos resiliência e disponibilidade. O espalhamento reduz o blast radius: a falha de um nó afeta uma fração pequena dos tenants; há headroom para absorver picos súbitos de demanda sem cold start; e diminui-se o efeito noisy neighbor, pois tenants ruidosos ficam isolados por menor densidade de coabitação. — Nesse projeto optamos pela 2a opção, por se tratar de um projeto que já nasce com mais de 3 mil clientes conectados.
1 · 611 ·
M
MicroServices Brasil
Photo
click to show
Hoje, 21h, no Canal .NET: Event Driven Architecture — o que você precisa entender antes de adotar. Nos últimos 13 anos trabalhando com mensageria e RabbitMQ, recuperei projetos de todos os tamanhos: Bancos, startups de música, dpvat, a integradoras de WhatsApp, que fracassaram ao adotar mensageria. O padrão se repete: não é a tecnologia que falha, é a falta de fundamento por trás das decisões técnicas que impactam negócio. Hoje vamos sair da implementação e falar do que vem antes dela: os conceitos essenciais de Event Driven Architecture e as decisões que parecem corretas no papel, mas sabotam o projeto em produção. O Oragon.RabbitMQ aparece como pano de fundo, mas o assunto é arquitetura — e vale para qualquer stack. Nosso compromisso: cada live tem que valer mais que curso pago sobre o assunto. Em troca, pedimos só presença e like. Te espero às 21h no Canal .NET no youtube. https://share.gago.io/-MqC
2 · 991 ·
M
MicroServices Brasil
Link
click to show
🔴 AO VIVO daqui a pouco, 21h Mesa Redonda Cloud Native ! Kubernetes, Microservices, Arquiteturas, projetos e nuvem... Acompanhe neste novo evento ONLINE e GRATUITO do canal Coding Night um bate-papo descontraído sobre Cloud Native: o que realmente é, sua importância para empresas e a nuvem, projetos interessantes, containerização, Kubernetes, infra, nuvem e muito mais! https://share.gago.io/-l9q https://share.gago.io/-l9q
1 · 1.6K ·
  1. M
    MicroServices Brasil
    é uma discussão muito rica que dá para aprofundar muito. Mas o principal é que tenho visto os problemas do passado, que demandaram esse tipo de solução de arquitetura, design, praticas e princípios, se perdendo. Deixamos de ter os problemas com deturpações sobre responsabilidades, e portanto 2 gerações depois, camadas estâo sendo abolidas. Monolito modular, é um convite aos problemas que camada resolveram no passado. Microsserviço, fracassou não por ser ruim, mas porque a média é incompetente pra caralho! Monolitos foram apedrejados porque é mais facil dizer que o problema é da arquitetura do que assumir que não sabe resolver problemas de acoplamento e não possuem paciência, humor, saco, para ter discussôes filosóficas sobre responsabilidades, escopo, camadas, módulos, etc
Whole thread · 1 reply →
R
Link
click to show
🟠 [Online|13:30|Arquitetura Microservices: o case real da Grafana Labs|Gratuito] Fala galera! Daqui a pouco - a partir das 13:30 - horário de Brasília - estreia mais um vídeo gratuito - com chat ao vivo para dúvidas - no Canal .NET. Confira neste conteúdo um exemplo real de implementação de uma arquitetura de microsserviços na Grafana Labs, a partir do uso do projeto Dapr (Distributed Application Runtime), containers, ambientes baseados em Kubernetes e diversas outras tecnologias cloud native: https://www.youtube.com/watch?v=qBHIdd7jyWU
R
Link
click to show
🟠 [Online|23:15|Microservices: implementando o uso de secrets com Dapr|Gratuito] Fala galera! Daqui a pouco - a partir das 23:15 - horário de Brasília - estreia mais um vídeo gratuito - com chat ao vivo para dúvidas - no Canal .NET. Confira neste conteúdo como implementar a utilização de secrets de forma descomplicada com o projeto Dapr (Distributed Application Runtime)... Tudo isso em um exemplo que inclui o uso de variáveis de ambientes ou secrets do Azure Key Vault, com monitoramento via OpenTelemetry + Tempo + Grafana e um script do Docker Compose para a criação do ambiente de testes: https://www.youtube.com/watch?v=qBMr40cM-sc

An open public feed from the search index ChatCrawler — “Google for public Telegram”; refreshed as the venue is crawled. Times are UTC.

Public content only, official Telegram API. About · FAQ · What we do not do · Remove a page · Catalog · Search · How we count