Arquitetando e evoluindo um ERP para a Nuvem

Palestra apresentada na qcon.

Transcript

1. u m e r p p a r a a n u v e m ARQUITETANDO E EVOLUINDO @andremidea @mvlbarcelos
2. André Midea Dev focado em Ops na Bluesoft. www.andremidea.com @andremidea
3. @mvlbarcelos Marcus Barcelos Arquiteto de soluções. Objetivo de estrangular o legado! :)
4. a EMPRESA
5. A EMPRESA
6. A EMPRESA carreiras.bluesoft.com.br labs.bluesoft.com.br
8. DESAFIO Migrar de um data center para a AWS
9. ROADMAP Identificar Problemas 2 Soluções Solução para Problemas internos
10. ANTES
11. Foi pra aws
12. depois Availability Zone #1 Availability Zone #2 Cliente 1,2 Cliente 3 Cliente 4,5,6 Cliente ….. Web app WEB APP WEB APP
13. CONSEQUENCIAS PIOPS. Tipos de instancias. Multi-AZ
14. WE HAVE A PROBLEM Nosso software não foi feito pensando na nuvem.
15. Precisamos Evoluir!
16. Mas… Como?
17. IDENTIFI CAR O que Conseguimos Mudar? AGIR Alterar! MEDIR Ver se o que alteramos deu resultado VER ReSULTA DO O que fizemos deu certo? PROCESSO
18. “Uma longa caminhada começa com o primeiro passo” –Lao Tse
19. identificar Processos pesados concorrendo com o usuário Processamento de arquivos texto com grande volume direto no web server Não Escala na Horizontal
20. AçÃO Processos pesados concorrendo com o usuário Processamento de arquivos texto com grande volume direto no web server Não Escala na Horizontal
21. ACÃO HACKATHON!! =)
22. MUITAS ÍDEIAS
23. IdéÉÉias
24. TORNADO 1.0 Processamento Pesado Assíncrono vs Síncrono Emagrecer o ERP Escala na Horizontal
25. Arquitetura Web app Web Amazon SQS Tornado Cliente Cliente Cliente Enviar NF-e Gerar SPED Task X Task Y Task Z Amazon S3 Amazon RDS Amazon Redshift PostgreSQL
26. BÔNUS Escala na Horizontal Menos Carga no WebServer Processamento em Fila 10.000 Tarefas/dia retirados do web server Tolerancia a Falha
27. Porém…. o ônus sempre acompanha o bônus
28. ÔNUS Estrutura Complexa Deploy Centralizado Code Ownership Adoção do Time não foi boa.
29. TORNAdo 2.0 Pegar os pontos positivos da primeira versão e melhorar! TORNADO 1 = PERFORMANCE TORNADO 2 = FACILIDADE
30. Objetivos OWNERSHIP ONECLICK DEPLOY SIMPLE DEV ENV
31. Microservices é hype… vamos usar.
32. AçÕES Separar Tasks em Serviços Processo que controla Serviços Deploy Individual e sem Downtime
33. ARQUITETURA 2.0
34. FLUXO
35. BENEFÍCIOS Tarefas Isoladas Deploy sem Downtime e a qualquer momento Desenvolvimento não precisa conhecer da infra
36. Desvantagens Maior Complexidade no Manager Mais Coisas para Gerenciar
37. TORNADO CLI ./newtask.sh • Archetype • Cria Repositório • Gera Pipeline no Jenkins • Gera todas configurações
38. ONE CLICK DEPLOY
39. DASHBOARD
40. APRENDIZADO NÃO CENTRALIZE ISOLAMENTO RASTREABILIBADE USE A NUVEM A SEU FAVOR
41. NEXT STEPS CONTAINER SERVICE!
42. 1 2 3 4 5 1. Nova Release 2. Deploy - Docker Image 3. Mudança de Versão Subir docker image correspondente 4. Enviar Tasks para versão nova 5. Matar Serviço Antigo FLOW
43. DOcker maven plugin <build> <plugins> ... <plugin> <groupId>com.spotify</groupId> <artifactId>docker-maven-plugin</artifactId> <version>0.2.4</version> <configuration> <imageName>task-sped-fiscal</imageName> <dockerDirectory>docker</dockerDirectory> <resources> <resource> <targetPath>/</targetPath> <directory>${project.build.directory}</directory> <include>${project.build.finalName}.jar</include> </resource> </resources> </configuration> </plugin> ... </plugins> </build>
44. mvn clean package docker:build - DpushImage
45. Final
46. U S E O Q U E A N U V E M O F E R C E - M A N U T E N ç Ã O + I N O V A Ç Ã O
47. AçÃO Processos pesados concorrendo com o usuário Processamento de arquivos texto com grande volume direto no web server Não Escala na Horizontal
48. ANTES
49. Problemas Consumo de CPU Contínuo Não Escala Cupons param de processar se webserver fica fora Não temos garantia de processamento
50. Objetivos RESILIÊNCIA ESCALABILIDADE NÃO AFETAR USUÁRIO
51. COMO? Lembrando… Use e abuse o que a cloud oferece!
52. http://aws.amazon.com/pt/kinesis/
53. DEPOIS
54. benefícios 22% de requests a menos Disponibilidade Escala Horizontalmente Acompanhamento de Venda em Tempo Real Usuários não são mais afetados
55. Os Desafios não Acabam :)
56. IDENTIFI CAR O que Conseguimos Mudar? AGIR Alterar! MEDIR Ver se o que alteramos deu resultado VER ReSULTA DO O que fizemos deu certo? DEPLOY Deploy Está 
 Lento Teste não Passa Teste passa
 na minha máquina
57. Perfomance boa, entrega devagar… não está certo
58. Identificar Demora para fazer o build. Ambiente de dev ≠ Ambiente de build. Insegurança para Entregar. Feedback rapido por equipes.
59. Objetivos BUILD RÁPIDO RELEASE CONFIÁVEL AMBIENTE PADRONIZADO
60. Abordagem Amazon EC2 Spot Instances
61. jenkis Integração Continua. Criação das instancias SPOT. Deploy.
62. Docker image Firefox headless. Ruby + Watir. Java + Tomcat. Volume montado (war + testes) Docker hub (mesma imagem dev / build)
63. ec2 spot Uma instancia por equipe Custo +- U$ 20,00/instancia
64. ansible SPOT cai com frequência Criar a SPOT pelo Jenkis.
65. Docker? Passa na minha maquina, mas quebra no Jenkins!
66. PQ docker? Desenvolvimento Build/Produção
67. Já rodou os teste na sua maquina com o docker?
68. então… RODA LÁ!
69. FLUXO
70. Valeu a pena? Sem docker Com docker
71. Valeu a pena?
72. wrap up Conheça bem os produtos que sua provedora de cloud oferece
73. wrap up BigBang não é viável em um produto grande. Começa pelas bordas.
74. wrap up Delegue o máximo possível para a provedora de cloud.
75. Obrigado!