Palestra sobre como criar um software mais aderente à nuvem.

1. André Paulovich
Arquiteto de Softwares
ASPNET MVP 2011-2014
Arquitetando sistemas para
obter o melhor da nuvem.

2. André Paulovich
andrepg@ciandt.com | @andrepaulovich
MCP | MCTS | MCT | MCAD | MCSD.Net | MVP Asp.Net 2011-2014

7. Como é hoje?

8. 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

9. 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

10. 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”

11. 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

12. Mesmo “prevendo” você ainda tem um problema!

13. 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. Manutenível Disponível Escalável
Econômico

16. Manutenível Disponível Escalável
Econômico

17. Manutenível Disponível Escalável
Econômico

18. Manutenível Disponível Escalável
Econômico

19. 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

20. 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

21. Manutenível Disponível Escalável
Econômico

22. Comparativo simples!
https://awstcocalculator.com

23. Entenda o
contexto

24. Big Users

27. Fonte: ProgrammableWeb
Clube dos Bilhões
5+ Bilhões de Calls/Dia1+ Bilhões de Calls/Dia

28. A Internet
das coisas

31. E a exigência dos
usuários é cada vez
MAIOR!!!

34. Evolução
Virtualização
Físico SaaSVirtual IaaS PaaS
Nuvem

35. 35
Modelos

36. 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

38. 90% das
aplicações
são assim.

39. Desafios arquiteturais
Posso pegar minha aplicação atual e publicá-la na nuvem para ter todas
estas vantagens?

41. Ele continua
sendo um
Porco!

42. “On the line”
Clickgram

43. 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.

45. Requisição Resposta
JAVA
MySQLREDIS HD

46. Requisição Resposta
Servidor 01
JAVA
MySQLREDIS HD

47. Mas lembre-se de
que precisa ser
escalável!

48. Servidor 01
JAVA
MySQLREDIS HD
Servidor 02
JAVA
MySQLREDIS HD
Requisição Resposta Requisição Resposta

49. MySQLREDIS HD
Parece bom, mas as camadas de dados não são
escaláveis simplesmente “dobrando” os servidores.
E agora?!

50. 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.

51. Voltamos à estaca
zero!

52. Dica de ouro!

54. ServidorServidor
ServidorServidor
JAVA
MySQL
REDIS
HD
Isole cada componente da sua aplicação!

55. Problema: O banco de dados está muito lento.
O que fazer?

56. Servidor (master)Servidor
ServidorServidor
JAVA
MySQL
REDIS
HD
Um master-slave pode funcionar!
Servidor (slave)
MySQL

57. Os bancos relacionais,
são “limitados”!
(DBA´s por favor sem polêmica)

58. ServidorServidor
ServidorServidor
JAVA
NoSQL
REDIS
HD
Mas considere usar bancos NO-SQL

59. Problema: A quantidade de escritas e leituras no sistema de
arquivos (armazenamento de fotos) precisa aumentar.
O que fazer?

60. ServidorServidor
ServidorServidor
JAVA
NoSQL
REDIS
Storage
Não use um sistema de arquivos convencional.

61. Problema: O sistema de cache precisa de mais memória.
O que fazer?

62. ServidorServidor
ServidorServidor
JAVA
NoSQL
REDIS + Memória
Storage
Neste caso, aumentar a memória de um servidor basta!

63. Problema: A aplicação não está atendendo todas as requisições
por conta de limitação do processamento.
O que fazer?

64. 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

65. Servidor
Servidor
ServidorServidor
GAE
DataStore
GAE - MEMCACHE
Cloud
Storage
Servidor
GAE
Servidor
Cloud
NetworkingRequisição
Resposta
Visão usando “recursos de nuvem” do google.

66. Servidor
ServidorServidor
GAE
DataStore
GAE - MEMCACHE
Servidor
GAE
Servidor
Cloud
NetworkingRequisição
Resposta
Indo ainda além… pense fora da caixa.

67. 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

68. Perguntas?!

69. Por hoje é só pessoal!
Obrigado, velhinhos!

70. THANK
YOU FOR
YOUR
TIME!