SlideShare uma empresa Scribd logo
SISTEMAS PARA O
  MUNDO REAL
  Leandro Silva, CIO @ Locaweb
        http://leandrosilva.com.br




        Abril pro Ruby 2012
QUEM SOU EU?
LEANDRO SILVA @codezone
• 15 na indústria (escrevendo software de produção)
• Fissurado em programação (Ruby, Java, Erlang, Clojure, C#, F#)
• Blogueiro hibernado (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)
VAMOS AO TEMA
Sistemas para o Mundo Real – Diferenciando ônis e mininus
Mas antes, 1 minuto de silêncio pela moquequinha perfeita
     que comi em minha primeira refeição aqui em Recife
O MUNDO DOS UNICÓRNIOS
      Ilusão para mininus?
É 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... bem quadradinha!
“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
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
“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”
“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
E no final das contas, todo esse sonho e empolgação dá em...
E no final das contas, todo esse sonho e empolgação dá em...




                                              O R
                                          D
Porque o Mundo Real bate à porta, mais cedo ou mais tarde
O MUNDO REAL (1)
Beleza é importante quando ômis escrevem sistemas?
Todo mundo gosta de código bonito...
Todo mundo gosta de código bem fatorado...
É sempre bom quando os códigos seguem um padrão, um estilo...
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
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
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!
Ômis 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
O MUNDO REAL (2)
É no runtime que ômis e mininus se sobressaem
Sistemas para o Mundo Real
“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
Sistemas para o Mundo Real
Há pelo menos 6 coisas com que ômis se preocupam
quando escrevem sistemas para o Mundo Real, que
definitivamente os diferenciam dos mininus:

• Realidade
• Administrabilidade
• Alta disponibilidade
• Troubleshootabilidade (Existe essa palavra?)
• Escalabilidade
• Performance
REALIDADE
Você escreve sistemas que passam em que tipo de teste?
Ômis 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)
ADMINISTRABILIDADE
Você já pensou em quem vai administrar seu sistema?
Ômis 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?)
ALTA DISPONIBILIDADE
Você acha que não vai haver falhas em seus sistemas?
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
Ômis 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)
TROUBLESHOOTABILIDADE
Como é que você investiga e descobre problemas?
Ômis 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?)
ESCALABILIDADE
Você desenha seus sistemas para serem escaláveis?
Ômis 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?)
PERFORMANCE
Você negligencia performance no início?
Ômis 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?)
CONCLUSÃO
O que separa ômis de mininus?
Ômis 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
sistema disponível, completando transações para seus usuários
Mininus 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
Você vai ficar de que lado, hamm?
LIVROS QUE RECOMENDO
A essência de todo “overview” que dei até aqui
Sistemas para o Mundo Real
PERGUNTAS?
OBRIGADO!
Leandro Silva, CIO @ Locaweb
       http://leandrosilva.com.br




 “Eita terra boa ess’aqui, hein?!”

Mais conteúdo relacionado

Mais procurados

JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...
JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...
JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...
iMasters
 
Clean Architecture
Clean ArchitectureClean Architecture
Clean Architecture
Rodrigo Branas
 
Discutindo DevOps na pratica, por Danilo Sato
Discutindo DevOps na pratica, por Danilo SatoDiscutindo DevOps na pratica, por Danilo Sato
Discutindo DevOps na pratica, por Danilo Sato
Thoughtworks
 
O Spring está morto! Viva o Spring!
O Spring está morto! Viva o Spring!O Spring está morto! Viva o Spring!
O Spring está morto! Viva o Spring!
Josenaldo de Oliveira Matos Filho
 
Testes Automatizados
Testes AutomatizadosTestes Automatizados
Testes Automatizados
Rodrigo Branas
 
Cultura DevOps e integração entre infra e devel
Cultura DevOps e integração entre infra e develCultura DevOps e integração entre infra e devel
Cultura DevOps e integração entre infra e devel
Jose Augusto Carvalho
 
Quebrando barreiras entre desenvolvimento e operação de software com DevOps
Quebrando barreiras entre desenvolvimento e operação de software com DevOpsQuebrando barreiras entre desenvolvimento e operação de software com DevOps
Quebrando barreiras entre desenvolvimento e operação de software com DevOps
José Alexandre Macedo
 
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian FerrariDrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
Taller Negócio Digitais
 
DevOps - A Origem
DevOps - A OrigemDevOps - A Origem
DevOps - A Origem
André Dias
 
DevOps, NoOps...afinal que raios é isso?
DevOps, NoOps...afinal que raios é isso?DevOps, NoOps...afinal que raios é isso?
DevOps, NoOps...afinal que raios é isso?
Thiago Ganzarolli
 
scrumbut
scrumbutscrumbut
Vivenciando dev ops para além da automação de infraestrutura 2.0
Vivenciando dev ops para além da automação de infraestrutura 2.0Vivenciando dev ops para além da automação de infraestrutura 2.0
Vivenciando dev ops para além da automação de infraestrutura 2.0
Diego Pacheco
 
Java virtual machine quantas linguas fala a jvm2
Java virtual machine   quantas linguas fala a jvm2Java virtual machine   quantas linguas fala a jvm2
Java virtual machine quantas linguas fala a jvm2
Josenaldo de Oliveira Matos Filho
 
Webinar DevOps - Encontros Ágeis
Webinar DevOps - Encontros ÁgeisWebinar DevOps - Encontros Ágeis
Webinar DevOps - Encontros Ágeis
Rodrigo R Garcia, PMP
 
POG nunca mais - SOLISC
POG nunca mais - SOLISCPOG nunca mais - SOLISC
POG nunca mais - SOLISC
Paulino Michelazzo
 
Maven: Introdução
Maven: IntroduçãoMaven: Introdução
Maven: Introdução
JugVale
 
DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014
Rodrigo Campos
 
O que é DevOps afinal?
O que é DevOps afinal?O que é DevOps afinal?
O que é DevOps afinal?
Jose Augusto Carvalho
 
O que move a web atualmente?
O que move a web atualmente?O que move a web atualmente?
O que move a web atualmente?
Fabio Janiszevski
 
Inovando na plataforma Java
Inovando na plataforma JavaInovando na plataforma Java
Inovando na plataforma Java
Eteg
 

Mais procurados (20)

JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...
JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...
JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...
 
Clean Architecture
Clean ArchitectureClean Architecture
Clean Architecture
 
Discutindo DevOps na pratica, por Danilo Sato
Discutindo DevOps na pratica, por Danilo SatoDiscutindo DevOps na pratica, por Danilo Sato
Discutindo DevOps na pratica, por Danilo Sato
 
O Spring está morto! Viva o Spring!
O Spring está morto! Viva o Spring!O Spring está morto! Viva o Spring!
O Spring está morto! Viva o Spring!
 
Testes Automatizados
Testes AutomatizadosTestes Automatizados
Testes Automatizados
 
Cultura DevOps e integração entre infra e devel
Cultura DevOps e integração entre infra e develCultura DevOps e integração entre infra e devel
Cultura DevOps e integração entre infra e devel
 
Quebrando barreiras entre desenvolvimento e operação de software com DevOps
Quebrando barreiras entre desenvolvimento e operação de software com DevOpsQuebrando barreiras entre desenvolvimento e operação de software com DevOps
Quebrando barreiras entre desenvolvimento e operação de software com DevOps
 
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian FerrariDrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
 
DevOps - A Origem
DevOps - A OrigemDevOps - A Origem
DevOps - A Origem
 
DevOps, NoOps...afinal que raios é isso?
DevOps, NoOps...afinal que raios é isso?DevOps, NoOps...afinal que raios é isso?
DevOps, NoOps...afinal que raios é isso?
 
scrumbut
scrumbutscrumbut
scrumbut
 
Vivenciando dev ops para além da automação de infraestrutura 2.0
Vivenciando dev ops para além da automação de infraestrutura 2.0Vivenciando dev ops para além da automação de infraestrutura 2.0
Vivenciando dev ops para além da automação de infraestrutura 2.0
 
Java virtual machine quantas linguas fala a jvm2
Java virtual machine   quantas linguas fala a jvm2Java virtual machine   quantas linguas fala a jvm2
Java virtual machine quantas linguas fala a jvm2
 
Webinar DevOps - Encontros Ágeis
Webinar DevOps - Encontros ÁgeisWebinar DevOps - Encontros Ágeis
Webinar DevOps - Encontros Ágeis
 
POG nunca mais - SOLISC
POG nunca mais - SOLISCPOG nunca mais - SOLISC
POG nunca mais - SOLISC
 
Maven: Introdução
Maven: IntroduçãoMaven: Introdução
Maven: Introdução
 
DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014
 
O que é DevOps afinal?
O que é DevOps afinal?O que é DevOps afinal?
O que é DevOps afinal?
 
O que move a web atualmente?
O que move a web atualmente?O que move a web atualmente?
O que move a web atualmente?
 
Inovando na plataforma Java
Inovando na plataforma JavaInovando na plataforma Java
Inovando na plataforma Java
 

Destaque

Hamlet no Holodeck
Hamlet no HolodeckHamlet no Holodeck
Hamlet no Holodeck
henriquespereira
 
Mundo real
Mundo realMundo real
Mundo real
Otacilio Ribeiro
 
Mundo real x mundo virtual paulo eduardo
Mundo real x mundo virtual paulo eduardoMundo real x mundo virtual paulo eduardo
Mundo real x mundo virtual paulo eduardo
Paulo Martins
 
Contos de Fadas X Mundo Real
Contos de Fadas X Mundo RealContos de Fadas X Mundo Real
Contos de Fadas X Mundo Real
Milasan
 
Mongo db no mundo real slides
Mongo db no mundo real   slidesMongo db no mundo real   slides
Mongo db no mundo real slides
Suissa
 
Cibercultura
CiberculturaCibercultura
Cibercultura
André Pase
 
Internet, Ciberespaço e Cibercultura
Internet, Ciberespaço e CiberculturaInternet, Ciberespaço e Cibercultura
Internet, Ciberespaço e Cibercultura
Michele Pó
 

Destaque (7)

Hamlet no Holodeck
Hamlet no HolodeckHamlet no Holodeck
Hamlet no Holodeck
 
Mundo real
Mundo realMundo real
Mundo real
 
Mundo real x mundo virtual paulo eduardo
Mundo real x mundo virtual paulo eduardoMundo real x mundo virtual paulo eduardo
Mundo real x mundo virtual paulo eduardo
 
Contos de Fadas X Mundo Real
Contos de Fadas X Mundo RealContos de Fadas X Mundo Real
Contos de Fadas X Mundo Real
 
Mongo db no mundo real slides
Mongo db no mundo real   slidesMongo db no mundo real   slides
Mongo db no mundo real slides
 
Cibercultura
CiberculturaCibercultura
Cibercultura
 
Internet, Ciberespaço e Cibercultura
Internet, Ciberespaço e CiberculturaInternet, Ciberespaço e Cibercultura
Internet, Ciberespaço e Cibercultura
 

Semelhante a Sistemas para o Mundo Real

DNAD 2015 - Como a arquitetura emergente de sua aplicação pode jogar contra ...
DNAD 2015  - Como a arquitetura emergente de sua aplicação pode jogar contra ...DNAD 2015  - Como a arquitetura emergente de sua aplicação pode jogar contra ...
DNAD 2015 - Como a arquitetura emergente de sua aplicação pode jogar contra ...
Gleicon Moraes
 
Extreme programming
Extreme programmingExtreme programming
Extreme programming
Maurício Linhares
 
Como automatizar Sistemas Legados utilizando ferramentas de DevOps
Como automatizar Sistemas Legados utilizando ferramentas de DevOpsComo automatizar Sistemas Legados utilizando ferramentas de DevOps
Como automatizar Sistemas Legados utilizando ferramentas de DevOps
Rafael Salerno de Oliveira
 
Novas Fronteiras
Novas FronteirasNovas Fronteiras
Novas Fronteiras
Rangel Torrezan
 
Qualidade e Testes de Software
Qualidade e Testes de SoftwareQualidade e Testes de Software
Qualidade e Testes de Software
André Phillip Bertoletti
 
PHP Anti Patterns
PHP Anti PatternsPHP Anti Patterns
PHP Anti Patterns
Theoziran Lima
 
AULA 06 - REVISÃO DE CONCEITOS INICIAIS DE ALGORITMOS
AULA 06 - REVISÃO DE CONCEITOS INICIAIS DE ALGORITMOSAULA 06 - REVISÃO DE CONCEITOS INICIAIS DE ALGORITMOS
AULA 06 - REVISÃO DE CONCEITOS INICIAIS DE ALGORITMOS
profjotamarcosduarte
 
OmbrosDeGigantes-TDC2014
OmbrosDeGigantes-TDC2014OmbrosDeGigantes-TDC2014
OmbrosDeGigantes-TDC2014
Marcio Marchini
 
Introdução ao XP
Introdução ao XPIntrodução ao XP
Introdução ao XP
Paulo Rebelo, MSc, PMP, CSP
 
SonarQube
SonarQubeSonarQube
SonarQube
CDS
 
Como desenvolver-software
Como desenvolver-softwareComo desenvolver-software
Como desenvolver-software
Fábio Nogueira de Lucena
 
O ciclo da vida
O ciclo da vidaO ciclo da vida
O ciclo da vida
Luiz Borba
 
Como desenvolver com um sistema com um front-end colossal?
Como desenvolver com um sistema com um front-end colossal?Como desenvolver com um sistema com um front-end colossal?
Como desenvolver com um sistema com um front-end colossal?
Mozart Diniz
 
TDC 2017 - Borg até o Prometheus: Site Reliability Engineering
TDC 2017 - Borg até o Prometheus: Site Reliability EngineeringTDC 2017 - Borg até o Prometheus: Site Reliability Engineering
TDC 2017 - Borg até o Prometheus: Site Reliability Engineering
Felipe Klerk Signorini
 
Introdução a DevOps e Continuous delivery agileday
Introdução a DevOps e Continuous delivery   agiledayIntrodução a DevOps e Continuous delivery   agileday
Introdução a DevOps e Continuous delivery agileday
Carlos Felippe Cardoso
 
PHPZEIRO: Adote um framework
PHPZEIRO: Adote um frameworkPHPZEIRO: Adote um framework
PHPZEIRO: Adote um framework
Leonardo "Hackin" Freire
 
Analise e desenvolvimento
Analise e desenvolvimentoAnalise e desenvolvimento
Analise e desenvolvimento
Gabriel Moura
 
Frameworks PHP
Frameworks PHPFrameworks PHP
Frameworks PHP
Augusto Pascutti
 
Carreira de Desenvolvimento
Carreira de DesenvolvimentoCarreira de Desenvolvimento
Carreira de Desenvolvimento
Alvaro Viebrantz
 
Aspectos do aprendizado do paradigma orientado a objetos por programadores pr...
Aspectos do aprendizado do paradigma orientado a objetos por programadores pr...Aspectos do aprendizado do paradigma orientado a objetos por programadores pr...
Aspectos do aprendizado do paradigma orientado a objetos por programadores pr...
Rodrigo Vieira
 

Semelhante a Sistemas para o Mundo Real (20)

DNAD 2015 - Como a arquitetura emergente de sua aplicação pode jogar contra ...
DNAD 2015  - Como a arquitetura emergente de sua aplicação pode jogar contra ...DNAD 2015  - Como a arquitetura emergente de sua aplicação pode jogar contra ...
DNAD 2015 - Como a arquitetura emergente de sua aplicação pode jogar contra ...
 
Extreme programming
Extreme programmingExtreme programming
Extreme programming
 
Como automatizar Sistemas Legados utilizando ferramentas de DevOps
Como automatizar Sistemas Legados utilizando ferramentas de DevOpsComo automatizar Sistemas Legados utilizando ferramentas de DevOps
Como automatizar Sistemas Legados utilizando ferramentas de DevOps
 
Novas Fronteiras
Novas FronteirasNovas Fronteiras
Novas Fronteiras
 
Qualidade e Testes de Software
Qualidade e Testes de SoftwareQualidade e Testes de Software
Qualidade e Testes de Software
 
PHP Anti Patterns
PHP Anti PatternsPHP Anti Patterns
PHP Anti Patterns
 
AULA 06 - REVISÃO DE CONCEITOS INICIAIS DE ALGORITMOS
AULA 06 - REVISÃO DE CONCEITOS INICIAIS DE ALGORITMOSAULA 06 - REVISÃO DE CONCEITOS INICIAIS DE ALGORITMOS
AULA 06 - REVISÃO DE CONCEITOS INICIAIS DE ALGORITMOS
 
OmbrosDeGigantes-TDC2014
OmbrosDeGigantes-TDC2014OmbrosDeGigantes-TDC2014
OmbrosDeGigantes-TDC2014
 
Introdução ao XP
Introdução ao XPIntrodução ao XP
Introdução ao XP
 
SonarQube
SonarQubeSonarQube
SonarQube
 
Como desenvolver-software
Como desenvolver-softwareComo desenvolver-software
Como desenvolver-software
 
O ciclo da vida
O ciclo da vidaO ciclo da vida
O ciclo da vida
 
Como desenvolver com um sistema com um front-end colossal?
Como desenvolver com um sistema com um front-end colossal?Como desenvolver com um sistema com um front-end colossal?
Como desenvolver com um sistema com um front-end colossal?
 
TDC 2017 - Borg até o Prometheus: Site Reliability Engineering
TDC 2017 - Borg até o Prometheus: Site Reliability EngineeringTDC 2017 - Borg até o Prometheus: Site Reliability Engineering
TDC 2017 - Borg até o Prometheus: Site Reliability Engineering
 
Introdução a DevOps e Continuous delivery agileday
Introdução a DevOps e Continuous delivery   agiledayIntrodução a DevOps e Continuous delivery   agileday
Introdução a DevOps e Continuous delivery agileday
 
PHPZEIRO: Adote um framework
PHPZEIRO: Adote um frameworkPHPZEIRO: Adote um framework
PHPZEIRO: Adote um framework
 
Analise e desenvolvimento
Analise e desenvolvimentoAnalise e desenvolvimento
Analise e desenvolvimento
 
Frameworks PHP
Frameworks PHPFrameworks PHP
Frameworks PHP
 
Carreira de Desenvolvimento
Carreira de DesenvolvimentoCarreira de Desenvolvimento
Carreira de Desenvolvimento
 
Aspectos do aprendizado do paradigma orientado a objetos por programadores pr...
Aspectos do aprendizado do paradigma orientado a objetos por programadores pr...Aspectos do aprendizado do paradigma orientado a objetos por programadores pr...
Aspectos do aprendizado do paradigma orientado a objetos por programadores pr...
 

Mais de Leandro Silva

Arquitetura de Software 101
Arquitetura de Software 101Arquitetura de Software 101
Arquitetura de Software 101
Leandro Silva
 
Async/Await Pattern in C#
Async/Await Pattern in C#Async/Await Pattern in C#
Async/Await Pattern in C#
Leandro Silva
 
Uma breve introdução ao Terraform
Uma breve introdução ao TerraformUma breve introdução ao Terraform
Uma breve introdução ao Terraform
Leandro Silva
 
SRE - Esperança não é uma estratégia
SRE - Esperança não é uma estratégiaSRE - Esperança não é uma estratégia
SRE - Esperança não é uma estratégia
Leandro Silva
 
Gerenciando times autogerenciáveis
Gerenciando times autogerenciáveisGerenciando times autogerenciáveis
Gerenciando times autogerenciáveis
Leandro Silva
 
Como vi Scrum ser rechaçado em uma grande empresa
Como vi Scrum ser rechaçado em uma grande empresaComo vi Scrum ser rechaçado em uma grande empresa
Como vi Scrum ser rechaçado em uma grande empresa
Leandro Silva
 
Erlang/OTP - Caelum Tech Day 2009
Erlang/OTP - Caelum Tech Day 2009Erlang/OTP - Caelum Tech Day 2009
Erlang/OTP - Caelum Tech Day 2009
Leandro Silva
 

Mais de Leandro Silva (7)

Arquitetura de Software 101
Arquitetura de Software 101Arquitetura de Software 101
Arquitetura de Software 101
 
Async/Await Pattern in C#
Async/Await Pattern in C#Async/Await Pattern in C#
Async/Await Pattern in C#
 
Uma breve introdução ao Terraform
Uma breve introdução ao TerraformUma breve introdução ao Terraform
Uma breve introdução ao Terraform
 
SRE - Esperança não é uma estratégia
SRE - Esperança não é uma estratégiaSRE - Esperança não é uma estratégia
SRE - Esperança não é uma estratégia
 
Gerenciando times autogerenciáveis
Gerenciando times autogerenciáveisGerenciando times autogerenciáveis
Gerenciando times autogerenciáveis
 
Como vi Scrum ser rechaçado em uma grande empresa
Como vi Scrum ser rechaçado em uma grande empresaComo vi Scrum ser rechaçado em uma grande empresa
Como vi Scrum ser rechaçado em uma grande empresa
 
Erlang/OTP - Caelum Tech Day 2009
Erlang/OTP - Caelum Tech Day 2009Erlang/OTP - Caelum Tech Day 2009
Erlang/OTP - Caelum Tech Day 2009
 

Sistemas para o Mundo Real

  • 1. SISTEMAS PARA O MUNDO REAL Leandro Silva, CIO @ Locaweb http://leandrosilva.com.br Abril pro Ruby 2012
  • 3. LEANDRO SILVA @codezone • 15 na indústria (escrevendo software de produção) • Fissurado em programação (Ruby, Java, Erlang, Clojure, C#, F#) • Blogueiro hibernado (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 ônis e mininus
  • 5. Mas antes, 1 minuto de silêncio pela moquequinha perfeita que comi em minha primeira refeição aqui em Recife
  • 6. O MUNDO DOS UNICÓRNIOS Ilusão para mininus?
  • 7. É 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... bem quadradinha!
  • 8. “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. 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
  • 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”
  • 11. “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
  • 12. E no final das contas, todo esse sonho e empolgação dá em...
  • 13. E no final das contas, todo esse sonho e empolgação dá em... O R D
  • 14. Porque o Mundo Real bate à porta, mais cedo ou mais tarde
  • 15. O MUNDO REAL (1) Beleza é importante quando ômis escrevem sistemas?
  • 16. Todo mundo gosta de código bonito...
  • 17. Todo mundo gosta de código bem fatorado...
  • 18. É sempre bom quando os códigos seguem um padrão, um estilo...
  • 19. 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
  • 20. 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
  • 21. 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!
  • 22. Ômis 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
  • 23. O MUNDO REAL (2) É no runtime que ômis e mininus se sobressaem
  • 25. “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
  • 27. Há pelo menos 6 coisas com que ômis se preocupam quando escrevem sistemas para o Mundo Real, que definitivamente os diferenciam dos mininus: • Realidade • Administrabilidade • Alta disponibilidade • Troubleshootabilidade (Existe essa palavra?) • Escalabilidade • Performance
  • 28. REALIDADE Você escreve sistemas que passam em que tipo de teste?
  • 29. Ômis 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)
  • 30. ADMINISTRABILIDADE Você já pensou em quem vai administrar seu sistema?
  • 31. Ômis 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?)
  • 32. ALTA DISPONIBILIDADE Você acha que não vai haver falhas em seus sistemas?
  • 33. 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
  • 34. Ômis 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)
  • 35. TROUBLESHOOTABILIDADE Como é que você investiga e descobre problemas?
  • 36. Ômis 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?)
  • 37. ESCALABILIDADE Você desenha seus sistemas para serem escaláveis?
  • 38. Ômis 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?)
  • 40. Ômis 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?)
  • 41. CONCLUSÃO O que separa ômis de mininus?
  • 42. Ômis 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 sistema disponível, completando transações para seus usuários
  • 43. Mininus 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
  • 44. Você vai ficar de que lado, hamm?
  • 45. LIVROS QUE RECOMENDO A essência de todo “overview” que dei até aqui
  • 48. OBRIGADO! Leandro Silva, CIO @ Locaweb http://leandrosilva.com.br “Eita terra boa ess’aqui, hein?!”

Notas do Editor

  1. \n
  2. \n
  3. \n
  4. \n
  5. \n
  6. \n
  7. \n
  8. \n
  9. \n
  10. \n
  11. \n
  12. \n
  13. \n
  14. \n
  15. \n
  16. \n
  17. \n
  18. \n
  19. \n
  20. \n
  21. \n
  22. \n
  23. \n
  24. \n
  25. \n
  26. \n
  27. \n
  28. \n
  29. \n
  30. \n
  31. \n
  32. \n
  33. \n
  34. \n
  35. \n
  36. \n
  37. \n
  38. \n
  39. \n
  40. \n
  41. \n
  42. \n
  43. \n
  44. \n
  45. \n
  46. \n
  47. \n
  48. \n