DevConf - Separando uma aplicação monolítica @Rafael Girolineto

DevConf - Separando uma aplicação monolítica @Rafael Girolineto

Primeiro Evento organizado pelo Opensanca se trata do DevConf, tivemos a participação do Rafael Girolineto (https://www.linkedin.com/in/girolineto/) abordando sobre Microserviços

B2519015997dff04abe2568ebb2cf729?s=128

opensanca

May 27, 2017
Tweet

Transcript

  1. Microserviços Separando uma aplicação monolítica: Estudo de caso CasaeCafe.com

  2. Rafael Pereira Girolineto Eng. da Computação - USP São Carlos

    9 anos no mercado de TI Líder técnico no CasaeCafe.com Apreciador de cerveja e café (não necessariamente nesta ordem) Apaixonado por Fotografia (analógica e digital)
  3. O que são microserviços? Onde eles moram? De que se

    alimentam?
  4. Agenda • Aplicações Monolíticas e Microserviços • Microserviços ◦ Definições

    ◦ Aplicabilidade ◦ Padrões de Design ◦ Docker ◦ Vantagens e Desvantagens • CasaeCafe.com ◦ Problema ◦ Solução Proposta ◦ Passo a Passo ◦ Dificuldades
  5. Monolito ou Microserviços

  6. Qual a diferença? Monolito Microserviços Se você não é capaz

    de construir uma aplicação monolítica bem estrutura, o que te faz pensar que microserviços é uma saída? – Simon Brown
  7. Monolito • Processo Único • Base de dados unificada •

    Integrações via chama de função • Integrações no banco de dados • Uso de uma stack única • Tendência a alto acoplamento • Tendência a baixa redundância de informação Fonte: https://martinfowler.com
  8. Microserviços • Múltiplos processos • Separação do modelo de dados

    • Integrações por chamadas remotas • Fronteira bem definida • Possibilidade de diversas stacks • Baixo acoplamento entre módulos • Tendência a alta redundância de informação Fonte: https://martinfowler.com
  9. Microserviços

  10. Definições • Independência: ◦ Modelo Interno ◦ Tecnologias utilizadas ◦

    Atualizações / Deploys ◦ Escalabilidade • Descentralização dos dados (e do modelo de dados) • Propósito único: domínio a ser tratado • Fronteira: ◦ Codebase separada (uni / multi repositórios) ◦ API pública estável, versionada e bem definida ◦ Protocolo único de comunicação (RESTish)
  11. Aplicabilidade Quando faz sentido adotar Microserviços? "Qualquer empresa que projeta

    um sistema, inevitavelmente produz um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização." - Melvin Conway
  12. Conway's Law Conway's Law Fonte: https://martinfowler.com

  13. Conway's Law Seguindo esta lei, a empresa que planeja trabalhar

    com Microserviços deve ter equipes com: • Multidisciplinaridade • Autonomia sobre um domínio (ou mais) • Comunicação com times de domínios próximos e VICE-VERSA Fonte: https://www.thoughtworks.com/pt/insights/blog/demystifying-conways-law
  14. Constraints Quais são os requisitos mínimas para adotar Microserviços? Provisionamento

    rápido de infraestrutura: • Utilização de algum provedor de cloud 1 Capacidade de entregar em produção rapidamente • Testes automatizados, releases pequenas, automatização 2 Monitoria básica • Acesso aos logs, status da infraestrutura, status dos serviços 3
  15. Padrões de Design Timeout Controle configurável de tempo máximo de

    espera para obter uma resposta Circuit Breaker Gestão de disponibilidade de serviços através de medição de erros Bulkheads Capacidade de suportar a serviços indisponíveis de forma "graciosa"
  16. Padrões de Design Arquitetura Orientada a Eventos • Consistência eventual.

    • Cada serviço publica eventos sempre que algum dado muda. • Os subscribers destes eventos e podem executar ações após receberem • Após o processamento de toda a árvore de eventos, o sistema fica, novamente, consistente
  17. Arquitetura Orientada a Eventos UI Order Microservice Payment Microservice Payment

    Gateway Realizar pedido Criar pedido ... [evento] Pedido Criado ... [evento] Pagamento Aprovado pagar
  18. Docker • Fidelidade de Ambientes • Comoditização da Infra Estrutura

    • Escalabilidade Horizontal • Deploy consistente
  19. Docker - Orquestradores docker swarm

  20. Veredito? Desvantagens • Complexidade • Impraticável sem automação • Custo

    alto para integração entre módulos • Multiplas stacks Vantagens • Times auto gerenciáveis • Times multifuncionais • Desacoplamento • Independência entre módulos • Arquitetura Evolutiva • Multiplas stacks DEPENDE
  21. Empresas que adotaram microserviços

  22. Casa e Café

  23. A Empresa Marketplace de empregos domésticos • Profissionais buscam emprego

    • Contratantes buscam profissionais • Geolocalização • Reputação + 500 mil usuários
  24. MVP

  25. Qualidade de Código

  26. Escalabilidade

  27. O Problema • MVP tornou-se o produto • Produto ganhou

    escala • Não existiu preocupação com qualidade de software • Lógica de negócio obscura ou desconhecida • Sistema escalou verticalmente • Indisponibilidade de serviço constante
  28. Solução Proposta

  29. Solução Proposta Encontrar uma entidade do sistema que pudesse ser

    isolada 1 Entender a regra de negócio associada à esta entidade 2 Criar um serviço completamente independente com a lógica de negócio implementada 3 Usar o sistema antigo como fallback até que a lógica toda fosse implementada 4 MICROSERVIÇOS
  30. Serviço de Oportunidades Aplicação Monolítica Micro Serviço

  31. Resultados Iniciais • Redução de lock no Banco de Dados

    • Diminuição no tempo médio de transações envolvendo vagas • Fallback permitiu dupla convivência • Insuficiente para resolver problemas de escalabilidade da plataforma
  32. Review Evolução Opport User Prof WebF Event Search Payment Metric

    Message Products Account Fav Notif Auth Audit AppF Extract Behav
  33. Alguns dados técnicos • REST over HTTP - JSON •

    Cluster Docker Swarm • AWS EC2 • Deploy de Imagens Docker • Bancos de Dados MongoDB (e um Cassandra perdido) • Comunicação síncrona (na maior parte) • PHP7 + NGINX
  34. Dificuldades • Problemas por falta de automatização • Problemas por

    falta de monitoria • Perda de produtividade do time: ◦ Ambientes ◦ versionamento de API ◦ Deploy • Overhead de requisições
  35. E agora?

  36. Referências

  37. Referências • Martin Fowler: https://martinfowler.com/ • Microservices.io: http://microservices.io/ • Building

    Microservices - Sam Newman • Release It!: Design and Deploy Production-Ready Software - Michael T. Nygard • ThoughtWorks: https://www.thoughtworks.com • Netflix Techblog: https://medium.com/netflix-techblog • NGINX Blog: https://www.nginx.com/blog
  38. Perguntas? Dúvidas? Certezas?

  39. Obrigado! Bora pro PUB f fb.com/rafael.girolineto @rafakareka rafapg rafapg.85@gmail.com