A arquitetura de microsserviços vem ganhando cada vez mais foco atualmente. Porém, somente utilizar um orquestrador de containers não torna sua infraestrutura eficiente. Nesta talk vamos falar sobre como podemos utilizar todo o poder de ferramentas de Integração contínua para dar super poderes aos seus containers!

No mundo dos micro serviços, a comunicação entre eles pode se tornar mais um fator de complicação, tanto para os sysadmins, que precisam gerenciar essa comunicação, como para os desenvolvedores, que as vezes precisam adaptar o código para lidar com "coisas" de rede, que não fazem parte do negócio da aplicação.

Istio torna a comunicação entre os micro-serviços (servive mesh) uma tarefa mais fácil de gerenciar, do ponto de vista dos sysadmins, e, do ponto de vista dos desenvolvedores, tira a complexidade da aplicação de ter que lidar com problemas de rede, como Circuit Breakers, Retries, Load Balacing, etc.

Eba! Temos microservices! Agora tudo está resolvido: podemos escalar, distribuir e orquestrar nossos serviços sem qualquer preocupação!

Será? Já parou para pensar nos dados de cada serviço? E nos dados compartilhados entre eles? E pior: já pensou nas transações entre serviços?

O modelo ACID já não serve mais. Transações distribuídas menos ainda. Como fazer então?

Para isso existe o padrão de Sagas! Com ele é possível resolver esse problema de uma forma inteligente, consistente e alinhado ao paradigma de microservices.

Afinal, de que adianta dezenas, centenas... milhares de microservices, se os dados não forem confiáveis?

Quando você começa a pensar em microserviços, uma peça importante nisso tudo é o domínio dos dados. Nem sempre as fronteiras das definições dos dados são tão claras, em alguns momentos você pode precisar que os dados dos seus microserviços conversem entre si e nesse momento o Debezium pode te ajudar. Ele monitora mudanças do seu banco de dados e publica em tópicos do Kafka automaticamente para você.

Com isso você consegue fazer com os seus micro(serviços) tenham dados consistentes e suas aplicações podem trabalhar independentemente e focar nas suas responsabilidades.

As aplicações modernas, principalmente serviços, são criadas para que possamos reaproveitar as funcionalidades em diferentes contextos. Dentre estes contextos, temos frontends distintos como navegadores, celulares, Smart TVs, IOT, etc.

Um pattern existente para que possamos manter nossos serviços isolados das implementações de frontend é o BFF (Backend for Frontend). Nessa palestra iremos apresentar este pattern, seus benefícios e algumas dicas do que aprendemos ao utilizá-lo.

Monitorar nossas aplicações é essencial para a sobrevivência de nossos produtos, mas o que devemos monitorar? Nesta palestra pretendo falar um pouco sobre os tipos de métricas, modelo de infraestrutura e como implementar em Java.

O objetivo desta palestra é mostrar como é possível construir uma aplicação baseada na idéia de MonolithFirst e atrasar a decisão de separar em microserviços. A ideia de modular monoliths vem da organização e separação da sua aplicação em módulos ou componentes autônomos que se relacionam entre si, mas estão dentro de uma mesma base de código. Nesta palestra será mostrado como identificar e separar estes módulos, além de um processo que permite extrair um módulo e distribuir como um microserviço.

Aplicações utilizando arquitetura em microsserviços são cada vez mais comuns hoje em dia, entretanto, há necessidade de monitorar e garantir a segurança de cada microsserviço. A proposta é apresentar desafios como autenticação e autorização dos serviços, transmissão de dados sensíveis e registro de dados, bem como suas possíveis soluções para mitigar e solucionar essas questões.

A arquitetura de microsserviços distribuídos transforma aplicações monolíticas em pedaços menores que podem ser compostos conjuntamente.

No ambiente de microsserviços, há questões de descoberta de serviços, balanceamento de carga, tolerância a falhas, monitoramento de ponta a ponta, roteamento dinâmico que podem ser difíceis de lidar no nível do serviço.

Para isso apresentamos o Kiali (kiali.org) que conjuntamente com o Istio, Jaeger, Prometheus, possui uma solução para visualizar a topologia dos seus serviços (service mesh), taxa de requisição, latência, distribuição de carga, tracing distribuidos e entre outras funcionalidades que não requerem modifcação do código da aplicação