é simples • Sistemas totalmente independentes • Serviços com responsabilidade específica (coeso) e desacoplados • Facilidade de deploy • Não se prende a uma tecnologia específica • Times trabalhando em paralelo • Ausência de um ponto de falha único Fonte: “Microserviços: dos grandes monólitos às pequenas rotas” https://bit.ly/2rLYmsz
ser maior • A arquitetura geral se torna complexa se não for bem documentada • Monitorar, monitorar e monitorar • O desenvolvimento de recursos novos que abrangem mais de um serviço devem ser cuidadosamente orquestrado em todas as equipes Fonte: Microserviços: dos grandes monólitos às pequenas rotas: https://bit.ly/2rLYmsz
em Y canais, porém quando um vendedor atualiza preço de um determinado produto na plataforma Olist este produto precisa ser re-eleito para depois ser publicado/atualizado nos Y canais.
Django ou Go ou Apistar ou <whatever> • Só persistem e fazem leitura das informações nos bancos de dados services • Consumidores das filas AWS SQS • Contém regra de negócio brokers • Um agregado de serviços com um objetivo comum (b2w-broker por exemplo) apps • “Interfaces” para conversar com os nossos queridos usuários <3 • Não tem persistência
Loafer: https://loafer.readthedocs.io/en/latest/ https://bit.ly/2DAgMCW • Usamos o projeto Loafer para construir todos os nossos services • Loafer é um projeto Python que consome filas do serviço Amazon SQS de forma bem robusta • Vamos a um exemplo prático… https://github.com/rafaelhenrique/simple-sqs-consumer