Mulesoft Meetup Latam Summit Brazil

7 Outubro, 2020
LATAM Summit
Garantia na Entrega de Mensagens
e Disponibilidade 5 Noves

3
● Introdução - Speaker
● Alta disponibilidade - High availability;
● Escalonamento Vertical vs. Horizontal;
● Diferenças da “Object Store” em diferentes Topologias;
● Garantindo a Entrega de Mensagens - Zero Message Loss;
● Disjuntores - Circuit Breakers;
● Networking time;
Agenda

Brasileiro atualmente com residência em Orangeville, ON, Canadá com mais de
20 anos de experiência em design e implementação de Sistemas de Integração
entre América do Norte, Latina, Europa, Oriente Médio & África do Norte (MENA)
e Ásia.
Arquiteto de Integração na construção do primeiro Campus hospitalar da
Cleveland Clinic fora dos Estados Unidos da América (Abu Dhabi) com suporte a
364 leitos de internação e operação 24x7x365.
Mestre em Ciências da Informação e Tecnologia pela Universidade de Liverpool -
Reino Unido, Certified Mulesoft Integration/Platform Architect & Developer, Six
Sigma Green & Black Belt e Certificado em várias Plataformas Enterprise como
Salesforce, AWS, Hyland OnBase e Epic EMR.
Thiago Santos
https://linkedin.com/in/thiagonsantos/

Five Nines Availability
Disponibilidade 9,9999%

6
● Tempo de inatividade por ano
○ 5,26 minutos
●Tempo de inatividade por mês
○ 26.30 segundos
●Tempo de inatividade por semana
○ 6.05 segundos
●Tempo de inatividade por dia
○ 864.00 milissegundos
Disponibilidade 99,999% “5 noves”

7
● Telecom
○ Sistemas de PABX;
○ Streaming (Video Calls);
● Militar - Military
○ Comunicações Seguras (E-mail, SMS);
○ Monitoramento de Redes (Heartbeats);
● Saúde - Healthcare
○ Monitores Vitais;
■ Check de bateria para Marcapassos (Pacemakers);
■ Monitores Cardiacos e etc;
○ EMR - Prontuário Médico Eletrônico;
■ Pedido de Medicamentos e Exames;
Alguns Segmentos que exigem “5 noves”

8
● Requerimentos Mínimos para garantia “5 noves”:
○ Dedicated Load Balancer;
○ DDos/Dos Policies;
○ Heartbeats;
○ Múltipla Instâncias por Aplicação Mule em regiões diferentes;
○ Ao menos 2 workers por instância (região);
○ Solução Assíncrona:
■ Pub/Sub, Queuing, Request/Reply (Advanced Event Broker);
● AnypointMQ, Solace, ActiveMQ, RabbitMQ;
○ Solução Síncrona:
■ Multi-site In-Memory Data Store (AWS Redis), **Object Store;
● Itens adicionais para agilidade e segurança:
○ Suporte para Transacoes (XA Transactions) - JMS, Database, Salesforce (allornone);
○ Auto-Scaling Enabled (Requer Enterprise Licensing Agreement);
○ CI/CD (Continuous Integration / Continuous Delivery);
Topologia Nuvem (Cloud-Based)
*Workers são distribuídos randomicamente
entre “Availability Zones” na região
selecionada.
**Falaremos adiante...

9
Topologia Customer-Hosted
Somente Assinaturas Platinum & Titanium
Benefícios Mule Classic Anypoint Runtime Fabric
Confiabilidade no isolamento de
Aplicações
Manual ✓
Escalonamento Horizontal Manual ✓
Registro de Aplicações (OOTB) Mule &
APIs com Mulesoft-Managed Control
Plane
Manual
(Registro de cada Runtime)
✓ (Conectado ao Control Plane)
Zero-Downtime durante re-
deployments
Manual
(Dedicated Load Balancer Switch)
✓ (Rolling Updates)
Suporte nas Plataformas Azure, AWS,
VM, GCP e Servidores Físicos
✓ ✓
Suporte de Containers (Imagens) com
Mulesoft Runtime × ✓
● Requerimentos Mínimos para garantia “5 noves”:
○ Dedicated Load Balancer;

Vertical vs. Horizontal Scaling
Escalonamento Vertical vs. Horizontal

11
Escalonamento Vertical vs. Horizontal
● Escalonamento Vertical (Vertical Scaling)
○ Adicionar mais recursos no mesmo sistema, runtime ou aplicação;
■ Mais eficiente e irredundante;
■ Mais pesado = mais lento;
● Escalonamento Horizontal (Horizontal Scaling)
○ Adicionar mais máquinas ou servidores como parte da mesma coleção de recursos;
■ Serviço redundante;
■ Mais leve = mais rápido;
}50 passageiros
}25 passageiros }25 passageiros+

Object Stores Topology Variations
Diferenças da “Object Store” em diferentes Topologias

13
Cloudhub Object Stores
● Object Stores não devem ser consideradas uma opção universal para Armazenamento:
○ Não a usem como um banco de dados;
○ Exigem cuidados para o armazenamento de informações sensíveis (incluindo tokens
de acesso e dados pessoais);
○ Uso deve ser analisado caso-a-caso;
● Uso comum:
○ Armazenamento de ids para sincronismo de informações (watermark);
● Tipos:
○ Transient: Salvo na Memória (Alta Performance, sem persistência);
○ Persistent: Salvo em Disco (I.O Performance, persistente);

14
Cloudhub Object Stores (Cloud-Based)
Versão Free Premium Limite Retenção Key Size Value Size Transient (In-
Memory)
Persistent
(On-Disk)
v2
(Mule 3x e 4x)
10
transações por
segundo
(por aplicação);
FIPS 140-2 row
level encryption
100
transações por
segundo
(por aplicação);
FIPS 140-2 row level
encryption
100 milhões de
transações (entre
todos ambientes)
30 Dias 256 characteres 10 mb
×
Acessível entre
todos os
Workers da
mesma
aplicação.
Dados
sobrevivem em
caso de “re-
deployment”
(Uso da
plataforma
AWS Redis).
v1*
(Mule 3x)
Disponivel somente US-EAST
(*Considerar Network Latency
- Brasil) Region e para todos
os usuários Cloudhub.
Sem limites de transações por
segundo.
No API Rate
limit.
N/A 768 byte key size
100,000 keys por
aplicação
1 mb per value
(1gb por aplicação)
“_defaultUserObjectStore”
Dados
sobrevivem em
caso de “re-
deployment.
(Externo)
Dados não
sobrevivem em
caso de “re-
deployment”.
(Arquivo Local)
● *Object Store v1 é um serviço descontinuado (Cloudhub). Usem v2 para novos projetos.
○ Database Encryption;
○ Suporte para Object Store V1 não disponível para Mule Runtime 4.x;
● Redis pode ser utilizado como uma “custom” Object Store in Mule 4
(https://help.mulesoft.com/s/article/How-To-Use-Redis-As-Custom-Object-Store-Reference-In-Mule-4)
×

15
Mule Object Store (On-Premises)
Topology Limites Key Size Value Size Transient (In-
Memory)
Persistent
(On-Disk)
Mule
Standalone
(Mule 3x e 4x)
N/A N/A N/A Disponível
em domain
applications
e clusters;
Acessível entre todos
os Workers da
mesma aplicação.
Dados sobrevivem
em caso de “re-
deployment” (Salvo
em Arquivo Local -
Disco).
Runtime
Fabric
(Mule 3x e 4x)
N/A N/A N/A Disponível em
“clustering
mode” entre
réplicas (shared-
memory).
×
On-Premises Object Store, parte do Mule Runtime.

Zero Message Loss with Reliable Patterns
Garantindo a Entrega de Mensagens
● Customizável;

Padrões na Garantia de Entrega
Flow Endpoint Vantagens Desvantagens
VM (Virtual Machines)
Transient (Mule Standalone)
● Mais rápida que JMS por ser um
processo/mensagem salvo em
memória;
● Funcionalidade OOTB;
● Dados são perdidos em caso de
redeployment ou falha da
aplicação;
● Non-clustered;
● Suporte somente “In-Mule App”;
Transient VM (Mule HA Cluster)
● Dados são perdidos em caso de
redeployment ou falha da
aplicação;
● Suporte somente “In-Mule App”;
Persistent VM (Mule Standalone)
● IO Performance (Disco);
● Funcionalidade OOTB;
● Non-Clustered;
JDBC (Java Database Connectivity) ● Dependendo dos recursos JDBC
pode acumular uma imensa
quantidade de informações
● Requer DBMS Schemas;
JMS (Java Message Service)
Topologia não Persistente
● Suporte para aplicações Mule e
Não Mule;
● Customizável;
● Mais devagar que VM por ser
parte de outro processo;
JMS (Java Message Service)
Topologia Persistente
● Forma mais confiável pelo motivo
das mensagens serem
persistentes em disco;
● Customizável;
● Mais devagar que VM por IO
Performance (nem sempre);

18
Use Case - Entrega de Medicamento
Enfermeiro(a)
Farmácia
Convênio
Médico(a)
Paciente
Adicionar a
Conta do Paciente
Cobertura
Aprovada?

19
Requisição Síncrona (Synchronous)
Farmácia
Experience API
Médico(a)
Pagamento
Process API
Entrega de Medicamento
(Enfermagem)
Process API
Convênio A
System API
Convênio B
System API
Vocera (Voz)
System API
Pager (Texto)
System API
Financeiro
System API
Enfermeiro(a)
ServiceNow
System API
IT Ops
Process API
×

Pros x Cons - Req. Síncrona
● Prós
○ Integração quase real-time;
● Contras
○ Perda de Mensagens em caso de falha/erros (não persistente);
■ Implementação Complexa de Circuit Breakers;
○ Grande dependência em caching;
○ Monitoramento Continuo;
■ Complexidade na definição de RCAs (Root Cause Analysis);

21
Requisição Assíncrona (Asynchronous)
Farmácia
Experience API
Pagamento
Process API
Médico(a)
Entrega de Medicamento (Enfermagem)
Process API
Convênio A
System API
Convênio B
System API
Vocera (Voz)
System API
Pager (Texto)
System API
Financeiro
System API
Enfermeiro(a)
ServiceNow
System API
IT Ops
Process API
Pub/Sub (Exchange/Topic)
Pagamento Queue Pagamento Retry Queue Pagamento DLQ Medicamento DLQ Medicamento
Queue
Medicamento Retry Queue

Pros x Cons - Req. Assíncrona
● Prós
○ Integração quase real-time (send & forget);
○ Mensagens são confiáveis, perda 0;
○ Fácil Implementação de Circuit Breakers;
● Contras
○ Topologia um pouco mais complexa;

Circuit Breakers Pattern
Padrões de “Circuit Breakers” (Disjuntores)

24
Estados de um Circuit Breaker
Início
Start
Meio Aberto
Half Open
● Tentativa de processamento de
mensagem única.
# Erros >= Limite de Erros
Fechado
Closed
● Processamento normal das
mensagens baseado na
estratégia do subscriber.
Aberto
Open
● Nenhuma mensagem é
processada a partir deste
momento.
Intervalo tripTimeout
Falha no processamento de
mensagem única.

25
Implementando “Circuit Breakers”
Farmácia
Experience API
Pagamento
Process API
Médico(a)
Entrega de Medicamento (Enfermagem)
Process API
Convênio A
System API
Convênio B
System API
Vocera (Voz)
System API
Pager (Texto)
System API
Financeiro
System API
Enfermeiro(a)
ServiceNow
System API
IT Ops
Process API
Pub/Sub (Exchange/Topic)
Pagamento Queue Pagamento Retry Queue Pagamento DLQ Medicamento DLQ Medicamento
Queue
Medicamento Retry Queue
×

26
● AnypointMQ (OOTB)
○ Funcionalidade Out-Of-The-Box (Subscriber Source / Mule 4);
■ Por exemplo, pode ser usado para gerenciar downtime em serviços externos;
● Falha em requests e/ou error responses;
○ Suporte a múltiplos Circuit-Breakers e instâncias Globais;
○ Fácil Implementação;
●Groovy Script (Custom)
○ Para iniciar flows Mule você irá precisar instanciar o registro e procurar o flow por nome:
Exemplos de Circuit Breakers

27
● Share:
○ Tweet using the hashtag #MuleSoftMeetups
● Feedback:
○ Fill out the survey feedback and suggest topics for upcoming events
○ Contact MuleSoft at meetups@mulesoft.com for ways to improve the program
What’s next?

Vamos nos conhecer!
Hora do Networking

7 Outubro, 2020
LATAM Summit
Community Manager, desenvolvedores são os
novos clientes

31
● Comunidades
● API Community Manager
● Demo Community
● Networking time
Agenda

Lead Solution Engineer - Latin America, trabalho na Mulesoft unidade Brasil, sou pai de uma
linda mocinha, apaixonado por tecnologia e esportes, principalmente corridas.
Propósito: "Contribuir para a vida das pessoas por intermédio do esporte e tecnologia"
Graduado em Sistema de Informação pelo Centro universitário Newton Paiva - MG, duas
especializações (MBA), Gestão de Pessoas e Liderança estratégica pela Newton Paiva - MG e
Arquitetura de Soluções pela FIAP / SP.
Trabalho com Arquiteturas de Integração desde 2007, atuando com plataformas (IPaaS,
Middleware e API Gateway).
Tenho uma paixão muito grande por contribuir com comunidades e projetos Open Source.
● Organizer CNCF BH
● Organizer Api and Cloud Adoption (whatsapp)
Marcelo Umberto

Desenvolvedores são os novos
clientes

Desenvolvedores são os novos clientes
Forums
Support
Docs
APIs
Case
Studies
Tutorials
Events
User
Groups

36
"Comunidades são grupos de indivíduos que compartilham
experiências entre si.
Geralmente convivem sob o mesmo conjunto de normas, num
mesmo ambiente, sob uma liderança ou organizado por líderes
que trabalham para manter ou fortalecer a identidade do grupo
como uma unidade."
"O principal foco de uma comunidade é manter o engajamento
ativo de seus membros"
Comunidades

37
Comunidades
Engajamento
Moderação
Forums Desafios
Contéudo

API Community Manager
39
Experiência do desenvolvedor para construir e aumentar seu ecossistemas de API
Espor APIs como produtos
Crie portais com cliques ou código usando modelos
e componentes Lightning
Impulsionar a adoção da API
Ofereça suporte aos usuários em cada etapa com
documentos, fóruns e gerenciamento de casos
interativos
Gerenciar ecossistemas de API
Avalie o envolvimento e acompanhe o desempenho
dos investimentos em API

API Community Manager
Capacidades Equipes coordenadas
• Gerenciamento de API de ciclo de vida
completo
• Sistema de gerenciamento de
conteúdo
• Personalização
• Fóruns
• Bate-papo
• Gerenciamento de casos de suporte
• Análise de engajamento
• TI central
• Gerentes de produto API
• Marketing de conteúdo / marca
• Relações com o desenvolvedor
• Escritores técnicos
• Profissionais de suporte
• Desenvolvimento de negócios

Capacidades
Out-of-the-box themes Drag-and-drop builder Personalized portals
Interactive docs Forums & Cases Engagement Analytics

7 Outubro, 2020
LATAM Summit
Segurança de APIs e automação

47
● Proteção de APIs
● Como funciona aplicação de políticas com API Gateway
● Automatizando políticas de segurança
● Demo
● Networking time
Agenda

Apaixonado pela minha linda família e pai do pequeno Benício de 7 meses!!!!
Trabalho com desenvolvimento de software e integrações de sistemas desde
2008
Líder da prática de MuleSoft na Harpia Cloud.
Desde 2014 trabalhando com MuleSoft
Certificado Mulesoft Integration/Platform Architect & Developer
Lider do grupo de Meetups de São Paulo desde 2019
Guilherme Pereira

49
● Grupo da comunidade para a comunidade
● Local aberto para discussões sobre o mundo de APIs e MuleSoft
● Seja um palestrante
● Compartilhe seu conhecimento
● Ganhe um voucher para treinamento e certificação
https://meetups.mulesoft.com/sao-paulo/
Faça parte da comunidade

Como proteger suas APIs
Segurança de APIs

52
● Segurança & conformidade
○ Controle de segurança
○ Controle dos recursos acessados
○ Identificação do acesso
○ Informações sensíveis
● Qualidade do serviço
○ Delimitar limites de requisições
○ Definir SLA’s
○ Garantir que sua infraestrutura não seja afetada
○ Mau uso / Ataque
○ Uso massivo
Segurança de APIs

Modelos de gerenciamento
API Proxy vs Mule API

54
Proxy
Anypoint Management Center
API Manager
Mule Runtime
API Java, .Net,
etc Backend
API Proxy

55
Mule API
API Manager
Mule Runtime
Backend
API

Como as políticas são aplicadas
Como funciona?

57
Aplicando políticas
API ManagerTime
segurança
Mule Runtime
Mutual TLS
1.2
Aplica política
Download
política
Metadados
analíticos

58
Aplicando políticas
● Para cada nova API publica é
necessário aplicar sua política
de segurança
● Processo de segurança pode
falhar e uma API ser publicada
sem uma política aplicada
● Gerenciamento pode ser
custoso e onerar muito o time

Facilitando a gestão e governança
Automatizando políticas

● Por que utilizar ?
○ Uma política pode ser aplicada para todas as APIs de um determinado ambiente
○ Gestão de segurança é facilitada
○ Consistência e redução de erros no processo
○ Novas APIs já são publicas seguindo as determinações de segurança
● Exemplos de utilização:
○ Definir política onde todos os consumidores devem se registrar em uma API
○ Definir uma política com requerimentos de logging unificada
○ Aplicar política customizada para todas as APIs

● Características
○ Políticas automatizadas são aplicadas para todas as APIs de um ambiente
○ Políticas automatizadas sobrescrevem as políticas aplicadas em uma API
○ Se uma política já estiver aplicada em uma API o conflito deverá ser resolvido
○ Você pode aplicar qualquer política seja ela padrão ou customizada
○ É possível automatizar políticas para determinadas versões de Runtime
○ Ex: Aplicar somente para runtimes versão 4.2.X

65
● Share:
○ Tweet using the hashtag #MuleSoftMeetups
○ Invite your network to join: https://meetups.mulesoft.com/
● Feedback:
○ Fill out the survey feedback and suggest topics for upcoming events
○ Contact MuleSoft at meetups@mulesoft.com for ways to improve the program
What’s next?

Mulesoft Meetup Latam Summit Brazil

Mais conteúdo relacionado

Mais procurados

Semelhante a Mulesoft Meetup Latam Summit Brazil

Mais de Guilherme Pereira Silva

Mulesoft Meetup Latam Summit Brazil