Digital Day BH - 19/09/205 - CI&T

383 visualizações

Publicada em

Palestra sobre como criar um software mais aderente à nuvem.

Publicada em: Internet
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
383
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
1
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Digital Day BH - 19/09/205 - CI&T

  1. 1. André Paulovich Arquiteto de Softwares ASPNET MVP 2011-2014 Arquitetando sistemas para obter o melhor da nuvem.
  2. 2. André Paulovich andrepg@ciandt.com | @andrepaulovich MCP | MCTS | MCT | MCAD | MCSD.Net | MVP Asp.Net 2011-2014
  3. 3. Como é hoje?
  4. 4. Uso Computação Tempo Uso Inatividade “Liga/Desliga“ • Cargas On/Off (ex.:. Job batch) • Desperdício da capacidade provisionada • Time to market pode ser retardado Padrões de Uso Imposto de renda Cadastro FIES
  5. 5. Uso Computação Tempo “Crescimento Rápido“ • Serviços que precisam crescer e escalar • Crescer é um desafio grande na TI • Deployment complexo Padrões de Uso Whatsapp Facebook Twitter
  6. 6. Computação Tempo “Pico Imprevisível“ Uso • Pico de demanda inesperada • Desempenho comprometido pelo pico • Difícil provisionar nos casos extremos Padrões de Uso Site de Notícias “Earth Shake”
  7. 7. Computação Tempo Uso “Pico Previsível“ • Serviços com micro sazonalidades • Picos devido a demandas periódicas • Complexidade da TI + desperdício Padrões de Uso Sistemas estudantis Bancos
  8. 8. Mesmo “prevendo” você ainda tem um problema!
  9. 9. Tempo Capac idade deTI Carga Alocação de capacidades Desperdício de capacidades Falta de capacidades Previsão de carga Padrão de Crescimento de Capacidade de TI
  10. 10. Manutenível Disponível Escalável Econômico
  11. 11. Manutenível Disponível Escalável Econômico
  12. 12. Manutenível Disponível Escalável Econômico
  13. 13. Manutenível Disponível Escalável Econômico
  14. 14. Tempo Capac idade deTI Carga Alocação de capacidades Desperdício de capacidades Falta de capacidades Previsão de carga Padrão de Crescimento de Capacidade de TI
  15. 15. Carga Redução do investimento inicial Redução do excesso de TI Sem falta de capacidades Redução das capacidades nos momentos de redução da carga Tempo Capac idade deTI Previsão de carga Escalável
  16. 16. Manutenível Disponível Escalável Econômico
  17. 17. Comparativo simples! https://awstcocalculator.com
  18. 18. Entenda o contexto
  19. 19. Big Users
  20. 20. Fonte: ProgrammableWeb Clube dos Bilhões 5+ Bilhões de Calls/Dia1+ Bilhões de Calls/Dia
  21. 21. A Internet das coisas
  22. 22. E a exigência dos usuários é cada vez MAIOR!!!
  23. 23. Evolução Virtualização Físico SaaSVirtual IaaS PaaS Nuvem
  24. 24. 35 Modelos
  25. 25. Seu Datacenter Virtualization O/S Hardware Network Data Applications Firewall Web Sites Applications Data Serviços na Nuvem Applications Firewall Rules Data Virtual Network Máquinas Virtuais Virtual Network Data Applications Firewall Rules O/S Quanto mais à direita, maior o foco no “negócio” Cloud Services
  26. 26. 90% das aplicações são assim.
  27. 27. Desafios arquiteturais Posso pegar minha aplicação atual e publicá-la na nuvem para ter todas estas vantagens?
  28. 28. Ele continua sendo um Porco!
  29. 29. “On the line” Clickgram
  30. 30. Você é o responsável pela infraestrutura de um novo aplicativo chamado Clickgram. O Clickgram permite que qualquer pessoa compartilhe uma foto com seus amigos em apenas um clique! Chegou o momento de você colocar o aplicativo no ar e seu chefe exigiu que não ocorram problemas de escalabilidade ou de disponibilidade.
  31. 31. Requisição Resposta JAVA MySQLREDIS HD
  32. 32. Requisição Resposta Servidor 01 JAVA MySQLREDIS HD
  33. 33. Mas lembre-se de que precisa ser escalável!
  34. 34. Servidor 01 JAVA MySQLREDIS HD Servidor 02 JAVA MySQLREDIS HD Requisição Resposta Requisição Resposta
  35. 35. MySQLREDIS HD Parece bom, mas as camadas de dados não são escaláveis simplesmente “dobrando” os servidores. E agora?!
  36. 36. Requisição Resposta Servidor 01 JAVA MySQLREDIS HD Novamente parece muito bom! Esta abordagem de montar um servidor mais potente vai funcionar por um tempo, mas tem um limite físico.
  37. 37. Voltamos à estaca zero!
  38. 38. Dica de ouro!
  39. 39. ServidorServidor ServidorServidor JAVA MySQL REDIS HD Isole cada componente da sua aplicação!
  40. 40. Problema: O banco de dados está muito lento. O que fazer?
  41. 41. Servidor (master)Servidor ServidorServidor JAVA MySQL REDIS HD Um master-slave pode funcionar! Servidor (slave) MySQL
  42. 42. Os bancos relacionais, são “limitados”! (DBA´s por favor sem polêmica)
  43. 43. ServidorServidor ServidorServidor JAVA NoSQL REDIS HD Mas considere usar bancos NO-SQL
  44. 44. Problema: A quantidade de escritas e leituras no sistema de arquivos (armazenamento de fotos) precisa aumentar. O que fazer?
  45. 45. ServidorServidor ServidorServidor JAVA NoSQL REDIS Storage Não use um sistema de arquivos convencional.
  46. 46. Problema: O sistema de cache precisa de mais memória. O que fazer?
  47. 47. ServidorServidor ServidorServidor JAVA NoSQL REDIS + Memória Storage Neste caso, aumentar a memória de um servidor basta!
  48. 48. Problema: A aplicação não está atendendo todas as requisições por conta de limitação do processamento. O que fazer?
  49. 49. Servidor Servidor ServidorServidor JAVA NoSQL REDIS + Memória Storage Dobramos a aplicação e adicionamos um balanceador de carga! Voilá! Servidor JAVA Servidor Load BalancerRequisição Resposta
  50. 50. Servidor Servidor ServidorServidor GAE DataStore GAE - MEMCACHE Cloud Storage Servidor GAE Servidor Cloud NetworkingRequisição Resposta Visão usando “recursos de nuvem” do google.
  51. 51. Servidor ServidorServidor GAE DataStore GAE - MEMCACHE Servidor GAE Servidor Cloud NetworkingRequisição Resposta Indo ainda além… pense fora da caixa.
  52. 52. Comparando Nuvens! •Não é tão simples. •Esteja “por dentro” das vantagens específicas de cada nuvem. • Precificação • Modelo de cobrança • Tecnologias de plataforma e serviços •Revisite sua arquitetura. • Seja flexível • Não tenha um escopo fechado
  53. 53. Perguntas?!
  54. 54. Por hoje é só pessoal! Obrigado, velhinhos!
  55. 55. THANK YOU FOR YOUR TIME!

×