Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microsserviços, bem além do hype

Microsserviços, bem além do hype

Hildeberto

April 23, 2019
Tweet

More Decks by Hildeberto

Other Decks in Technology

Transcript

  1. Relação pessoal e profissional com TI • 8 bits -

    Autodidata (1989 a 1991) ◦ PC, Clipper, Pascal, Dbase • 16 bits - Aprendendo no Trabalho (1992 a 2001) ◦ Mainframe, Cobol, CSP, SQL ◦ Redes locais, Windows, Unix, Linux, DB Oracle, Delphi • 32 bits - Graduação (2002 a 2006) ◦ Internet, Ciências da Computação, Paradigmas, C, Java, MySQL, PostgreSQL • Gerente de desenvolvimento de sistemas (2007 a 2011) ◦ Metodologia, Gestão de Processos, Frameworks, Gestão de projetos, Governança • 64 bits - Mudança para Área de Recursos Humanos (desde 2012) ◦ MBA em gestão de Projetos (2016) ◦ Cloud computing, virtual servers, containers, Python ◦ Data Science, IoT, IA, Machine Learning, Deep Learning
  2. Grupo de Usuários Python na Paraíba (PUG/PB) • Promover a

    integração entre desenvolvedores, entusiastas e demais interessados na linguagem • Fomentar e difundir o uso nas empresas e faculdades • Organizar eventos que multipliquem o conhecimento • Compartilhar experiências e projetos • Contribuir com a comunidade nacional e internacional
  3. Microsserviços Nos prefixos ou nos falsos prefixos terminados em vogal,

    diante de palavras iniciadas pelas consoantes R e S, duplica-se a consoante. https://novaescola.org.br/conteudo/328/regras-hifen-alteradas-novo-acordo-ortografico
  4. O desafio • Nova competência no Regulamento: “Fomentar o pronto

    atendimento das necessidades dos servidores e buscar a excelência organizacional” • Competência antiga, mas desafiadora: “Manter atualizado o sistema com os dados relativos aos servidores, viabilizando a extração de informações fidedignas sempre que necessário” • Migração entre sistemas de gestão de pessoas (SIGEP/JT Nacional) • Principais clientes: CNJ, CSJT, TCU, Administração, Magistrados, Servidores, Público em geral
  5. Solução pretendida • Data Warehouse ◦ Sumarizar dados do sistema

    de gestão, com sincronização diária • Portal para agregar funcionalidades de: ◦ Transparência pública ◦ Atendimento a magistrados e servidores ◦ Divulgação (intranet) ◦ Fiscalização (interno) ◦ Organização (interno)
  6. Produtos necessários - Solução ideal • Portal: Agregador, Proxy, Balanceamento,

    Servidor de conteúdo estático (CDN) • Sistema de Gerenciamento de Conteúdo (CMS) • Autenticação (para sistemas internos) • Banco de dados sumário de RH e API de acesso a esses dados • Sincronizador de banco de dados • Lavratura de documentos (produção de PDFs baseado em modelos pré-definidos) • Distribuição de protocolos (com balanceamento de carga) • Legislação e atos internos, com busca textual • Modelos e consultas estatísticas com geração de arquivos para órgãos de controle • Aplicativos de fiscalização e controle interno • Gestão de Riscos e Gestão Estratégica de Pessoal • ufa...
  7. Monolito versus microsserviços • A evolução das tecnologias mudou a

    forma como construímos a arquitetura de aplicativos. • Os serviços Docker, Cloud Services e Container Orchestration nos permitiram desenvolver soluções distribuídas, mais escaláveis e confiáveis. • Não é estritamente verdadeiro que os aplicativos monolíticos sejam sempre simples, mas os microsserviços são geralmente 10 vezes maiores e quase sempre exigem mais recursos.
  8. Monolito versus microsserviços - Implantação • Aplicações monolíticas permitem que

    você defina sua implantação (deployment) uma vez e, em seguida, basta ajustá-lo com base nas mudanças que vierem a acontecer. No entanto, há apenas um único ponto de falha durante a implantação e, se tudo der errado, você poderá “quebrar” todo o seu projeto. • Microsserviços requerem mais trabalho; você precisará implantar cada microsserviço de forma independente, preocupar-se com as ferramentas de orquestração e tentar unificar o formato de suas “esteiras de distribuição” (CI/CD) para reduzir o tempo necessário para fazer a distribuição a cada novo microsserviço. O lado positivo é que, se algo der errado, você só quebrará um microsserviço pequeno, o que é menos problemático. Também é mais fácil reverter um serviço do que um aplicativo monolítico inteiro.
  9. Monolito versus microsserviços - Infra-estrutura • Se você planeja usar

    uma arquitetura de microsserviços, contrate um DevOps para sua equipe e prepare-se. • Nem todo desenvolvedor está familiarizado com o Docker ou com ferramentas de orquestração, como Kubernetes, Docker Swarm, Mesosphere ou qualquer ferramenta semelhante, que podem ajudá-lo a gerenciar a infraestrutura com várias partes móveis. • Alguém tem que monitorar e manter o estado de funcionamento de sua configuração de Integração Contínua, para cada microsserviço e toda a infraestrutura.
  10. Monolito versus microsserviços - Confiabilidade • A arquitetura de microsserviços

    é o vencedor óbvio aqui. • A quebra de um microsserviço afeta apenas uma parte da aplicação e causa problemas somente para os clientes que a usam, ninguém mais.
  11. Monolito versus microsserviços - Escalabilidade • Os microsserviços são novamente

    mais adequados. • Aplicativos monolíticos são difíceis de escalar porque, mesmo se você colocar mais recursos (pessoas, equipamentos, etc), todos estarão em um projeto único e completo (uma maneira ineficiente de usar recursos). • Pior, você pode escrever seu código da maneira que tornaria impossível dimensioná-lo horizontalmente, deixando apenas a escala vertical possível (mais recursos numa mesma máquina). • Com microsserviços, isso é muito mais fácil. Os recursos podem ser usados com mais cuidado e permitem dimensionar as partes que exigem mais recursos.
  12. Monolito versus microsserviços - Custo • O custo é difícil

    de calcular porque a arquitetura monolítica é mais barata em alguns cenários, mas não em outros. • Com a melhor escalabilidade dos microsserviços, é possível configurar uma escala automática e pagar apenas por isso quando o volume de usuários realmente exigir mais recursos. • Ao mesmo tempo, para manter essa infraestrutura em funcionamento, você precisa de um ou mais Devops, que é um especialista “caro”. • Um monolítico pequeno pode rodar em um host de US$ 5 a US$ 20 e ativar escala automática (cuidado!). • Um monolítico maior vai precisar de uma instância muito cara, pois não é possível compartilhá-la em vários hosts pequenos e baratos.
  13. Monolito versus microsserviços - Desenvolvimento • Um projeto relativamente simples

    pode ter mais de 10 microsserviços, e isso pode ser complicado para lidar. • A melhor maneira é criar seu arquivo de “composição do Docker” desde o início e desenvolver através do Docker. Isso também ajuda a reduzir o tempo gasto na integração de novas pessoas. Basta executar o sistema a partir do zero e iniciar os microsserviços conforme necessário. Abrir 10+ janelas de terminal e executar comandos para iniciar cada serviço individual é uma dor. • Quando você desenvolve um microsserviço, pode ter casos em que não precisa executar outras partes do aplicativo. Isso resulta em menos problemas com conflitos de versionamento, devido ao melhor processo de decomposição de tarefas e à capacidade de isolar os desenvolvedores por microsserviço. • Fazer revisão de código e controle de qualidade é mais simples com microsserviços; você pode até mesmo ser capaz de escrever microsserviços em diferentes linguagens (o que pode aumentar o custo).
  14. Monolito versus microsserviços - Liberação de novas versões • Os

    microsserviços que são menores, se modelados com uma arquitetura adequada de comunicação entre eles, permitem que você libere novas versões mais rapidamente, reduzindo o tempo de controle de qualidade, o tempo de construção/compilação, e o tempo de execução dos testes. • Os aplicativos monolíticos têm muitas dependências internas que não podem ser divididas. Há um risco maior de que algo com o qual você esteja comprometido possa depender de alterações inacabadas dos membros de sua equipe, o que poderia adiar as liberações.
  15. Qual arquitetura é melhor? • Use a arquitetura monolítica se

    você: ◦ Tem uma equipe pequena ◦ Vai construir a versão MVP de um novo produto ◦ Não conseguiu investimento/recursos para contratar DevOps ou gastar mais tempo em arquitetura complexa ◦ Tenha experiência de desenvolvimento em estruturas sólidas, como Ruby on Rails, Laravel, Django, etc. ◦ Não perceba gargalos de desempenho para funcionalidades importantes ◦ Acho que os microsserviços são legais e é uma tendência (não siga o hype).
  16. Qual arquitetura é melhor? • Use a arquitetura de microsserviços

    se você: ◦ Não tem um prazo apertado; microsserviços exigem que você pesquise e planeje a arquitetura para garantir que ela funcione. ◦ Tem uma equipe com conhecimento de diferentes linguagens. ◦ Preocupe-se muito com a escalabilidade e confiabilidade do seu produto. ◦ Potencialmente tem vários departamentos de desenvolvimento (talvez até mesmo em diferentes países / fusos horários). ◦ Tem um aplicativo monolítico existente e observa problemas com partes de seu aplicativo que podem ser divididos em vários microsserviços.
  17. Porquê Docker? • Open Source e Free Software • Economia

    de recursos • Arquitetura simplificada • Instalação padronizada para desenvolvimento e produção • Deploy simplificado • Portabilidade • Escalabilidade https://hub.docker.com/
  18. Porquê Python? • Open Source e Free Software • Facilidade

    para construir software web e operar com servidores • Testável e manutenível • Interação facilitada com outras linguagens • Conjunto invejável de bibliotecas, estáveis e verificadas pelo uso • Aprendizado com curva amena, para novas tecnologias ainda não utilizadas pela equipe • Codificar em Python é divertido e a comunidade se ajuda https://www.python.org/
  19. Empresas que são referência em microsserviços • Netflix ◦ 149

    repositórios • AirBNB ◦ 179 repositórios • Google ◦ 1460 repositórios • Uber ◦ 169 repositórios • Amazon, Comcast Cable, Ebay, SoundCloud, Karma, Groupon, etc
  20. Áreas das ferramentas ligadas a microsserviços • Linguagens de programação

    ◦ Elixir, Java, Go, Python, etc. • Containers e Orquestração ◦ Docker, Kubernetes • Monitoramento ◦ Prometheus • Gerenciamento e testes de API • Integração e Entrega contínuas • Mensageria e Filas de Execução • Serverless, Cloud Servers ◦ AWS, Azure, GCP, etc.
  21. Referências • https://medium.freecodecamp.org/monolith-vs-microservices-which-architecture-is-right-for-your-team-bb840319d531 • https://medium.com/@raycad.seedotech/monolithic-vs-microservice-architecture-e74bd951fc14 • https://dzone.com/articles/microservices-1-introduction-monolithic-vs-microse • https://www.mulesoft.com/resources/api/microservices-vs-monolithic •

    https://dev.to/alex_barashkov/microservices-vs-monolith-architecture-4l1m • https://www.youtube.com/watch?v=nrzLdMWTRMM • https://www.youtube.com/watch?v=CoDbnoaaiu0 • https://www.youtube.com/results?search_query=microservices • https://caylent.com/building-microservices/ • https://dzone.com/articles/30top-tools-for-building-microservices-on-all-leve
  22. Obrigado. Perguntas? [email protected] https://github.com/hilam https://dev.to/hilam Twitter: @__hilam__ PUG/PB: https://pb.python.org.br https://github.com/pug-pb

    https://groups.google.com/forum/#!forum/pug-pb Telegram: https://t.me/pugpb Slack: http://grudepb.slack.com/ (Canal #pug-pb)