1. 7 Outubro, 2020
LATAM Summit
Garantia na Entrega de Mensagens
e Disponibilidade 5 Noves
2. 7 Outubro, 2020
LATAM Summit
Garantia na Entrega de Mensagens
e Disponibilidade 5 Noves
3. 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
4. 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/
6. 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. 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. 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. 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;
11. 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+
13. 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. 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. 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.
16. Zero Message Loss with Reliable Patterns
Garantindo a Entrega de Mensagens
● Customizável;
17. 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”;
VM (Virtual Machines)
Transient VM (Mule HA Cluster)
● Dados são perdidos em caso de
redeployment ou falha da
aplicação;
● Suporte somente “In-Mule App”;
VM (Virtual Machines)
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. 18
Use Case - Entrega de Medicamento
Enfermeiro(a)
Farmácia
Convênio
Médico(a)
Paciente
Adicionar a
Conta do Paciente
Cobertura
Aprovada?
19. 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
×
20. 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. 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
22. 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;
24. 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. 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. 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. 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?
30. 7 Outubro, 2020
LATAM Summit
Community Manager, desenvolvedores são os
novos clientes
31. 31
● Introdução - Speaker
● Comunidades
● API Community Manager
● Demo Community
● Networking time
Agenda
32. 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
36. 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
39. 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
40. 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
47. 47
● Introdução - Speaker
● Proteção de APIs
● Como funciona aplicação de políticas com API Gateway
● Automatizando políticas de segurança
● Demo
● Networking time
Agenda
48. 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. 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
52. 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
58. 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
60. 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
61. Automatizando políticas
● 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. 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?