Não tenho melhor abordagem para iniciar este texto a não ser dizer que, em uma carreira de quase uma década, o maior desafio como profissional de TI foi explicar o que eu fazia para quem se atrevia a perguntar além da minha formação ou queria mesmo testar minha erudição acadêmica para que eu não pudesse fugir com um “sou analista” ou “trabalho com tecnologia”. Muito embora os primeiros registros teóricos publicados utilizando a alcunha de DevOps datem já do boom da orientação a serviços e os primeiros livros dedicados surjam em 2008, o analista de DevOps como especialista ainda é um movimento novo, apoiado na disseminação de metodologias que o alavancam, como Tidy, Lean e Agile.

Logo, devo confessar uma coisa muito séria: sempre fui DevOps e não sabia. Por vezes, rótulos podem ser exaustivos e desnecessários, mas é um alívio poder se apoiar em um conceito bem definido e fluido na hora de explicar alguns dos grandes mistérios da administração de infraestrutura, em um mundo ainda acostumado a associar essa palavra a algo físico. Tá certo, saber fazer e explicar é grande e eu sempre soube, mas ter em mãos a essência de como tornar sua explicação concisa e eficiente em todos os aspectos é excelência. E por si só este é o grande tao do DevOps: não basta saber fazer, mas manter e transmitir com sabedoria, organização e persistência (sim, muita).

O que é o DevOps e quais suas bases?

Talvez a este ponto você já tenha tentado fazer tal associação, e ponto para quem acertou! DevOps é mesmo a união de desenvolvimento (development) e operação (a corruptela “ops” é de uso bem comum no meio militar e, como deve ser de conhecimento, o jargão militar influenciou muito no jargão da tecnologia). Essas duas palavras podem ser dissecadas de forma muito mais abrangente do que temos costume, já que pensamos quase automaticamente em desenvolvimento de software e em monitoramento.

Mas desenvolvimento aqui vai além do código programático; é código de honra de uma filosofia de melhoria contínua, de soluções ágeis. E operação vai além de monitoração, vai no cerne da administração de sistemas, de realmente tornar sistemas e seus componentes operáveis, funcionais. E é neste contexto que o trabalho do DevOps vai além do trabalho de um administrador de sistemas e sua tradição de bom scripting e automação de tarefas: ele torna o código integrável, reutilizável, trabalha com boas linguagens instrumentais e busca, acima de tudo, tornar estes processos cada vez mais ágeis e integrados a processos de infraestrutura, desenvolvimento e garantia da qualidade. Suas definições de Supervaca foram atualizadas.

Então tá, eu sei que algumas pessoas ainda se perguntarão o que de fato faz a figura do DevOps. Pra entender melhor, continua comigo… Mas uma lista de funções notáveis de escopo seria mais ou menos essa:

• Administração de sistemas operacionais. Usualmente UNIX/Linux. Mas cabe Windows;
• Configuração e administração de middleware (se você realmente não sabe o que é middleware, eu vou traduzir aqui bem tortinho como “ferramentas interoperacionais”, e isso tá longe de ser bonito);
• Configuração e administração de serviços de computação em nuvem (e isso, às vezes, inclui computação em grade – só às vezes);
• Administração de ferramentas de automação e integração, de desenvolvimento ou de sistemas. Inclui: integração e teste contínuos, ferramentas de controle de versão, contêineres de aplicações voláteis e ferramentas de validação;
• Scripting e, melhor que isso, desenvolvimento de toolkits e eventualmente APIs que facilitem a integração desses processos;
• Controle e administração de segurança de informação.

De certo que isso é um apanhado de cerne geral. E não, nem todo mundo precisa ser o soldado universal (e ter o porte do Dolph Lundgren) para ser devops. Há pessoas que começam por serem exímias com arquitetura da nuvem, outras por serem excelentes sysadmins, outras por conhecerem middleware e infraestrutura. Mas a grande sacada é ter a oportunidade de trabalhar com processos ágeis e limpos. Isso, mais as habilidades base, permite uma clareza e objetividade imensas na hora de juntar todos estes conhecimentos.

Nem acima e nem abaixo, a beleza de estar no meio

Uma das constantes para quem está começando (não faça a Suzana, seja paciente) é sempre precisarmos resumir, humildemente, parte do escopo de DevOps à infraestrutura e saber que tipo de infraestrutura lidamos. Ainda é corriqueiro, mercadologicamente falando, associar a análise de infraestrutura apenas ao profissional de redes, à organização dos dispositivos físicos, ao cabeamento, inventário etc. Se o DevOps não é o cara do cabo, nem o desenvolvedor de aplicações, mas não é somente o administrador de sistema operacional; quem ele é?

A resposta é simples – para nós – haja visto que, com as arquiteturas orientadas a serviços e logo além a computação em nuvem, a infraestrutura física é, atualmente, uma memória quase distante. A possibilidade de administrar serviços flexíveis e moldáveis às demandas de nossos clientes cria uma gama infindável de servidores escaláveis e integráveis, os quais sequer precisamos tocar além do shell ou da console administrativa. Grandes players como Amazon e Digital Ocean fazem da pletora de máquinas e cabos uma reminiscência.

Entretanto, é preciso lembrar que essa é apenas uma forma de prover um ambiente de integração contínua com a prática de DevOps. A provisão de infraestrutura como serviço (IaaS) é, inclusive, tão recente quanto a instituição do profissional de DevOps – arrisco dizer que foi a grande cartada para transformá-los em uma necessidade de mercado. Mas como eu disse, alguns de nós eram DevOps e não sabiam, desde a explosão desenfreada do SOA e dos web services. Ali nós ainda precisávamos prover a estrutura física, mas já tratávamos os processos de desenvolvimento, deploy e administração de forma integrada, separando a experiência de usuário de todo o processo de negócio e tornando-a moldável, reusável e adaptável.

Esta era (e ainda é para algumas aplicações de grande porte) uma forma viável de integrar os processos de negócios por meio de de middleware, provendo infraestrutura como uma plataforma (PaaS), algo mais móvel e com uma curva de aprendizado menor do que manter uma enorme estrutura vertical. Em ambas, a horizontalidade é um trunfo para melhor comunicação, melhor capacidade de análise, maior acesso de informação para todos os envolvidos e, claro, custo reduzido. Quero ouvir o coro de quem diz que não gosta dessa parte.

No próximo artigo, vou falar um pouco sobre Python x Ruby e a literatura básica de DevOps, com alguns links de dicas. Fique atento! Se você tem alguma dúvida ou contribuição para essa primeira parte, aproveite os campos abaixo. Até semana que vem!