História dos Sistemas - Por que estamos fazendo desse jeito

História dos Sistemas
Porque estamos fazendo desse jeito

sob uma perspectiva da web moderna
lorieri@ google mail dot com

Agenda

Rapidamente pelo PASSADO

Agenda


Lentamente do PRESENTE

Agenda


Lentamente do PRESENTE

Olhadinha no FUTURO

Objetivos
•  Desenvolvimento Web
não é tão fácil como era alguns anos atrás

•  Com fatos do presente do passado,
ajudar novos profissionais

•  Mostrar como velhas tecnologias
foram reempacotadas para ajudar na Web

•  Ficar rico e famoso,
e vocês acharem que eu sou inteligente

Quem eu NÃO Sou

- não sou programador
- não sou cientista
- não sou professor de português
- não sou historiador

Sou apenas um “velho” sysadmin

- "Surge” = "se tornou popular” = "agora é hora de falar"

- "Hacker" aqui é o Cracker, o malvado

- A sequência dos fatos não são precisas

- Termos começam em português depois mudam para inglês

1 - Começo, primeiro computador elétrico

•  ... para propósitos gerais

•  CPU fraco / pouca memória

•  sem disco

•  somente linguagem de máquina

•  somente cientistas

•  muito caro, para poucos: governos,
e instituições

•  feito em laboratórios

•  bugs de verdade

•  Sem rede

2 – Era Comercial, computadores corporativos

•  Empresas: Menos CPU e mais armazenamento

•  Tecnologia de 1795: cartões perfurados para entrada de dados,
armazenamento e processamento

•  Tempo de CPU caro,
programadores sem acesso aos computadores

•  Programação em lote

•  mais simplicidade, mais mão de obra

•  fornecedores comerciais, preços menores

•  Surge o LEO,
o primeiro computador corporativo

Primeira "modinha”

Batch: performance, aproveitando ao máximo
o tempo de uso do CPU

vs

Multiprogramação: poposta de dividir o tempo
de CPU para aumentar a produtividade dos
programadores

Empresas e Ciência

Processamento de Dados Cálculos

3 - Interpretadores

•  Abstração = produtividade

•  Surgimento de fitas magnéticas

•  Começo da abstração de hardware (System Calls)

•  Primórdios dos “frameworks”

•  Mais estudantes

•  Passos para executar um programa:
1 - Carrega o programa interpretador dos cartões para a fita
2 - Carrega o seu programa dos cartões para fita
3 - Carrega os dados dos cartões para a fita
4 - Fita é carregada em outro computador com o sistema básico
5 - Executa os programas e salva o resultado em outra fita
6 - Em outro computador com impressora, resultados são impressos

from Tanenbaum's book

from Tanenbaum's book

4 - Circuito Integrado

•  Começo da Lei de Moore

•  Tudo mais rápido/poderoso porém menor

•  Mais fácil de fabricar = menor preço

•  Popularização

E o que fazer com tanto
poder ?

E o que fazer com tanto
poder ?

- Hora da Multiprogramação !

5 - Multi-programação
•  "THE Multiprogramming System", SO muti-tarefa

•  time-sharing

•  separou a memória e inventou os bugs!

•  separou o sistema em níveis de execução e inventou os...

System Levels

+Access Control

+Bugs

+Complexity

=HACKERS !!!

5 - Multi-programação
•  "THE Multiprogramming System", SO muti-tarefa

•  time-sharing

•  separou a memória e inventou os bugs!

•  separou o sistema em níveis de execução e inventou os hackers

•  introduziu a paginação de memória

•  Surge o sistema de arquivos:
abstração de pedaços de memória persistentes

•  Surge a comunicação inter-processos (IPC)

•  Manipulação de erros amadurecem

6 - Redes

•  Multi-programming necessitava de multi terminais

•  Popularização entre universidades

•  Mais estudantes

•  Trouxe mais criatividade e colaboração

•  Mais Bugs

•  Mais Hackers

7 - Mainframes

•  Big Iron

•  Grande quantidade de dados

•  Tempo=dinheiro, hardware tolerante a falhas

•  Redes lentas contribuem para centralização

•  Custos centralizados de manutenção

•  Começo da Virtualização

•  Surgem os hypervisors

•  Mão de obra super especializada

8 - PC, computadores pessoais

•  Terminais cresceram

•  Ideais para necessidades básicas

•  Jogos !

•  Podiam ser usados como terminal

•  Sem time-sharing, sem multi-tasking

•  Surge o DBM, chave-valor para persistir
configurações, ranking dos jogos, etc.

•  Surge o SO popular e barato: Microsoft

9 - Um pouco de caos

bugs+popularização -> solução de hardware para segurança

MMU
mapeia a memória para criar/traduzir endereços virtuais de
memória de modo que os programas não consigam roubar
espaços um dos outros

A propósito... “computadores reduzem a duplicação de
dados e economizam recursos”

Tamanho da memória ainda
uma fração do tamanho de armazenamento permanente

10 - Popularização

•  Redes: mais e melhores
•  Memoria e armazenamento maiores
•  Mais bugs e mais hackers
•  Conhecimento e mão de obra aumentaram
•  Preços melhores !!

•  Surge o banco de dados relacional (SQL)

•  Surgem os softwares livres
e de código fonte aberto

11 - Era Cliente/Servidor (era da latência)

•  Máquinas pequenas com poder suficiente centralizar tarefas

•  Parte do processamento nos terminais

•  Mainframes começaram a desaparecer

•  Surge o roteador: INTERNET virou realidade!

•  Pequenos websites estáticos

•  Máquinas mais simples = mais fornecedores

•  Internet = fácil acesso ao conhecimento

•  Mão de obra ficou mais cara que o tempo de CPU
=
mais foco em produtividade

Empresas

Mainframes Client/Server

12 - Conteúdo dinâmico na Web

•  Shopping !! e Grana !!

•  Apache inventa os Virtual Hosts: Um computador = diversos sites

•  Surge o PHP: programação simples para internet
Estilo Abre-roda-morre*milhões = Alta escalabilidade

•  Surge o RPC

•  Conceito do MMU para virtualizar Ips (Ip Masq)
1 IP = diversos computadores conectados

•  muita mão de obra
criando milhões de pequenos e simples sistemas web

•  Mais bugs, mais hackers

Shopping = Dinheiro
Tempo é Dinheiro
Tempo = Alta Disponibilidade

Shopping = Experiência do Usuário

Pessoas começaram a
escrever as respostas
em cima dos e-mails

13 - Caos Físico

•  Morte da Lei de Moore

•  Necessidade de mais inovações no software

•  Discos maiores, porém ainda lentos

•  Memórias melhores e mais baratas!

•  Nomes sofisticados e estranhos

•  Engenheiro
•  Arquiteto
•  "Operador" foi substituído por "System Administrator"
•  “Governança em TI”

•  Lei de Moore virou um Objetivo

14 - Paralelismo se tornou crucial
•  Única saída

•  Multi, multi, multi... (CPU, core, thread)

•  Real multi-tasking !!! (Multi-tarefa real)

•  Muitos, muitos, muitos bugs

•  Memória pra todo lado como buffers e caches:
CPU, FileSystem, HD, Controladoras...

•  Lei de Amdahl: "...se 95% do programa pode ser paralelizado,
o aumento teórico de performance máximo atingido usando
paralelismo será de 20x... não importa quantos processadores
serão usados."

... e depois de tanto tempo, o Windows aprendeu como
usar os níveis de execução, a memória virtual e conseguiu
diminuir os travamentos do sistema :)

15 - Virtualização

•  Multiprocessamento trouxe Virtualização para máquinas simples

•  Consolidação de sistemas

•  Fácil de rodar testes e POCs

•  Facilidade de criar ambientes de contingência

•  Porém a velocidade de acesso a disco que já era lenta...

Mainframes trabalham com paralelismo, caches de
hardware, virtualização, multi-core e multi-cpus há 50
anos, pelos menos motivos.

(porém com latência menor)

16 - Situação atual

•  Dados aumentando absurdamente
•  mídias sociais, UGC (User generated content)

•  Porém sem Lei de Moore

•  Storage e banda crescendo, mas latência não diminui

•  Significando: BD central é o gargalo e atual vilão

Banda = tamanho total de operações em um espaço de tempo
Latência = tempo mínimo de uma operação

•  BD = ~ milhares de pequenas operações de I/O por segundo

•  Operações que não deveriam ser colocadas em caches e buffers

17 - Como os softwares podem ajudar?
•  Separando os acessos a disco?
•  Ajustando tudo na memória?
•  Quebrando a lei de não duplicar dados para evitar acessos a
disco ?

•  Fizemos tudo isso: máquinas baratas + rede (Federate)

•  Estilo PHP precisou ser otimizado
•  sem fácil/barato shared memory
•  sem fácil/barato IPC
•  sem fácil/barato controle de “lock”, mutex

•  Mais componentes no backend

•  Hoje me dia é fácil ter um loadbalancer

•  Lembra do IPC e RPC ? Evoluíram para ser a API

•  Use massivo de SOAP e REST

18 - Acessos mais lentos (I/O)
•  Recursos fora das máquinas

•  Caches foras das máquinas

•  Buffers e RPCs cresceram, mas overheads trouxeram
Filas e Message Brokers

•  Respostas mais lentas -> abordagens Assíncronas

•  Lembra do DBM ?
Ganhou rede e tornou-se Sistemas NoSql

•  Lembra do MMU ?
Teve um neto: Distributed hash table (partitioning)

•  Acesso a dados mais complicados: CAP
(Escolher 2 entre 3: consistência, disponibilidade e distribuição)

•  Manipulação de erro mais importante que nunca

1 ns = .000000001 segundo

http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf

1 ns = .000000001 segundo

pior para multi-cpu ou
virtual machines


1 ns = .000000001 segundo

pior para multi-cpu ou
virtual machines

quantos pedaços de hardware pode falhar entre EUA e Europa?


19 - Muito mais desafios
•  Maior complexidade = mais falhas -> tolerância a falhas

•  Complexidade requer maior abstração -> mar de Frameworks

•  Lembra do níveis de execução de sistema ?
Também saíram do computador e viraram ambientes:
•  Development Env
•  Testing Env
•  Staging Env
•  Production Env

•  rollbacks não são mais triviais

•  muitas tecnologias e linguagens misturadas

•  Para reduzir incidentes:
•  automação
•  processos de controle
•  processos de deploy

•  Um grande problema: controle de acesso agora é mundial

Ter mais ambientes antes do ambiente de produção não é burocracia,
É liberdade

20 - e os SSD ?

•  No começo eram bugados e tinham tempo de vida curto

•  Foram bem vindos, porém o desenvolvimento para web estava chato

•  Novos desafios são muito legais

•  Se juntaram a festa

•  Ainda são muito caros

•  Estão sendo usados como grandes buffers e caches,
mais rápidos que acesso a disco porém mais lentos que a memória

21 - *aaS Era

aaS = As a Service, “vendido como serviço”

•  Conceito do Mainframe evoluiu para a nuvem

•  Pay-per-use, assim como eletricidade e telefonia

•  Serviço aaS → “me dê somente um login e senha para usar”

•  Hardware aaS:
•  Lembra dos system calls ? Tornou-se "cloud call”
•  Redução de desperdícios
•  Sem plano de capacidade para picos

•  Software (ou Platform) aaS

•  Deploys tornando-se commodity

22 - Nova ordem mundial
•  Updates constantes, inclusive para OS
•  Github
•  API que mudam toda hora

•  Sistemas complexos e distribuídos agora na web
(Erlang, Nginx, NodeJS)

•  Linguagens funcionais na web (stateless, de fácil distribuição)

•  Browser para gravar, processar e cachear, e agora para guardar

•  RPC direto no browser (JSON)

•  Serem humanos se comunicando em IPC (Twitter)

•  Diversos Dispositivos

•  Ao contrário dos tempos dos Mainframes, os dados são maiores
do que um único computador sequer imagina em processar
•  Map-reduce para todos esses dados

Troca de mensagens e programação orientada a eventos
é exatamente o que o kernel vem fazendo por 40 anos

Y U NO

PARALLELIZE EASILY !?!?!?!

23 - Por que web devs não paralelizam ?

"Entretanto, novas tecnologias são sempre difíceis
de usar no começo, mas tornam-se invariavelmente Is Parallel Programming Hard, And,
mais simples com o passar do tempo. Por exemplo, If So,What Can You Do About It?
.... dirigir um carro era para poucos, ... agora é
Edited by:
comum. ....
Paul E. McKenney
(1) carros ficaram mais baratos e mais fáceis de Linux Technology Center
possuir, dando mais oportunidade para mais IBM Beaverton
pessoas aprender, e paulmck@linux.vnet.ibm.com
(2) carros tornaram-se mais simples de operar, .... January 2, 2011
inclusão de diversas melhorias vinda de outras
tecnologias.”

http://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2011.01.02a.pdf

Significa: Empresas! Porque empresas precisam de produtividade e
baixos riscos, então as coisas acontecem mais devagar

24 - Aceitação de novas tecnologias
E se trocássemos todos os carros por algum outro tipo de veículo ?

Douglas Crockford thoughts (http://yuiblog.com/crockford/)

"As pessoas que deveriam ser as primeiras a reconhecer o valor
de uma inovação são geralmente as últimas."

E ele está falando de desenvolvedores

Quando fábricas de chip estavam mudando para 16bits a Intel lançou um
chip revolucionário que foi um fiasco, conseguiu sobreviver porque voltou
atrás e criou um chip 16bits compatível com o antigo de 8bits e conquistou
o mercado que não queria grandes mudanças, e vem fazendo isso até hoje

"Estamos em um grande momento para ser um programador, temos
diversas escolhas, e precisamos ser espertos fazendo essas escolhas se
sermos abertos a aceitar novas idéias porque existes muitas idéias por aí,
não devemos rejeitá-las somente porque não são familiares ou não
vemos nenhum necessidade pra elas”

25 - Manutenção-”ability”

Não podemos mudar somente nosso carro

Em empresas, não basta somente aceitação,
mas todas adaptações necessárias

•  Ferramentas
•  Bibliotecas suficientes
•  Integração com os processos existentes
•  Integração com automações (de testes e segurança também)
•  Colaboração de colegas dispostos e querendo aprender
•  Comunidade que dê suporte
•  Ótima utilização de recursos, inclusive pessoais

"You are not Google, Amazon or Facebook”
-Ivan Ribeiro, na apresentação "You shall Not Get Excited”

falando sobre a jornada de 2-3 anos para usar Erlang em produção

http://www.slideshare.net/x697272/you-shall-not-get-excited-5851097

26 - Novas Linguagens

Para quebrar o tradicional "LAMP”
e trazer outras tecnologias para a Web

Mas as vezes... exageram

Exemplo:
as 4 linguagens mais populares são:
C, Java, Php, JavaScript, todas baseadas na mesma sintaxe

Geralmente mudanças são justificadas por novas abordagens e novas
tecnologias. As vezes não mudam nada, só perdem produtividade

27 - ORM, agora não

•  Abstrações requerem poder
•  POO na web, só 40 anos depois
•  Templatização, só quando ficou fácil escalar o PHP
•  SQL não é só abstração, é também paralelização

•  Bancos de dados modernos já possuem ótimo cache interno e
um ótimo otimizador de queries

•  Vai contra nosso atual problema: dados
•  Tempo de “cortar”, não podemos pagar por overheads
•  Aceitação de NoSql imediata: necessidade imediata
•  Um problema que não é hora de fingir que não existe

•  Sistemas web são compostos por poucas queries
•  Poucas queries são fáceis de empacotar dentro de funções,
utilizando sistemas especializados de caches
"… frequentemente suposições inseridas na interface se tornam
equívocos”
http://research.microsoft.com/en-us/um/people/blampson/33-Hints/Acrobat.pdf
9th ACM Symposium on Operating Systems Principles, Oct. 1983

Matt Yonkovit - at Percona Live NYC 2011
http://www.percona.com/files/presentations/percona-live/nyc-2011/PerconaLiveNYC2011-How-MySQL-and-NoSQL-Coexist.pdf

28 - E a ciência?

•  Últimas palavras em computação científica:

•  GPU: Graphic CPU, nasceu paralela e distribuída

•  FPGA: Trazendo o software mais próximo do hardware

•  GRID: Rede Internacional e Compartilhada
http://www.opensciencegrid.org/

3 coisas que você pode ter em casa!

29 - Futuro ?
Pare de pensar serial e sequencial

"Compute Local, Act Global.
Otherwise the Overhead will kill you”
- Carlos Bueno, um amigo

Juntar disco e memória e montar
sistemas que não precisam de boot

Nunca houveram tantos dados para
serem usados, especialmente de livre
acesso, tornando pesquisas com
grafos muito mais interessantes

2012 - Fim do mundo ?

Se não: Para de fazer “brute force” usando computação quântica

From GWAN's website

"A new vogue for the now generation
A new profit in the same old game

We got new thoughts, new ideas it's all so groovy
It's just a shame that we all seen the same old movies "
The Saints - Private Affairs

References:
Tanenbaum's "novels",
EWD manuscripts,
Wikipedia,
Google's image search,
My and my friends' experiences.

História dos Sistemas - Por que estamos fazendo desse jeito

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a História dos Sistemas - Por que estamos fazendo desse jeito

Semelhante a História dos Sistemas - Por que estamos fazendo desse jeito (20)

Mais de Leo Lorieri

Mais de Leo Lorieri (6)

História dos Sistemas - Por que estamos fazendo desse jeito

Notas do Editor