Conteúdo apresentado no Meetup do grupo AWS Campinas, em 08/07/2017. Foi feita uma apresentação sobre os conceitos de microserviços, como a AWS pode ajudar e no final uma técnica de como refatorar um sistema monolítico para microserviços.
Amadurecendo Equipes com Microservicessanchez_ivan
Uma arquitetura de microserviços trás inúmeras vantagens. Por outro lado, organizar um sistema deste modo traz vários desafios. Nesta apresentação eu trago algumas lições aprendidas que podem ser úteis mesmo para equipes que não pretendem aderir completamente a esta nova tendência.
Microservices é um conceito que está na cabeça de todo mundo da tecnologia neste momento. Existem várias outras teorias e patterns que estão ajudando a fazer dos microservices uma estratégia de sucesso para o desenvolvimento de aplicações de média e larga escala. Vamos entrar fundo em alguns conceitos e ver como eles podem ajudar na hora de produzir uma arquitetura robusta de microservices.
Vantagens e desvantagens de uma arquitetura microservicesFábio Rosato
A demanda cada vez maior por agilidade, inovação e escalabilidade das soluções digitais tem impulsionado a adoção da arquitetura baseada em microservices. Os benefícios desta abordagem são reais e significativos, mas esse estilo arquitetural traz uma série de novos desafios.
Nesta apresentação, vamos fazer um mergulho profundo a partir de exemplos detalhados sobre as vantagens e desvantagens dessa abordagem arquitetural, como por exemplo:
Explorar como realizar a decomposição funcional e como definir taxonomias e granularidades adequadas para os microservices;
Como solucionar problemas arquiteturais como Client-side service discovery e Server-side service discovery, invocação, logging e monitoramento;
Definir protocolos de comunicação (HTTP, AMQP e Websocket) de forma minimizar a latência e lidar com outros requisitos não funcionais;
Como atacar questões de replicação de dados e regras de negócio e dados;
Design Patterns para problemas arquiteturais recorrentes;
Como conduzir a operação e evolução de um sistema nesta abordagem.
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Dirceu Resende
O que é o Power Embedded?
Uma aplicação web que permite reduzir o custo do Power BI em até 90%
➢ Usuários que precisam apenas visualizar relatórios acessam o Power Embedded
ao invés do portal do Power BI, e por isso, não precisam de licença PRO
Usuários que criam relatórios continuam acessando powerbi.com para configurar
atualizações, gateways e tudo mais.
➢ Permissões de acesso aos relatórios e RLS são configurados no Power Embedded
e não mais no portal do Power BI
Investimento necessário
Pagamento único
➢ Setup inicial e instalação: R$ 1.500,00 – Power Tuning
Mensal
➢ Sistema: R$ 5,00 (por usuário) – Power Tuning
➢ Capacidade Embedded ou Fabric: A partir de R$ 500,00* – Microsoft
O que são essas capacidades?
São recursos do Power BI que licenciam a solução do Power Embedded junto à
Microsoft e permitem utilizar as API’s, de forma legal e ilimitada, a inserir relatórios
publicados em aplicações terceiras e não precisar de licença para visualizar os relatórios
Tipos de capacidades (todas são suportadas pelo Power Embedded):
➢ Fabric: Mais nova, flexível, mais recursos e pode começar mais barata.
➢ Power BI Embedded: Mais estável, confiável e pode ser mais barata no pago pelo uso.
➢ Premium por Capacidade: A mais completa, mas o custo inicial é 32 mil reais por mês.
• As capacidades são contradas direto com a Microsoft (ou parceiro) pelo Azure.
• Ter uma capacidade é um requisito para o Power Embedded funcionar.
• Microsoft libera um período de avaliação gratuito de 60 dias para o Fabric.
Por quê preciso do Power Embedded?
Apenas contratando a capacidade, você ainda precisará de licenças PRO para
visualizar os relatórios.
➢ O Power Embedded que cria essa comunicação com as API’s do Power BI e permite
visualizar os relatórios pelo Sistema, sem precisar de licença.
➢ Também é o Power Embedded que implementa o controles de segurança (RLS e
OLS) e garante que apenas os usuários com permissão podem visualizar o relatório.
➢ Se você não quiser gastar centenas de horas de programação para criar o seu portal e
todos os controles de segurança, você precisa do Power Embedded. ☺
Amadurecendo Equipes com Microservicessanchez_ivan
Uma arquitetura de microserviços trás inúmeras vantagens. Por outro lado, organizar um sistema deste modo traz vários desafios. Nesta apresentação eu trago algumas lições aprendidas que podem ser úteis mesmo para equipes que não pretendem aderir completamente a esta nova tendência.
Microservices é um conceito que está na cabeça de todo mundo da tecnologia neste momento. Existem várias outras teorias e patterns que estão ajudando a fazer dos microservices uma estratégia de sucesso para o desenvolvimento de aplicações de média e larga escala. Vamos entrar fundo em alguns conceitos e ver como eles podem ajudar na hora de produzir uma arquitetura robusta de microservices.
Vantagens e desvantagens de uma arquitetura microservicesFábio Rosato
A demanda cada vez maior por agilidade, inovação e escalabilidade das soluções digitais tem impulsionado a adoção da arquitetura baseada em microservices. Os benefícios desta abordagem são reais e significativos, mas esse estilo arquitetural traz uma série de novos desafios.
Nesta apresentação, vamos fazer um mergulho profundo a partir de exemplos detalhados sobre as vantagens e desvantagens dessa abordagem arquitetural, como por exemplo:
Explorar como realizar a decomposição funcional e como definir taxonomias e granularidades adequadas para os microservices;
Como solucionar problemas arquiteturais como Client-side service discovery e Server-side service discovery, invocação, logging e monitoramento;
Definir protocolos de comunicação (HTTP, AMQP e Websocket) de forma minimizar a latência e lidar com outros requisitos não funcionais;
Como atacar questões de replicação de dados e regras de negócio e dados;
Design Patterns para problemas arquiteturais recorrentes;
Como conduzir a operação e evolução de um sistema nesta abordagem.
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Dirceu Resende
O que é o Power Embedded?
Uma aplicação web que permite reduzir o custo do Power BI em até 90%
➢ Usuários que precisam apenas visualizar relatórios acessam o Power Embedded
ao invés do portal do Power BI, e por isso, não precisam de licença PRO
Usuários que criam relatórios continuam acessando powerbi.com para configurar
atualizações, gateways e tudo mais.
➢ Permissões de acesso aos relatórios e RLS são configurados no Power Embedded
e não mais no portal do Power BI
Investimento necessário
Pagamento único
➢ Setup inicial e instalação: R$ 1.500,00 – Power Tuning
Mensal
➢ Sistema: R$ 5,00 (por usuário) – Power Tuning
➢ Capacidade Embedded ou Fabric: A partir de R$ 500,00* – Microsoft
O que são essas capacidades?
São recursos do Power BI que licenciam a solução do Power Embedded junto à
Microsoft e permitem utilizar as API’s, de forma legal e ilimitada, a inserir relatórios
publicados em aplicações terceiras e não precisar de licença para visualizar os relatórios
Tipos de capacidades (todas são suportadas pelo Power Embedded):
➢ Fabric: Mais nova, flexível, mais recursos e pode começar mais barata.
➢ Power BI Embedded: Mais estável, confiável e pode ser mais barata no pago pelo uso.
➢ Premium por Capacidade: A mais completa, mas o custo inicial é 32 mil reais por mês.
• As capacidades são contradas direto com a Microsoft (ou parceiro) pelo Azure.
• Ter uma capacidade é um requisito para o Power Embedded funcionar.
• Microsoft libera um período de avaliação gratuito de 60 dias para o Fabric.
Por quê preciso do Power Embedded?
Apenas contratando a capacidade, você ainda precisará de licenças PRO para
visualizar os relatórios.
➢ O Power Embedded que cria essa comunicação com as API’s do Power BI e permite
visualizar os relatórios pelo Sistema, sem precisar de licença.
➢ Também é o Power Embedded que implementa o controles de segurança (RLS e
OLS) e garante que apenas os usuários com permissão podem visualizar o relatório.
➢ Se você não quiser gastar centenas de horas de programação para criar o seu portal e
todos os controles de segurança, você precisa do Power Embedded. ☺
Como DDD e Strategic Design estão nos ajudando a modernizar um LegadoLuiz Costa
O objetivo desta palestra é mostrar como é possível evoluir e reescrever partes de uma aplicação legada com mais 5 anos em produção utilizando técnicas de uma parte Domain Driven Design conhecida como Strategic Design. É uma aplicação web escrita em Python e Django que suporta a operação de um grupo focado em medicina do trabalho, com clínicas espalhadas pelo país.
Nesta palestra vamos mostrar uma abordagem que pode ajudar times que precisam lidar com aplicações legadas grandes e complexas no caminho da modernização.
Microservices - Canal .NET Dev WeekendRenato Groff
Tópicos abordados nesta apresentação realizada durante o Canal .NET Dev Weekend, evento online realizado em 05/12/2015:
- Aplicações Monolíticas
- Serviços: uma visão geral
- Arquitetura de Microservices
Microserviços - Universidade Metodista - EETI 2016Renato Groff
Tópicos abordados nesta apresentação realizada durante o a semana EETI 2016 da Universidade Metodista - São Paulo (02/05/2016):
- Aplicações Monolíticas
- Serviços: uma visão geral
- Arquitetura de Microserviços
Primeira aula da disciplina Programação Dinâmica para Web. Primeiros conceitos sobre Arquitetura de Aplicações web e informações gerais sobre a disciplina.
Tópicos abordados nesta apresentação realizada durante o Interopmix (24/08/2015):
- Aplicações Monolíticas
- Serviços: uma visão geral
- Arquitetura de Microservices
Tópicos abordados nesta apresentação realizada durante o ALM Roadshow 2015 - São Paulo (07/11/2015):
- Aplicações Monolíticas
- Serviços: uma visão geral
- Arquitetura de Microservices
How to break a Monolith into Microservices - Quebrar o um monolito pode não ser uma tarefa fácil, mas existe bastante conteúdo que vai nos ajudar com essa tarefa. Decompor uma aplicação existente monolítica, requer pensar em uma estratégia de desacoplamento, migração de dados, convivência entre sistemas e tecnologias. Conteúdo elabora junto com Marlon Moncores.
Como DDD e Strategic Design estão nos ajudando a modernizar um LegadoLuiz Costa
O objetivo desta palestra é mostrar como é possível evoluir e reescrever partes de uma aplicação legada com mais 5 anos em produção utilizando técnicas de uma parte Domain Driven Design conhecida como Strategic Design. É uma aplicação web escrita em Python e Django que suporta a operação de um grupo focado em medicina do trabalho, com clínicas espalhadas pelo país.
Nesta palestra vamos mostrar uma abordagem que pode ajudar times que precisam lidar com aplicações legadas grandes e complexas no caminho da modernização.
Microservices - Canal .NET Dev WeekendRenato Groff
Tópicos abordados nesta apresentação realizada durante o Canal .NET Dev Weekend, evento online realizado em 05/12/2015:
- Aplicações Monolíticas
- Serviços: uma visão geral
- Arquitetura de Microservices
Microserviços - Universidade Metodista - EETI 2016Renato Groff
Tópicos abordados nesta apresentação realizada durante o a semana EETI 2016 da Universidade Metodista - São Paulo (02/05/2016):
- Aplicações Monolíticas
- Serviços: uma visão geral
- Arquitetura de Microserviços
Primeira aula da disciplina Programação Dinâmica para Web. Primeiros conceitos sobre Arquitetura de Aplicações web e informações gerais sobre a disciplina.
Tópicos abordados nesta apresentação realizada durante o Interopmix (24/08/2015):
- Aplicações Monolíticas
- Serviços: uma visão geral
- Arquitetura de Microservices
Tópicos abordados nesta apresentação realizada durante o ALM Roadshow 2015 - São Paulo (07/11/2015):
- Aplicações Monolíticas
- Serviços: uma visão geral
- Arquitetura de Microservices
How to break a Monolith into Microservices - Quebrar o um monolito pode não ser uma tarefa fácil, mas existe bastante conteúdo que vai nos ajudar com essa tarefa. Decompor uma aplicação existente monolítica, requer pensar em uma estratégia de desacoplamento, migração de dados, convivência entre sistemas e tecnologias. Conteúdo elabora junto com Marlon Moncores.
6. Abordagem Monolítica
Sistema
Banco de dados
Controle
Usuários
Contas a
Pagar
Contas a
Receber
Emissão e
Guarda da NFe
Cadastro
Produtos
Cadastro
Fornecedores
Relatórios
Envio de
e-mail
7. Abordagem Monolítica
Prós
• Performático
• Fácil gerenciar
Contras
• Preso a uma tecnologia
• Alta curva de
aprendizado
• Pouco reaproveitamento
• Muitos programadores
“batem cabeça”
• Falha em um
componente
compromete o todo
• Dificuldades em escalar
tudo: aplicação, equipe,
base de dados, etc.
• Difícil escalar.
8. Por que não fatiar o grande
sistema em sistemas
menores?
12. Tamanho
Tempo para ser reescrito: duas semanas.
(Jon Eaves / RealEstate.com.au – Australia)
Equipes grandes o
suficiente para serem
alimentadas por duas pizzas
grandes.
13. Pontos importantes
• Serviços autônomos que trabalham juntos.
• Princípio da responsabilidade única.
• Comunicação através de chamadas de rede, para
evitar forte acoplamento.
• Mudar um serviço e deployar sem mudar mais nada.
• KISS – keep it short and simple.
• DRY – Don’t repeat yourself não é um problema
14. Benefícios
• Agnóstico à tecnologia (heterogeneidade).
• Resiliência - Problema não falha em cascada –
isolamento.
• Escalabilidade – não precisa escalar tudo.
• Facilidade de deploy (monolito é tudo), risco reduzido.
• Gestão dos times.
• Reaproveitamento / Diferentes composições.
• Fácil substituição.
• Usar outros datacenteres.
15. Deve-se definir padrões
• Monitoramento.
• Tipo de interface (HTTP/REST).
• Padrões de arquitetura (response codes 4xx, 5xx).
• Segurança.
19. API Gateway
• Facilita o gerenciamento do ciclo de vida das APIs.
• Pode ser usado com endpoint Lambda.
• Monitoramento via CloudWatch.
• Autorização AWS.
• Permite definir controles de threshold.
• Permite criar uma camada de cache integrada
(cache de até 1 hora).
• Permite realizar modificações nas requisições e
respostas.
Amazon API
Gateway*
20. Acoplamento
Sistema Monolítico
Controle
Usuários
Contas a
Pagar
Contas a
Receber
Emissão e
Guarda da NFe
Cadastro
Produtos
Cadastro
Fornecedores
Relatórios
Envio de
e-mail
Emissão e
Guarda da NFe
Envio de
e-mail
Contas a
Receber
Forma como os diferentes componentes do sistema interagem.
21. Acoplamento
• Quanto mais forte o acoplamento, pior.
• Se um componente falha, o processo quebra.
• Módulos do sistema (ou Microserviços) devem
conversar entre si através da troca de mensagens.
• Desacoplamento favorece autonomia e
escalabilidade.
22. Filas
• Formas seguras de informar outro componente de
que algo aconteceu e/ou precisa ser feito.
• Comunicação “assíncrona”.
• Cada fila pode ter um ou muitos “usuários”,
favorecendo o paralelismo da aplicação.
• Reduz falhas do tipo “curto-circuito”.
• Permite “cadenciar” a execução.
23. Filas – exemplo 1
1. Sistema emite a NFe
2. Sistema grava um item na fila de envio de e-mails
3. Sistema gera o contas a receber
Worker fica lendo a fila de envio de e-mails para
realizar os disparos sempre que algum item for
lançado lá.
Emissão e
Guarda da NFe
Envio de
e-mail
Contas a
Receber
Worker
24. SQS
• Pode ser FIFO ou randômica (best-effort).
• Garantia de entrega.
• Permite definir tempo de “invisibilidade” da
mensagem.
• Até 256 Kb de texto por mensagem.
• Mensagens podem ser enviadas e lidas
simultaneamente.
Amazon
SQS
25. Notificações
• Notificar um ou mais componentes de que algo
aconteceu.
• Comunicação “assíncrona”.
• Modelo publicação / assinatura.
• Pode ser usado para notificar dispositivos móveis.
26. Notificações - Exemplo
1. Sistema emite a NFe
2. Sistema emite a notificação “NFe emitida”
3. Assinantes da notificação são informados
Emissão e
Guarda da NFe
Envio de
e-mail
Contas a
Receber
Autor principal (Emissão da NFe) não precisa
saber quem são os assinantes da notificação.
27. SNS
• Tipos de assinatura: Push móvel (dispositivos
Apple, Google e Kindle Fire), HTTP/HTTPS, E-mail/E-
mail-JSON, SMS, SQS, funções do AWS Lambda.
28. Custos vs. Tipo de Instâncias
Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez
Consumo
Reserved
On
Demand
Spot
29. Coesão
• Os módulos/componentes do sistema devem ser
coerentes com o seu propósito.
• Um módulo não deve realizar papéis que deveriam
ser exclusivos de outros módulos: ações, consultas,
etc. deve-se solicitar o dado ou ação ao outro
módulo.
• Se aplica também à camada de persistência de
dados (banco de dados).
30. Coesão - Exemplo
• Listagem de fornecedores: quem o cadastrou?
Sistema Monolítico
Banco de dados Monolítico
Controle
Usuários
Contas a
Pagar
Contas a
Receber
Emissão e
Guarda da NFe
Cadastro
Produtos
Cadastro
Fornecedores
Relatórios
Envio de
e-mail
31. Segurança
• Uso o API Gateway para autenticar e os
microserviços para autorizar.
• Não exponha todos os microserviços na web.
• Use um API gateway interno e um externo.
• Use APIs de composição para acessar APIs internas.
• Controle o threshold das requisições.
32. Monitoramento
• Use o CloudWatch para monitorar as falhas.
• Importante monitorar o tempo de resposta.
33. Versionamento
• MAJOR.MINOR.PATCH
Major Mudanças significativas que podem
quebrar a aplicação.
Minor Mudanças que não quebram a aplicação,
normalmente são melhorias.
Patch Correções.
36. Do monolito para microserviços
1. Construa uma estrutura básica: Autenticação, API
Gateway, ferramentas de apoio (logs, etc.),
automação e padrões de API.
2. Unificar mecanismos de autenticação: faça o velho
usar o novo.
3. Identifique os componentes do sistema (aplicação e
banco de dados).
4. Crie os novos microserviços e faça os componentes
antigos do monolito usarem eles
5. Repita o item 4 até o monolito deixar de existir,
restando apenas a interface do usuário.
Strangler
39. Resumo
• Aplicações distribuídas facilitam escalabilidade e
são mais robustas, porém possui maior
complexidade.
• Arquitetura é fator chave de sucesso.
• Ferramentas na AWS:
• API Gateway
• Cloudwatch
• SNS
• SQS
• IAM
• EC2 / ELB
Por que a nuvem facilitou as coisas e viabilizou muitas outras pela redução da complexidade.
Custos
Complexidade
Coisas Prontas
Diferenças Azure / Google Cloud / AWS
Problemas para os vendors de hardware
Facilidade de gerenciamento/orquestração e capacidade computacional favorecem estruturas mais complexas
O que nos impede de transformar um sistema em vários?
Usar várias tecnologias?
Sistema monolítico: um grande problema
Coisas entrelaçadas tornam curva de aprendizado dura, pouco reaproveitamento
Preso a uma tecnologia
Muitos programadores “batem cabeça”
Falha em um componente compromete o todo
Dificuldades em escalar tudo: aplicação, equipe, base
A internet é um grande sistema distribuído
O que nos impede de transformar um sistema em vários?
Usar várias tecnologias?
Arquitetura abre um mundo de possibilidades
Monitoramento pode ser direcionado à pessoa certa
Front pode ser uma aplicação mobile, portal, outro sistema, etc.
Colocar API em outro local físico
Adquirir um sistema externo
Assíncrono vs. Síncrono
Falhas “curto circuito”
Garantia de execução ou não
Troca de mensagens / exemplos de quebra
Como usar filas (SQS):
Envia mensagem pra fila
Alguém consome
Auto-scale para trabalhar essa fila / instâncias SPOT
Monitoramento das filas usando CloudWatch
Dead letter queue
Outro uso: não deixar o usuário esperando
Notificações:
Assinantes: filas, lambda
Coerência com o propósito
Eric Evans’s DDD
Coesão do Banco de dados
Gateway Interno
Serviços a expor
Controle de threshold
Autorização microserviço / Autenticação gateway
SSO gateway
Cuidado com o que fixa exposto
RLK
Quem são seus usuários?
Não quebre a aplicação
Versionamento semântico: MAJOR.MINOR.PATCH
Uma CI por microserviço
Strangler – rotear chamdas par nova estrutura ; Big Bang
1) Estrutura “core”
Automatizar tudo o que der (orquestração) / definições de padrões da API / segurança / monitoramento
2) Unificar mecanismo de autenticação
3) Identificar os componentes do sistema (aplicação e banco)
4) Criar seu primeiro microserviço: legado passa a utilizá-lo
5) Começe a esvaziar o monolito