Explicando DevOps para a minha mãe
Olá, meu nome é Renata e eu sou DevOps, baseada em Toronto, Canadá. Todos os meus amigos sabem o que eu faço, mas eu sempre tive uma imensa dificuldade de explicar o que eu faço para a minha mãe, que é médica e vem de outra geração. Então, eu pensei que, fora da minha bolha, existe um imenso grupo de pessoas que deve ler termos como "DevOps", "Computação de Nuvem", "Software Livre", entre outros, todos os dias e fica mais perdido que cachorro em dia de mudança. Eu poderia explicar, em palavras mais simples, não só para a minha mãe, mas para todas essas pessoas, o que diabos é DevOps e porque essas tecnologias estão tão em voga de uns anos pra cá.
O objetivo deste artigo é explicar de modo simplificado para pessoas que não foram expostas a estes conceitos antes, então, se você é da indústria, entende de computadores, e sabe do que eu estou falando, este artigo não é para você e vai certamente achar minhas generalizações grosseiras (elas são, de propósito)
Parte I : No meu tempo…
Eu comecei a trabalhar com sistemas ainda no século passado, que hoje em dia soa menos engraçado do que quando eu comecei a falar isso. Naquela época, como computadores não eram tão poderosos assim. Para efeito de comparação, um dos servidores de produção do Google em 1998 tinha dois processadores Pentium II de 300MHz, 512Mb de RAM e 10 discos de 9Gb (fonte), enquanto meu celular, que eu carrego no meu bolso hoje, tem um processador Snapdragon de oito cores de 2.45GHz, 8Gb de RAM e 128Gb de "disco" (storage), em 128 gramas apena. Portanto, o trabalho de administração de sistemas na época era bastante diferente.
Alguns conceitos básicos para ajudar:
Um sistema operacional é um programa de computador que controla a parte física (hardware) e faz a conexão entre o hardware e os outros programas que o usuário (este é você) porventura venha a instalar. Uma explicação clássica sobre hardware e software, do meu tempo, dizia que software é o que você xinga e hardware é o que você chuta. Continua funcionando.
Um servidor é um computador mais poderoso do que você tem em casa e cujo objetivo é — adivinha só —servir alguma coisa: um site da internet, um banco de dados, um programa da sua empresa, qualquer coisa que não seja seu computador do dia a dia. Esse é um desktop.
Produção é o termo usado para um serviço ou produto que está atendendo ao público e precisa estar funcionando. Não é um produto em estágio de pesquisa, experiência ou teste, está na linha de fogo e precisa estar 100% positivo e operante.
Código ou código-fonte são comandos que uma pessoa escreve e são interpretados pelo computador.
Linha de comando é uma interface onde você digita comandos (duh), que pode ser um terminal
Programador é quem escreve código para rodar num computador. Administrador de sistemas é quem gerencia o computador onde o código vai rodar. DevOps é, teoricamente, um Administrador de Sistemas que faz uma ponte entre os programadores e a administração de sistemas.
A maior parte dos usuários domésticos no auge dos anos 90 tinha alguma versão de Windows instalada nos seus computadores. Outros sistemas operacionais, como Macintosh — criado pela hoje famosa Apple — e variações de Unix (nomes que você já teria ouvido falar, como Linux, Minix, FreeBSD, OpenBSD), eram nichos de mercado. Não vou dizer que não existe um mercado de Windows para administração de sistemas porque seria uma mentira grosseira, mas qualquer um que trabalhe com isso a sério sabe que, desde o advento do Linux em meados dos anos 90, as pessoas embarcaram nos sistemas baseados em Unix e nunca mais olharam para trás. E eu sou uma dessas pessoas, esse artigo é focado em sistemas Unix e eu não pretendo falar mais de Windows a partir desse parágrafo.
Parte II: Unix e como Linux virou uma coisa
Eu mencionei Unix lá em cima, mas o que diabos é Unix? Explicação curta: foi um sistema criado para rodar em mainframes em conjunto pelo MIT, Bell Labs e GE nos anos 60. Um sistema Unix permite usuários independentes, simultâneos, rodando programas independentes. Expandindo esse conceito, isso permite que a usuária maria esteja editando o documento textosdamaria ao mesmo tempo em que a usuária joana, em outra sala (vale lembrar que nesse tempo não existia internet) se loga através da rede e resolve jogar um joguinho e não vê nem afeta o documento da maria. Sistemas Unix foram originalmente pensados para universidades (daí a criação no MIT, uma das melhores universidades de pesquisa do mundo), para garantir aos alunos acesso a dados de um computador central e uma certa independência e segurança para as suas próprias contas.
A história do Unix é *extremamente* longa e complicada. Várias versões apareceram, desenvolvidas por diversas empresas. Eventualmente, o conceito de Software Livre surgiu. Software livre não significa software gratuito, significa software cujo código é aberto para a comunidade editar e compartilhar. Existem diferentes modelos de software livre mas isso não vem ao caso. Em 1991, inspirado pelo modelo de software livre, um aluno de origem sueca da Universidade de Helsinki, na Finlândia, chamado Linus Torvalds (você provavelmente já ouviu esse nome), desenvolveu uma versão livre de Unix e chamou, sem a menor vergonha, de Linux — um trocadilho de Linux com Unix.
O que faz o Linux tão especial? Qualquer um pode olhar o código do Linux. Qualquer um pode escrever código para o Linux. Qualquer um pode editar o código do Linux. Qualquer um pode copiar o código do Linux e criar a sua própria versão de Linux. O Linux, em si, é um sistema-base — chamado kernel — e não vem com uma interface gráfica bonitinha, joguinhos, instalador de programas ou coisas do tipo. O Linux é extremamente básico, é um apartamento na planta que você pode encomendar com um chão de porcelanato ou tábua corrida, pias de granito ou mármore, paredes dividindo a sala e a cozinha ou tudo open-concept, de acordo com seus interesses, e vender, morar, ou alugar depois. Dessa forma, o Linux pode ser usado para qualquer coisa — com o porém de precisar um usuário mais experiente para deixá-lo no ponto. EU SEI, sempre existe aquela pessoa dizendo "MAS ESTE VAI SER O ANO DO LINUX NO DESKTOP". Claro. Eu ouço isso há pelo menos quinze anos, adoro Xubuntu, mas ainda tenho um MacBook Pro (rodando High Sierra, que é só uma versão fofinha de Unix ) como meu computador de trabalho ;)
Quando você opta por rodar Linux, você escolhe uma distribuição. Cada distribuição tem suas características, como gerenciadores de software, e algumas vêm ou não com uma interface gráfica (a parte onde você vê ícones, joga joguinhos, abre imagens, etc) instalada. Uma das características interessantes do Linux é oferecer VÁRIAS interfaces gráficas diferentes — eu particularmente gosto de uma chamada XFCE, mas, honestamente, tem UM MONTE. Difícil escolher. Quando você roda Linux num servidor, você não precisa da interface gráfica, nem de nenhum dos penduricalhos que costumam vir com sistemas dedicados a usuários domésticos. Esses penduricalhos consomem recursos de hardware — memória RAM, espaço em disco, processamento — e tudo isso é muito precioso quando seu programa vai estar disponível para o público 24 horas por dia, 7 dias por semana, 365 dias por ano — a famosa "alta disponibilidade".
Várias distribuições de Linux foram otimizadas para essas configurações de servidor, e isso culminou com Linux sendo a escolha para segurar a onda de todos os maiores 5 sites de toda a internet mundial — Google, Facebook, Baidu, Wikipedia e Reddit. Claro que apelo à maioria é uma falácia, eu não estou tentando justificar que Linux é bom porque todo mundo usa. Eu estou explicando que muitas pessoas, inclusive empresas de grande porte, acharam no Linux uma boa solução por causa da capacidade de customização.
Parte III: Mas vem cá, você não ia falar de Nuvem e DevOps?
Foi mal, eu me empolguei e me distraí, mas isso te deu informações importantes sobre o que eu vou dizer agora. A gente já concordou que, nos últimos 20 anos, os computadores ficaram MUITO potentes, e que o Linux é extremamente configurável. O que significa que, em algum momento, alguém disse "nossa, e se eu conseguisse rodar OUTRO Linux dentro do meu Linux? Ou até OUTROS Linuxes diferentes???????". Eu não sei dizer com certeza quem teve essa idéia primeiro, mas várias pessoas tiveram idéias similares e implementações mais ou menos parecidas apareceram mais ou menos na mesma época. Isso é o que chamam de Virtualização — rodar um computador virtual dentro de um computador real. O limite de computadores virtuais que pode-se rodar em um computador real está apenas no hardware do computador real. Existem várias tecnologias diferentes para virtualização, e qual você vai usar depende do objetivo e/ou preferência pessoal.
Eventualmente esses computadores virtuais são executados em servidores que estão na internet. Antigamente, você tinha um computador, e dentro dele você executava o sistema operacional, o sistema operacional gerenciava uma série de programas e "servia" esses programas para a internet. A estrutura básica de um site no começo dos anos 2000 era mais ou menos assim:
A partir de um computador real, uma pessoa executava um programa cujo objetivo é servir páginas para a web. Essas páginas podem ser estáticas, escritas na linguagem HTML, e estilizadas com a linguagem CSS, que são interpretadas diretamente pelo seu navegador (Chrome, Firefox, Safari, entre outros). Essas páginas também podem ser dinâmicas, escritas em linguagens como Ruby, Python, Java, PHP, que lêem informações de um banco de dados como MySQL, PostgreSQL, MongoDB e Cassandra e montam a página que vai ser exibida na hora, proporcionando uma experiência melhor para o usuário — você.
Isso funcionava, mas significava que cada usuário estava acessando dados de um único computador, e, como eu já disse antes, computadores ficaram muito poderosos, e isso se tornou desperdício de processamento e até meio problemático de gerenciar. Então novas idéias apareceram, e empresas como a Amazon, que têm datacenters imensos espalhados pelo mundo inteiro (imagine armazéns imensos — se você já foi ao Rio, aqueles armazéns do Cais do Porto — agora imagine eles cheios de computadores conectados à internet o tempo todo) resolveram o problema oferecendo soluções mais ou menos assim:
Isso é obviamente muito mais complexo que ter simplesmente um ou dois computadores rodando meia dúzia de programas para tomar conta! Então existem mil maneiras de preparar Neston e, de modo geral, automatiza-se a preparação do seu Neston para que todo Neston que você prepare saia sempre do mesmo jeito. Isso é o que chamam de DevOps: escrever código para automatizar tarefas de gerenciamento de sistemas (eu disse que ia explicar!)
Raríssimas configurações hoje em dia (ou pelo menos na minha vida) envolvem menos de dez sistemas. Por exemplo, até uns meses atrás eu estava num trabalho no qual gerenciava, sozinha, quase dez mil máquinas (não estou inflando números e não vou entrar nos detalhes). A única solução, nesses casos, é utilizar uma ferramenta que cuide disso tudo para você, e você cuida da ferramenta. Aí fica mais fácil!
Existem algumas soluções prontas e famosas para várias partes do processo. É possível criar modelos de computadores virtuais e iniciar dezenas, centenas seguindo o mesmo modelo, todos iguaizinhos, em questão de minutos, e ter uma rede de computadores conectados servindo seu site em diversas partes do mundo. Só custa caro, of course ;)
A filosofia de otimização de serviços é que menos é mais, portanto, quanto mais modular a sua estrutura, melhor o seu sistema. Isso se chama microservices (não sei o nome disso em Português, nem sei se existe uma tradução para isso — microsserviços? ). A idéia por trás disso é que, ao invés de rodar programas em máquinas virtuais separadas, você tem containers dentro das suas máquinas virtuais, e dentro de cada container você roda a menor parte possível do seu programa.
Isso é bom (em teoria) porque, se uma parte do seu programa falhar, ele não leva o resto do programa junto, e basta você reiniciar aquele container isoladamente sem afetar a performance do resto do seu sistema como um todo, ou da máquina virtual. A arquitetura dos sites hoje em dia é muito mais complexa que a estrutura simples que eu desenhei grosseiramente aí em cima, de servidor web-banco de dados-servidor de arquivos, e portanto não é apenas viável, mas necessário. Esse exemplo vai ser péssimo porque eu não sei dirigir, mas imagine que você tem um carro, mas você vive num universo paralelo em que cada parte mecânica do carro vem isolada numa caixinha e pode ser replicada imediatamente a partir de um comando que você executa enquanto está dirigindo. Portanto, digamos, se seu tanque de combustível falha, não é um grande problema: seu carro pode continuar funcionando e enquanto você dirige você executa a criação de um novo tanque de combustível, muda para o novo tanque de combustível e remove o antigo, sem que isso afete o resto do seu carro. Eu avisei que o exemplo era ruim, mas ajuda a ter uma idéia.
A Amazon (ela mesma, onde você gasta todo o seu salário em livros e besteiras) é uma das maiores empresas em serviços de Cloud Computing e é difícil se manter atualizado com todos os serviços que ela lança toda semana. Sempre duvide de alguém que se diz um *expert* em Amazon Cloud Computing — é humanamente impossível. Eles oferecem domínios, hospedagem de sites, cloud computing, virtualização, automatização, qualquer porcaria que qualquer um possa ter imaginado. Vários serviços da Amazon têm modelos básicos absolutamente gratuitos — eles querem mesmo que você use para aprender e depois dizer para os seus amigos, colegas, chefes o quanto é legal e aí a empresa, que tem dinheiro, vai assinar o serviço e pagar. Existe uma razão pela qual o Jeff Bezos, dono da Amazon, é o homem mais rico EVER.
Então o modelo de trabalho de DevOps nos dias de hoje inclui (mas não se resume a):
- definir templates para os serviços que serão automatizados
- definir as ferramentas utilizadas para automatizar os serviços
- virtualizar e configurar servidores
- manter tudo isso online e funcionando
É um trabalho muito divertido, que exige aprendizado constante, mas pode ser bastante cansativo — vários empregos exigem plantões e disponibilidade em casos de emergência. Eu associo minha escolha de carreira muito ao fato de ter sido criada por uma mãe médica, ao mesmo tempo que tenho horror de sangue — eu me interesso por resolver problemas difíceis constantemente, lido bem com emergências, tenho um bom raciocínio científico e eterna vontade de aprender coisas novas. Não fosse a minha relação com sangue, poderia até ter tentado Medicina ;)
