O documento discute como planejamento de infraestrutura levou ao sucesso ao longo do tempo, passando de um servidor local para vários servidores especializados na nuvem. Inicialmente, tudo era feito em um único servidor local sem backups, o que causava perda de dados e problemas. Posteriormente, melhorias como snapshots, controle de versão e backups externos ajudaram, mas problemas de desempenho e disponibilidade persistiram. Uma arquitetura na nuvem com servidores dedicados à aplicação, banco de dados e arquivos estáticos,

1. Quando o planejamento
da infraestrutura
leva ao sucesso

2. Ivan Rosolen
Graduado em Sistemas de Informação
Pós-graduado em Gerência de Projetos
Desenvolvedor a 10+ anos
Autor de vários PHPT (testes para o PHP)
CTO @ Mokation

3. No começo …

4. - Poucos usuários
- Poucos “bugs”
- Tudo na mesma máquina
- Servidor “local”
- Sem backup !!!!

5. Problemas

6. - Delete sem where
- rm -rf /
- Tempestade
- Chutei a regua de energia
- Servidor local

8. Vamos melhorar?

10. - Snapshot/Imagem
- Sistema de controle de versão
- Dumps
- HD Externo
- Fita

11. Snapshot/Imagem
- perda de dados
- espaço em disco
- demora pra voltar (depende)
- onde guardar?

12. Sistema de controle de Versão
- SVN/GIT local/online
- branch/tag/release
- configurações (templates)

13. Dumps
- perda de dados
- definir periodicidade
- aonde guardar?

14. HD Externo/Fita
- perda de dados
- definir periodicidade
- aonde guardar?
- recover depende da rede

15. Problemas

16. Esta VIVO !!!!

17. - Demorado
- Perda de dados
- Dor de cabeça
- Noite em claro

18. Algum tempo depois …

19. - Vários usuários
- Alguns “bugs”
- Tudo no mesmo servidor
- Com backup :)

20. Problemas

21. - Crash
- Muitos usuários
- Muitos acessos
- Muitas operações em disco

22. - Tempo de recuperação
- Perda de dados
- MUITA Dor de cabeça
- MUITAS Noites em claro

23. Vamos melhorar?

25. Ta de brincation?

26. - Servidor para aplicação
- Servidor para banco de dados
- Servidor para arquivos estáticos

27. Porque tudo isso?

28. Porque SIM !!!!

30. Entendendo o porquê

31. Aplicação

32. - Servidor com configurações específica
- Muitos requests
- Sem concorrência de I/O
- Fácil replicação para aguentar carga
- Nuvem
- Melhorias no deploy (devops)

33. - Várias aplicações em um mesmo servidor

34. - Várias aplicações em um mesmo servidor
- Site/App/Admin/API

35. - Várias aplicações em um mesmo servidor
- Site/App/Admin/API
- Segurança

36. - Várias aplicações em um mesmo servidor
- Site/App/Admin/API
- Segurança
- Muda uma config do webserver…

37. - Várias aplicações em um mesmo servidor
- Site/App/Admin/API
- Segurança
- Muda uma config do webserver…
- Uma aplicação demanda mais memória

38. - Várias aplicações em um mesmo servidor
- Site/App/Admin/API
- Segurança
- Muda uma config do webserver…
- Uma aplicação demanda mais memória
- Recupera dados de uma aplicação

39. - Várias aplicações em um mesmo servidor
- Site/App/Admin/API
- Segurança
- Muda uma config do webserver…
- Uma aplicação demanda mais memória
- Recupera dados de uma aplicação
- Backup

40. Banco de Dados

41. - Servidor com configurações específica
- Muitos requests
- Memória
- Relatórios e Read Replica
- Vários tipos de banco de dados
- Fácil replicação para aguentar carga
- Nuvem

42. Arquivos Estáticos

43. - Servidor com configurações específica
- Cache/CDN
- Muitos requests
- Sem concorrência de I/O
- Espaço em disco
- Nuvem

44. Nuvem

45. Vantagens

46. - Backup automatizado
- Transferência de responsabilidade
- Suporte
- Especialistas
- Controle/Alertas
- Segurança

47. Arquitetura do Software

48. - Configurações
- Sessões
- Deploy automatizado
- Testes
- “Robos”
- Componentizar

49. Referência AWS
Yros Pereira Aguiar Batista - https://www.youtube.com/watch?v=Mey_hUKNpQY

50. Dúvidas?

51. Obrigado!
@ivanrosolen