O documento discute a diferença entre homens e meninos no desenvolvimento de sistemas para o mundo real. Homens não se preocupam apenas com a estética do código, mas também com aspectos como realidade, administrabilidade, disponibilidade, debugabilidade, escalabilidade e performance no runtime. Falhas inevitavelmente ocorrerão e sistemas precisam ser projetados para lidar com elas.

1. SISTEMAS PARA O
MUNDO REAL
Leandro Silva, CIO @ Locaweb
http://leandrosilva.com.br
TDC 2012

2. QUEM SOU EU?

3. LEANDRO SILVA @codezone
• 15 na indústria (escrevendo software de produção)
• Fissurado em programação (Ruby, Java, Erlang, Clojure, C#, F#)
• Blogueiro preguiçoso (http://leandrosilva.com.br)
• Já fui gerente de sistemas, arquiteto de sistemas, líder técnico,
programador e instrutor de programação e arquitetura
• Tenho código no GitHub (https://github.com/leandrosilva)
• E perfil no LinkedIn (http://linkedin.com/in/lesilva)

4. VAMOS AO TEMA
Sistemas para o Mundo Real – Diferenciando homens e meninos

5. O MUNDO DOS UNICÓRNIOS
Uma ilusão para os meninos?

6. É um mundo onde o que é cool é:
• Framework que nasceu hoje de manhã
• TDD red-green-dummy até da classe Sexo
• Cucumber-like stuff para programador
• Dojo de HTML
• 37 gems instaladas para um hello_world.rb
• Devopar em servidor de produção
E, claro, reinventar a roda. Só que... quadrada!

7. “Eu posso construir* um sistema em produção em 24h”
* Usando meu super-crud framework e um usuário root no servidor de produção

8. H O
O N
S
“Eu posso construir* um sistema em produção em 24h”
* Usando meu super-crud framework e um usuário root no servidor de produção

9. “Poxa, aquele framework de JavaScript assíncrono que eu inventei é uma
super novidade. Adoro surpreender o usuário com coisas que vão
simplesmente aparecendo na tela. Como é bom ter liberdade para inovar!”

10. “Poxa, aquele framework de JavaScript assíncrono que eu inventei é uma
super novidade. Adoro surpreender o usuário com coisas que vão
simplesmente aparecendo na tela. Como é bom ter liberdade para inovar!”
D E
IDA
IA L
E N
G

11. E no final das contas, todo esse sonho e empolgação dá em...

12. E no final das contas, todo esse sonho e empolgação dá em...
O R
D

13. Porque o Mundo Real bate à porta, mais cedo ou mais tarde

14. O MUNDO REAL (1)
Beleza é importante quando homens escrevem sistemas?

15. Todo mundo gosta de código bonito...

16. Todo mundo gosta de código bem fatorado...

17. É sempre bom quando os códigos seguem um padrão, um estilo...

18. Eu sou assumidamente do
tipo que:
• Gosta de código bonito
• Ama design de software
• Tem necessidade de seguir
padrões
• Adora style guides (Google
Python Style Guide, já viu?)
E eu preso muito por isso no
meu time de desenvolvimento

19. Mas a verdade é que escrever código bonito, bem
fatorado e desenhado, que segue um style guide super
coerente e cheio de testes automatizados nunca
livrou ninguém de ser acordado de
madrugada para entrar em uma sala de crise, com
uma baita pressão no cangote, porque a empresa está
perdendo dinheiro em transações não realizadas

20. Todas essas preocupações com os aspéctos est(é)áticos são
importantes, indiscutívelmente, porque elas te ajudam a:
• Se comunicar melhor com o time
• Entender o que você ou alguém fez,
muito tempo depois
• Implementar idéias com mais
facilidade
• Dar mais produtividade no
desenvolvimento
• Etc, etc, etc
Não pare de ter essas preocupações!

21. Homens se preocupam com os
aspéctos esté(á)ticos dos sistemas que
escrevem para o Mundo Real, sim!
Mas isso não é tudo...
* Jennifer Morrison, a Dra Cameron, da série de TV House

22. O MUNDO REAL (2)
É no runtime que homens e meninos se sobressaem

24. “Enterprise software must be cynical. Cynical software expects
bad things to happen and is never surprised when they do.
Cynical software doesn’t even trust itself, so it puts up internal
barriers to protect itself from failures. It refuses to get too
intimate with other systems, because it could get hurt.”
– Michael T. Nygard, no livro Release It

26. Há pelo menos 6 coisas com que homens se
preocupam quando escrevem sistemas para o
Mundo Real, que definitivamente os diferenciam dos
meninos:
• Realidade
• Administrabilidade
• Alta disponibilidade
• Troubleshootabilidade (Existe essa palavra?)
• Escalabilidade
• Performance

27. REALIDADE
Você escreve sistemas que passam em que tipo de teste?

28. Homens sabem que o Mundo Real é bem mais cruel que
qualquer ambiente de QA:
• Não somente testes funcionais (tenho aqui alguns requisitos
funcionais implementados bem bonitinho, olha só... só tem um
probleminha: donwtimes frequentes, tudo bem?)
• Testes de impulso (carga rápida e repentina, uma martelada)
• Testes de estresse (carga excessiva e prolongada, propagando
tensão por todo sistema)
• Testes de longevidade (para pegar erros que só acontecem
quando o sistema está rodando há muito tempo)
• Testes de falha de componente (derrubar conexão com BD,
particionar rede, congelar job em execução, etc)

29. ADMINISTRABILIDADE
Você já pensou em quem vai administrar seu sistema?

30. Homens sabem que sysadmins são os primeiros usuários de
duas aplicações:
• README (overview do sistema, decisões de arquitetura, pré-
requisitos, instalação, update, administração, etc)
• Padrões do SO que roda o sistema (empacotamento,
diretórios, configurações, start-stop-restart, etc)
• Arquivamento de dados (isso vai acontecer algum dia?)
• Particionamento de dados (como fazer isso?)
• Monitoração (monitorar o que e como?)
• Backup (fazer backup do que? É restaurável depois?)

31. ALTA DISPONIBILIDADE
Você acha que não vai haver falhas em seus sistemas?

32. Só um detalhe antes... O que são sistemas?
Sistemas são mais do que um conjunto de aplicações; aplicações
são apenas componentes de um sistema. Um sistema pode ser
composto, por exemplo, de:
• Aplicações web (aquelas que os usuários finais usam, sabe?)
• Aplicações de processamento em lote (a.k.a. jobs)
• Servidores de web, de aplicações, de jobs, de filas, de cache, ...
• Balanceadores de carga
• Virtualizadores de IP
• Bancos de dados
• Redes
• Storage
• Etc, etc, etc

33. Homens não são ingênuos, eles esperam por falhas no sistema e
procuram por maneiras de lidar com elas:
• Redundância de componentes (servidores, BD, filas, zonas)
• Balanceamento de carga (cuidado, quando um componente
falha, seus pares falham muito mais rápido)
• Modo de falha (cache, dados locais “readonly” – é melhor ter
menos funcionalidades funcionando do que não ter nada)
• Timeout (se for para falhar, que seja rápido então!)
• Retry (cuidado com o intervalo e o número de tentativas)
• Circuit Breaker (se você sabe que uma operação vai causar
falhas, não deixe elas acontecerem e registre-as para estudo)
• Barrier (uma fila pode ajudar nisso)
• Princípio de Hollywood (quando menor o acoplamento,
menhor a propagação de problemas)

34. TROUBLESHOOTABILIDADE
Como é que você investiga e descobre problemas?

35. Homens sabem que problemas vão acontecer, inevitávelmente,
e que em meio a uma crise, cada minuto vale ouro, então estão
sempre preocupados com:
• Log – muito log! (sistema + negócio, rastreáveis, monitoráveis,
pesquisáveis, facilmente acessíveis)
• Monitoração (componentes + funcional, histórico de
comportamento, correlação de eventos, health)
• Watcher (qual o estado atual do sistema?)

36. ESCALABILIDADE
Você desenha seus sistemas para serem escaláveis?

37. Homens sabem que, de repente, uma ação de marketing pode
fazer com que a carga em um sistema se multiplique da noite
para o dia:
• Projetar para crescer (building blocks multiplicáveis)
• Arquitetura horizontal (crescer favorecendo disponibilidade)
• Stateless (o máximo possível, por ser horizontal scale-friendly)
• Statefull (Redis ou Memcahed são seus amigos)
• Cache (pode ser uma bênção ou uma maldição na hora de
escalar um sistema, cuidado como faz isso)
• Sizing (seu sistema foi projetado suportar que volume de
dados e quantos usuários simultâneos?)

38. PERFORMANCE
Você negligencia performance no início?

39. Homens sabem que “otimização prematura é a raíz de todos os
males” não significa “não dê atenção a performance”:
• Lento na implementação, N vezes mais lento em produção
• Gargalos de performance (latência é frequentente gera falhas)
• Cache (pode diminuir a latência, mas pode mascaras falhas)
• Índices de banco de dados
• Modelos de dados (SQL vs NoSQL, normalizado vs
desnormalizado, granularidade grossa vs fina)
• Sizing (seu sistema foi projetado completar quantas
transações por segundo?)

40. CONCLUSÃO
O que separa homens de meninos?

41. Homens não se preocupam tão somente com a estética de
seus códigos, mas com o runtime de seus sistemas como um
todo:
• A infra-estrutura completa
• Todos os componentes
• Quem vai operá-los e administrá-los
• Quão disponíveis precisam ser
• Quão fáceis de escalar eles são
• Quão seguros (hardening)
• Quão monitoráveis e debugáveis
• Quantas transações por segundo
devem atender
Vão acontecer falhas no runtime de produção.
Você precisa identificá-las, lidar com elas, superá-las e manter o

42. Meninos tem boa vontade, empolgação, energia, mas muita ingenuidade
de achar que seus códigos bonitos vão livrar seus sistemas de falhas e
vão deixá-los dormir à noite, quando estiverem em produção

43. Você vai ficar de que lado, hamm?

44. LIVROS QUE RECOMENDO
A essência de todo “overview” que dei até aqui

46. PERGUNTAS?

47. OBRIGADO!
Leandro Silva, CIO @ Locaweb
http://leandrosilva.com.br