O guru da tecnologia da informação e o diretor técnico da revista Ars Technica, Jason Marlin, tem mais de vinte anos de experiência no suporte a infra-estruturas de informação - e, na sua opinião, muita coisa mudou nessa área.
O jogo Pit, que funcionava como uma porta do BBS. Nesta captura de tela, Lee Hutchinson ataca esses caras. Ou eles são ele.
Na década de 1980, cresci um nerd de verdade - não no sentido moderno, mas no sentido de sempre levar comigo uma edição de cinco quilos da revista
Computer Shopper (sim, essas publicações eram realmente grandes). Fiquei viciado no Bulletin Board Systems aos dez anos de idade. Não é de surpreender que, no final, eu me tornasse o diretor técnico do site, cobrindo questões de ciência e tecnologia.
Posso traçar paralelos claros entre o trabalho de dar suporte ao meu BBS (ou seja, o trabalho do sysop) e o gerenciamento da infraestrutura da web moderna. Vamos marcar esses paralelos em homenagem ao 20º aniversário do site da Ars. Este artigo não será um histórico exaustivo dos sites, aqui descreverei minha própria experiência no gerenciamento de sites e como ela evoluiu nos últimos 20 anos - bem como as ferramentas e o pensamento mudaram.
CARGA “*”, 8, 1
Minha primeira experiência como sysop foi obtida no Commodore 128 (é claro, no modo de 64 bits), onde o programa Color 64 de Greg Pfountz funcionava. Enviei meu cheque a Greg (bem, ele foi assinado por minha mãe) e recebi um disquete de 5,25 "com uma instrução costurada à mão impressa em uma impressora matricial e depois começou.
A Color 64 ficou incrível graças ao ASCII, pintado de acordo com o padrão ANSI, ao contrário da maioria dos outros programas BBS que produziam texto banal incolor. A cor 64 tornou possível criar uma experiência do usuário. Não consigo mais lembrar os nomes do meu BBS, mas garanto que o tema principal estava relacionado a dragões e / ou kung fu. Tenho um pouco de vergonha de admitir que meu apelido era DragonMaster, mas só confirmei os estereótipos associados aos nerds.
Infelizmente, minha infraestrutura de rede consistia em uma única linha telefônica, o que significava que eu tinha que desconectar todos os dispositivos de chamada (ou seja, um telefone de disco montado na parede) e trabalhar entre 23 e 5 horas. Isso também significava pouca interatividade do BBS. Com uma única linha e uma única unidade Commodore 1571, os usuários não podiam conversar entre si ou baixar mais de um jogo por vez.
O comodoro 1670 ainda faz o coração bater mais rápidoNos meus sonhos, no futuro próximo, eu dirigia o BBS real, algo como o então famoso Las Vegas Fear & Loathing, que eu frequentemente visitava. Nos meus sonhos, havia 10 linhas telefônicas para que os usuários pudessem se comunicar em tempo real e se conectar a 1200 modems - não, nem 2400 bauds! E em um disco rígido mítico com um volume de até 10 MB do sistema
Lt. Kernal teria mantido um estoque infinito de jogos.
Infelizmente, tudo isso era inacessível para mim, mas eu estava claramente infectado com alguma nova doença que encorajava um desejo incomum de criar uma área digital na qual os usuários pudessem se reunir.
Década de 1990
Continuei a mexer com o software BBS, incluindo um predecessor HTML muito interessante como o
Excalibur BBS . Dê uma olhada nos
resultados de pesquisa de imagens do Google para ver como esse software estava à frente de seu tempo.
$: cd ~ / public_html
Eu conheci HTML na faculdade em meados dos anos 90; então eu fiz meu dever de casa e o carreguei no diretório público, e os professores poderiam analisá-los em seu tempo livre usando os navegadores Netscape ou Mosaic. Um excelente motivador da época era 10 pontos extras por "usar a tecnologia".
Apache + Perl + XML + Hospedagem Compartilhada
Um dos primeiros "aplicativos" reais que criei como desenvolvedor da Web foi o departamento de notícias de uma empresa de telecomunicações. Tudo isso funcionou em um pacote generalizado: o Apache como servidor HTTP, o Perl como idioma do servidor e o banco de dados como arquivo de texto. Naquela época, eu não estava familiarizado com bancos de dados reais, mas sabia como escrever e analisar XML. Tudo isso foi hospedado em uma plataforma colaborativa incrivelmente boa, na qual eu poderia escrever todas as regras do servidor em um arquivo .htaccess. Logo aprendi que esse arquivo dava muito poder às minhas mãos inexperientes!
A hospedagem colaborativa resolveu meus problemas, mas naquela época os desenvolvedores dependiam de administradores em tudo relacionado a versões e extensões de software. Você também precisava se preocupar com o que seus vizinhos estão fazendo com recursos compartilhados, incluindo todo tipo de coisas desagradáveis. Hackear uma máquina pode comprometer centenas de sites.
IIS, extensões do FrontPage e acesso
Como resultado, a agência em que trabalhei ganhou clientes suficientes para comprar seu próprio servidor. Para meu desgosto, acabou sendo uma máquina Windows executando o IIS (Internet Information Services). Esse território era completamente desconhecido para mim, mas depois de iniciar o IDE do Frontpage, fiquei surpreso com o quão simples a Microsoft fazia as tarefas geralmente difíceis de armazenar entradas verificadas no banco de dados. (Não, sério, simplesmente incrível). Como resultado, procurei o IDE gráfico perfeito, incluindo uma bagunça breve e frustrante com o Macromedia Dreamweaver. Logo aprendi que as ferramentas que criam código automaticamente geralmente produzem uma quantidade enorme de macarrão, que somente essas mesmas ferramentas podem desdobrar.
O gerenciamento do IIS no Windows NT 3.5 também parecia uma tarefa fácil e perigosa para alguém com experiência no Unix. E, ao mesmo tempo, havia uma sensação de restrições rígidas - onde estavam os arquivos .conf nos quais era possível fazer o microajuste (e bagunçar fenomenalmente)?
Essa montagem tornou-se minha plataforma por um tempo, fizemos vários CMS solicitados para nossos clientes, sem pensar em manter uma base de código comum, suporte a longo prazo ou controle de versão. Que horror!
Início dos anos 2000, começando com o ColdFusion
Agora compreendo o horror da situação, mas gostei muito do ambiente Allaire
ColdFusion e o usei por pelo menos quatro anos para criar aplicativos e redes corporativas grandes o suficiente. Ela trabalhou com base na CFML (linguagem de marcação ColdFusion). Parecia HTML, mas fazia consultas triviais aos bancos de dados e sua integração com tecnologias externas, como Java Servlets ou CORBA. O ColdFusion tinha muitos oponentes, mas eu nunca fui um defensor de uma tecnologia específica e apenas escolhi o que me permitiu concluir a tarefa mais rapidamente.
Estruturas da Web aparecem
A muito baixa barreira de entrada do ColdFusion ganhou a notoriedade de uma linguagem idiota que atraiu programadores de baixa qualidade para essa área - bem como o PHP costumava ser. Não posso argumentar com isso, mas a ironia é que meu primeiro conhecimento de uma boa estrutura da Web ocorreu na forma de
Fusebox . Tudo começou com uma tentativa de organizar um aplicativo usando convenções simples de nomeação de arquivos e sistema de diretório. Parecia óbvio, mas, como a maioria dos desenvolvedores da Web da época, fui atraído por uma abordagem em constante evolução do layout do aplicativo e lutei com coisas que se separavam, como consultas ao banco de dados e componentes de saída. Eu brinquei com o
Struts , mas como era impossível usar Java no trabalho principal, ainda não o compreendi. Mas o Fusebox abriu meus olhos para plataformas com o paradigma
MVC (model view controller) que ultrapassa os limites de linguagens específicas. E isso foi muitos anos antes do aparecimento daquela
apresentação de 15 minutos de Ruby on Rails, feita por
David Heinemeyer Hansson .
Hoje, eu nunca consideraria criar um aplicativo grande sem escolher uma estrutura, e hoje temos muitas opções interessantes. Para PHP, eu gosto mais
do Laravel .
Sim, então apenas explodiu o telhado.
Hospedagem na Web em cluster
Tive minha primeira experiência com um site de alto tráfego em 2002. À medida que o tráfego aumentava, aumentava a responsabilidade e o número de chamadas no meio da noite exigindo a reinicialização do servidor. E, finalmente, decidi descobrir tudo sobre balanceamento de carga, cache e hospedagem de cluster. Essa foi outra revelação, porque abriu as possibilidades de escala quase ilimitada.
Se uma máquina ficasse offline, tínhamos carros de segurança para garantir que tudo funcionasse. Tínhamos análises e métricas detalhadas de cluster. A vida era linda, como o meu sonho.
Ascensão das máquinas virtuais: AWS, Vagrant
Aparentemente, a AWS (Amazon Web Services) apareceu do nada e deu aos desenvolvedores exatamente o que precisávamos. Eles também removeram intermediários da hospedagem tradicional. Não precisávamos perguntar quais tecnologias estávamos autorizadas a usar; de repente tudo foi possível. Deseja tentar fazer um aplicativo no Django ou NodeJS? Não tem problema Inicie duas máquinas virtuais e pronto. Tudo isso pode ser feito com a AWS: firewalls virtuais, balanceadores de carga, clusters especiais para bancos de dados, CDN (rede de entrega de conteúdo) para recursos estáticos e quase tudo o que você poderia imaginar. Tornou-se um data center para fabricação própria - e era ao mesmo tempo uma maldição e uma bênção. Ao adicionar cada novo serviço, era necessário rastreá-lo e para que alguém soubesse criá-lo depois que tudo quebra (e tudo quebra). Muito interessado no desenvolvedor, era muito fácil se livrar mais do que ele podia mastigar.
O que a AWS tornou possível na nuvem, o
Vagrant tornou possível em uma máquina de produção. O Vagrant nos deu acesso fácil e programável a vários provedores de VM. Eu pude testar novos tipos de Linux e todos os tipos de pacotes de software em um ambiente que, quando se tratava de implantação, era muito fácil recriar na nuvem. Se algo der errado durante a instalação, o comando mais simples de destruição de vagabundo permitirá que você comece da mesma imagem. Isso tornou o desenvolvimento muito mais agradável do que executar servidores em um sistema operacional doméstico ou usar diretamente o VMWare ou o VirtualBox.
2010s - De Webmasters a DevOps
Vamos desacelerar um pouco e falar sobre como eu sempre odiei o termo webmaster.
Man: O que você faz na vida?
Eu: eu crio aplicativos legais da Web usando várias linguagens de programação e trabalho com a infraestrutura ...
Man: Ahhh, então você é um WEBMASTER!
Quero remover esta palavra nojenta do uso.
Além de associar essa palavra a um cubo de jogo de 20 lados, ela não descreve de maneira alguma o papel que muitos de nós desempenham na programação e no gerenciamento de infraestrutura. Portanto, eu realmente gosto dessa mudança, passando na última década, para termos mais respeitados, como
DevOps . Os engenheiros do DevOps usam a programação para criar, gerenciar e documentar a infraestrutura do mundo real.
Chef + ansible
Quando comecei a trabalhar na Ars Technica, queríamos poder adicionar ou remover facilmente servidores da Web e servidores de banco de dados em um ambiente virtualizado. Após explorar várias abordagens, optamos pelo
Chef , que simplifica o gerenciamento da infraestrutura por meio de uma hierarquia de analogias, principalmente relacionadas à cozinha (faca, livro de receitas, receitas, etc.). Tendo estudado como as propriedades das variáveis, ou "atributos", como são chamadas aqui, surgem de funções e se separam em nós separados, torna-se muito simples gerenciar o software e as versões do servidor a partir de uma única plataforma. O Chef nos permitiu parar de fazer o microgerenciamento de servidores individuais em clusters e facilitou a tarefa de atualização em massa.
Hoje, pessoalmente, prefiro trabalhar com o
Ansible , um sistema baseado em Python desenvolvido pela Redhat - é mais fácil trabalhar e é um pouco menos frágil ao trabalhar em pequenas organizações. Diferentemente do Chef, onde é necessário um servidor central, o Ansible usa o SSH da máquina host (no nosso caso, de nossos laptops nos quais estamos desenvolvendo), mas para empresas maiores ele ainda possui um servidor, o Tower. O Ansible também permite gravar a maior parte da configuração no YAML, o que melhora muito sua legibilidade.
Há vários anos, hospedamos o
ServerCentral Turing Group . Eles nos ajudam a escolher o equilíbrio certo entre o que somos bons (escrever código e configurar a VM) e o que não podemos controlar completamente - são geradores a diesel de segurança, redes redundantes ou cópia em tempo real de dados em um data center projetado ignorar falhas.
A partir de 2019
Eu sempre serei nostálgico por aqueles dias serenos de digitação manual de comandos para o modem, quando em algum lugar do horizonte fomos atraídos pelas promessas emitidas pelo
cortador de grama ou pelo Hal 9000. Mas o momento atual também contém enormes oportunidades para a próxima fase da evolução da infraestrutura. Existem tantas ferramentas promissoras que planejamos colocar nos negócios, por exemplo,
Docker Swarm ou
Kubernetes . É incrível perceber até onde chegamos e quanto mais produtivo o desenvolvedor de hoje pode ser comparado aos velhos tempos cheios do misterioso chiado do BBS. Espero que observemos uma abstração cada vez maior da complexa tecnologia multicamada necessária para uma presença moderna na web.
Desejamos-lhe sucesso nos próximos 20 anos!