Sistemas para o Mundo Real
Upcoming SlideShare
Loading in...5
×
 

Sistemas para o Mundo Real

on

  • 3,429 views

Muitos desenvolvedores se preocupam bastante com os aspectos estáticos dos sistemas que constroem, tais como se o código está bonito, se está idiomático, se está seguindo um determinado ...

Muitos desenvolvedores se preocupam bastante com os aspectos estáticos dos sistemas que constroem, tais como se o código está bonito, se está idiomático, se está seguindo um determinado styleguide, entre outros bullet points do bom design de código; e isso é muito bom. Mas isso não é tudo. Há ainda o aspecto real da coisa, o Runtime. É no Runtime que ômis e mininus se sobressaem. E essa apresentação é sobre com o que os ômis mais se preocupam quanto estão escrevendo sistemas críticos – para o Mundo Real, é lógico.

Statistics

Views

Total Views
3,429
Views on SlideShare
862
Embed Views
2,567

Actions

Likes
5
Downloads
6
Comments
0

9 Embeds 2,567

http://leandrosilva.com.br 2250
http://www.locawebers.com.br 298
http://locawebianos.com.br 5
http://www.feedspot.com 5
http://www.linkedin.com 4
http://translate.googleusercontent.com 2
http://ps.googleusercontent.com 1
http://74.6.239.84 1
http://smashingreader.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Sistemas para o Mundo Real Sistemas para o Mundo Real Presentation Transcript

  • 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 TEMASistemas 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çãoE, 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 dotipo 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 nomeu time de desenvolvimento
  • Mas a verdade é que escrever código bonito, bemfatorado 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, comuma 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ãoimportantes, 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, etcNão pare de ter essas preocupações!
  • Ômis se preocupam com os aspéctosesté(á)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
  • “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
  • Há pelo menos 6 coisas com que ômis se preocupamquando escrevem sistemas para o Mundo Real, quedefinitivamente os diferenciam dos mininus:• Realidade• Administrabilidade• Alta disponibilidade• Troubleshootabilidade (Existe essa palavra?)• Escalabilidade• Performance
  • REALIDADEVocê escreve sistemas que passam em que tipo de teste?
  • Ômis sabem que o Mundo Real é bem mais cruel que qualquerambiente 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)
  • ADMINISTRABILIDADEVocê já pensou em quem vai administrar seu sistema?
  • Ômis sabem que sysadmins são os primeiros usuários deduas 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 DISPONIBILIDADEVocê 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çõessão apenas componentes de um sistema. Um sistema pode sercomposto, 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 eprocuram 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)
  • TROUBLESHOOTABILIDADEComo é que você investiga e descobre problemas?
  • Ômis sabem que problemas vão acontecer, inevitávelmente, eque em meio a uma crise, cada minuto vale ouro, então estãosempre 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?)
  • ESCALABILIDADEVocê desenha seus sistemas para serem escaláveis?
  • Ômis sabem que, de repente, uma ação de marketing podefazer com que a carga em um sistema se multiplique da noitepara 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?)
  • PERFORMANCEVocê negligencia performance no início?
  • Ômis sabem que “otimização prematura é a raíz de todos osmales” 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ÃOO que separa ômis de mininus?
  • Ômis não se preocupam tão somente com a estética de seuscó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 atenderVão acontecer falhas no runtime de produção.Você precisa identificá-las, lidar com elas, superá-las e manter osistema disponível, completando transações para seus usuários
  • Mininus tem boa vontade, empolgação, energia, mas muita ingenuidadede 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 RECOMENDOA essência de todo “overview” que dei até aqui
  • PERGUNTAS?
  • OBRIGADO!Leandro Silva, CIO @ Locaweb http://leandrosilva.com.br “Eita terra boa ess’aqui, hein?!”