Vagas DevOps fazem sentido? Entenda!

Esse post foi escrito para tentar ajudar — em especial recrutadores — que recorrentemente postam vagas “DevOps” em diversos grupos e canais de TI, sem trazer junto com a vaga qualquer tipo de informação que dê uma pista mínima do que ele espera do profissional que deseja recrutar.

Respondendo a pergunta do título:

Não, não fazem!

E quem diz isso são apenas os criadores do movimento DevOps e core members do DevOpsDays, dentre eles Patrick Debois, Damon Edwards, John Willis e outros.

Hoje o mundo está tomado por vagas Arquiteto DevOps, Engenheiro DevOps, Especialista DevOps ou simplesmente “DevOps”, além de ser um “cargo” abstrato, a informação sobre as vagas é muito ruim ou inexistente, simplesmente está lá o nome do cargo e cabe a nós de forma mágica tentar entender o que o recrutador está buscando.

Certa vez estava ministrando uma palestra e perguntei para 6 pessoas em pontos diferentes do auditório o que cada um entendia como DevOps, recebi 6 respostas completamente diferentes, agora imagina alguém colocando esse termo em uma vaga, cada interessado vai entender uma coisa, será uma confusão.

Entenda que DevOps é essencialmente uma CULTURA, fica difícil você colocar anúncio para contratar uma cultura, um modelo, um movimento, uma metodologia.

Faça uma comparação com desenvolvimento, você não vê por ai vagas para “desenvolvedores ágeis”, afinal o “ágil” em questão é um modelo, uma metodologia, você vê vagas para desenvolvedores nas quais dentro dos requisitos esperados está “Metodologia ágil de desenvolvimento”. DevOps é o mesmo caso, você não deveria procurar um Engenheiro DevOps, você deveria procurar um Engenheiro e dentro dos requisitos deve colocar “Cultura DevOps/Metodologia DevOps”, isso faz sentido.

Confusões e esclarecimentos

No Brasil especialmente a confusão sobre DevOps é terrível, tem gente que acha que DevOps é um programador que sabe infra, ou que é um sysadmin que sabe programar. O fato é que DevOps não é um cargo, não é uma pessoa, DevOps é uma CULTURA.

Outra confusão que vejo com muita frequência é sobre CI (Continuous Integration) e CD (Continuos Delivery/Deployment) serem DevOps ou não.

Tem gente que fala:

- Amanhã vou em um evento DevOps, discutir CD em plataforma Java e .Net.

Ok, dentro da Cultura DevOps você pode sim utilizar CD e CI, certamente vai usar, mas isso é uma ferramenta/metodologia que você traz para ajudar a resolver problemas culturais em uma organização, isso sozinho não pode ser considerado DevOps, na verdade é injusto pegar algo tão amplo, tão importante e reduzir a um simples pipeline de commit, build, test e deploy.

Sim, DevOps foi criado para entregar software melhor, mais rápido, com menor risco, de forma automatizada e controlada, ele é fundamentado nisso, mas antes de tudo, a Cultura estabelece uma série de eixos para resolver os problemas internos da organização que a IMPEDEM de entregar softwares melhores, mais rápidos, com menor risco de forma automatizada.

Antes da tecnologia vem o problema a ser assumido, resolvido, uma cultura a ser mudada para que todas as tecnologias e métodos possam ajudar.

CULTURA, guarde essa palavra, se não houver mudança de CULTURA não adianta querer trazer as tecnologias ou métodos para seu time ou organização. A tecnologia não vai resolver seu problema se a sua CULTURA está QUEBRADA.

Como contratar alguém que saiba essa cultura?

Eu — recrutador — preciso contratar um entusiasta da cultura DevOps, eu quero começar a transformar a minha organização, esse cara será o agente de mudanças, qual o nome dele?

CONSULTOR

Tá, mas eu quero alguém técnico para trabalhar já bebendo na fonte dessa cultura, e ai como divulgo?

Segue um exemplo:

Nome da vaga (sem devops no meio)

Estamos buscando um profissional que consiga trabalhar em times multidisciplinares, que tenha sólidos conhecimentos de programacao na plataforma/linguagem X, e bons fundamentos de sistemas operacionais e redes, que tenha condições de trabalhar com metodos ágeis, com processos e tecnologias de automação. Este profissional deve ter facilidade para adaptar metodos ágeis para uso interno do seu time e de suas atividades.

Procuramos essencialmente profissionais que consigam se relacionar bem com o seu time, que saibam fazer parte de um time, que respeitem o time, que saibam dividir e compartilhar responsabilidades com o time, que gostem de estudar e aprender novas tecnologias e que gostem de compartilhar o seu conhecimento.

Precisamos de profissionais que entendam que sua função é fazer com que o negócio da organização flua, ou seja, o foco do trabalho é oferecer suporte e sustentação as necessidades das pessoas que estão pensando, criando, escrevendo, desenvolvendo e publicando os produtos para atender as necessidades dos clientes desta organização.

Nesta organização enxergamos a TI como uma unidade orgânica composta por pessoas, as pessoas são importantes para nós, nosso entendimento é que a TI é um time monolítico que compartilha seus sucessos e aprendizados.

Queremos que você agregue valor ao nosso time e a nossa organização, e queremos que a organização agrege valor a você.

Tecnologias com as quais trabalhamos:

  • Linguagens
  • Sistemas operacionais
  • Serviços
  • Plataformas de desenvolvimento
  • Plataformas de automação
  • Plataformas de monitoramento
  • Plataformas de segurança
  • Plataformas de nuvem e virtualização
  • Plataformas de armazenamento
  • Plataformas de rede

Métodos que utilizamos em nossos times:

  • Método A
  • Método B
  • Método C

O que esperamos de você?

  • Esperamos que nos ajude a identificar as melhores tecnologias que possam ser utilizadas por novos produtos
  • Esperemos que nos ajude a identificar tecnologias que possam melhorar a performance de produtos existentes
  • Esperamos que nos ajude a acompanhar a performance e o funcionamento das aplicações
  • Esperamos que nos ajude a melhorar nossos processos de provisionamento de vms e containers
  • Esperamos que nos ajude a melhorar e agilizar o processo e o tempo necessário para criação de novos ambientes
  • Esperamos que nos ajude a oferecer mecanismos de autoserviço entregando recursos diretamente aos desenvolvedores
  • Esperamos que nos ajude a automatizar e otimizar nossa infra ao máximo
  • Esperamos que nos ajude a registrar mudanças e eventos, gerando relatórios que possibilitem auditoria se preciso
  • Esperamos que nos ajude a manter e evoluir nosso processo de deploy para que possamos entregar sempre e entregar rápido
  • Esperamos que você possa ir além, propondo, criando, mudando, construindo e evoluindo junto conosco.

Se você acha que as características necessárias para participar de nossos projetos e de nosso time, entre em contato!

Veja que é muito mais simples e claro dizer o que você espera da pessoa usando a cultura DevOps como referência e não como nome de cargo. Não há necessidade de enfiar o termo DevOps no meio da vaga. Infelizmente muito recrutadores fazem isso pois esperam que magicamente apareça aquele candidato que vai se encaixar na vaga e resolver a vida dele, isso não acontece, acredite.

Mais esclarecimentos

Antes que perguntem sobre sysadmin programar, sim, todo o profissional de TI deveria saber programar, isso não é exatamente Rocket Science, é uma qualidade fundamental para qualquer tipo de vaga de TI hoje em dia, principalmente se a organização se fundamenta pela cultura DevOps que tem automação como um dos seus pilares (CAMS/ICE).

É sempre bom lembrar que saber programar e ser um desenvolvedor ou engenheiro de software são coisas bem diferentes, normalmente não é isso que as pessoas estão buscando quando divulgam esse tipo de vaga.

Se precisa de um desenvolvedor, divulgar isso não tem mistério.

Momento “Reflexão”

Puxa eu — demandante da vaga — não preciso de nada disso, minha organização tem uma hierarquia bem vertical e engessada, tem vários silos e as pessoas não vão topar esse modelo ou essa mudança de cultura.

Se for esse o caso então sua necessidade não tem nada a ver com DevOps, talvez o que você esteja procurando seja um profissional de operação que use métodos ágeis, alguém que saiba aplicar métodos + automação em um silo como por exemplo uma equipe de sustentação ou infraestrutura.

Neste cenário tal profissional conseguirá melhorar processos ali, naquele time, e fazer uma transformação naquela realidade local — isso também é possível. A isso temos (Eu e Miguel Filho) dado o nome de infra ágil, que é uma necessidade e característica mais próxima do que temos visto no Brasil, seja em governo, seja em iniciativa privada.

Eu falarei mais disso em outro post ou em outro blog ;)

Espero ter ajudado.

[s]
Guto

DevOps in simple english

Abaixo coloco mais um vídeo bem simples para explicar DevOps feito pela Rackspace, muito bacana ;)

[s]
Guto

Cinco anos de DevOps

Duas palestras para demonstrar o atual estado do movimento e da cultura DevOps nos últimos 5 anos, uma do John Willis (criador da metodologia CAMS) e outra do Patrick Debois (criador do devopsdays).

Ambas dão uma noção de onde veio e como está o movimento hoje.

Enjoy!

[s]
Guto

Origens da cultura DevOps

Damon Edwards faz um excelente vídeo sobre as origens do DevOps, recomendo a todos que querem entender melhor esse movimento e cultura.

[s]
Guto

Puppet vs Ansible?

Essa é uma questão recorrente nas comunidades que participo e portanto vou registrar aqui no blog a minha visão para facilitar a resposta.

Definições

  1. O Puppet é uma ferramenta de gerência de configurações e estados que vem da escola de GCONF do Mark Burgess, criador do CFEngine e destes princípios que vem sendo contruídos desde os anos 90.

  2. O Ansible é uma ferramenta que faz o que chamamos de orquestração, ele não segue os princípios fundamentais de CCONF e o seu desenho não segue a escola do Mark Burgess.

1. Como funciona o Ansible

Imagine que você tem uma VM com o ansible instalado.

Nessa VM voce cria um playbook (código que vai executar alguma ação em um sistema operacional).

Você diz pro ansible a lista de máquinas em que ele vai se conectar para rodar aquele playbook.

A VM que roda o ansible converte aquele playbook em um código python e se conecta (faz o PUSH do código) em N máquinas utilizando sua rede para aplicá-lo. Na VM de destino é necessário ter o python e as python-libs exigidas pelo playbook.

O Ansible se conecta nestas máquinas utilizando o conhecido protocolo SSH, ele depende disso para funcionar, portanto é necessário ter credenciais de acesso ou chaves que te possibilitem chegar nestas VMs, se não houver serviço SSH rodando ou credenciais de acesso, não será possível fazer a orquestração.

Para se conectar as todas essas VMs, a máquina com Ansible tem que ter acesso a todas as redes em que as VMs estão rodando para poder orquestrá-las, portanto, você terá que fazer algumas regras de firewall para garantir o acesso a todos os pontos de sua infraestrutura.

Se você for aplicar um playbook em centenas ou milhares de máquinas paralelamente há de se tomar um cuidado extra pois ele pode gerar throughtput além das capacidades do seu switch/roteador no momento em que for tentar alcançar todos OSs simultâneamente ou dentro do paralelismo que você definir.

Nem tudo no Ansible tem controles rídigos ou é idempotente, algumas coisas são, outras não, idempotência não é uma pedra fundamental em seu desenho, além disto, ele não foi feito para gerar um relatório detalhado, garantir o sucesso ou ter um rídido controle da execução do playbook, no final ele executa o playbook onde você pede - o foco da orquestração é esse - mas a visibilidade é pequena, você não tem como saber de forma precisa se atingiu o seu objetivo ou se tudo o que você queria foi realizado em todas as VMs. No momento, ele não tem o melhor dos feedbacks para o administrador, mesmo assim, como orquestrador ele é uma ferramenta muito interessante e poderosa.

1.1 Orquestração em poucas palavras

Orquestração consiste em executar algo de forma paralela ou não em tempo real em um sistema operacional ou em um grupo de sistemas operacionais.

Quando falarem orquestração, pelo menos do ponto de vista de automação de infraestrutura, tenha em mente alguém que se conecta em N sistemas operacionais e executa algo, pontualmente, sem exigência rígidas ou grandes controles.

2. Como funciona o Puppet?

O puppet foi desenhado dentro dos conceitos fundamentais da “gerência de configurações”, e por isso não tem a característica PUSH. Esses conceitos foram criados em 1993 pelo Professor Mark Burgess da universidade de OSLO. Suas principais características são o drift, convergência, idempotência, gerência de estados e uso de agentes nos “nodes” (termo que usamos para descrever um sistema operacional com um agente instalado).

O conceito GCONF (Gerência de Configurações) foi estabelecido de forma mais concisa em 2004 com a criação da teoria Promisse do Mark Burgess que serviu de norte para a criação de todas as ferramentas modernas de CGCOF como Puppet, Salt, Chef e CFENGINE.

Na CGONF você define um estado desejado através de uma linguagem declarativa chamada DSL (Domain specific language), armazena isso em um local central (neste caso no puppetmaster). Nas pontas temos os agentes rodando nos nodes, esses agentes vão buscar essa configuração e aplicar no node.

Primeiro o agente verifica o estado atual do node, compara com o estado desejado, se houver divergência ele converge o node para o estado desejado. Todo esse processo gera um relatório robusto que registra todas as mudanças e eventos daquela drift/convergência.

Em resumo se alguém alterar algo que o puppet está gerenciando, o puppet detecta e corrige sem necessidade de intervenção humana, é o que chamamos de auto-healing.

Quaisquer ações ou recursos utilizados no Puppet tem como premissa a idempotência e o rídigo controle durante a aplicação, esse é um princípio fundamental do seu desenho. O agente roda como serviço no sistema operacional, portanto, a cada N minutos ele acorda e executa essa checagem em todo o sistema para garantir o compliance e o estado desejado, essa é sua missão, ele é o guardião dos estados e da integridade do node.

O servidor nunca se conecta nos nós, apenas os nós de conectam no servidor. O servidor que contém as configurações pode ser facilmente replicado e colocado atrás de um balanceador. Você difícilmente tem problemas com throughput em sua rede como aqueles que podem acontecer com orquestradores e praticamente não precisa de preocupar com regras firewall, os nodes precisam se conectar à porta 8140 TCP do master ou do seu LB, apenas isto.

O Puppet não depende de serviços de terceiros como SSH para funcionar, ele utiliza seu próprio agente e a comunicação ocorre através de uma API REST que é utilizada pelo agente para se comunicar com o master.

Toda a comunicação é criptografada ponta-a-ponta e o custo disso para rede é baixíssimo se comparado com outros médotos.

Outra grande vantagem desse modelo é que mesmo que o servidor esteja fora, os agentes continuam funcionando e aplicando a última configuração recebida.

2.1 Gerência de configurações em poucas palavras

Ferramentas de gerência de configuração funcionam em arquitetura agente e servidor, o servidor armazena as configurações dos nodes. O agente que roda no node, busca as configurações e aplica localmente.

O agente funciona com o conceito de gerência de estados. Você usa uma linguagem declarativa para descrever os estados desejados nos nodes de sua rede.

Idempotência é uma princípio fundamental do agente. Há um robusto sistema de relatórios e registro de eventos e mudanças. O servidor nunca se conecta nos nós, apenas os nós se conectam ao servidor.

3. Conclusão

No final ambas são ferramentas de gerência, o Puppet faz a gerência de configurações e estados e o Ansible faz gerência por orquestração. Tais ferramentas atuam de formas distintas e tem objetivos e usos diferentes.

Acima de tudo é importante entender que elas não são concorrentes.

É bom ter as duas no seu cinto de utilidades, dependendo do projeto você terá uso para uma ou para outra.

[s]
Guto

Plugins que uso no ATOM

Sempre me perguntam quais plugins eu uso no ATOM para desenvolvimento Puppet, segue a lista:

De linguagem:

  • language-puppet do atom
  • language-yaml do atom
  • language-ruby do tom

De linter:

  • linter do atom-community
  • linter-puppet-lint do atom-community
  • linter-puppet-parser do asquelt
  • linter-ruby do atomcommunity

De align:

  • aligner do adrianlee44
  • aligner-puppet do bigbrozer
  • aligner-ruby do adrianlee44

Outros:

  • file-icons do DanBrooker
  • git-control do jacogr
  • open-recent do zren
  • minimap do atom-minimap
  • remote-edit do sveale

Normalmente monto - via sshfs - o diretório com o código que está em alguma VM de desenvolvimento e trabalho no conforto do ATOM.

Meus alunos preferem que eu mostre o código no ATOM e eles sempre falam muito bem do linter.

#ficaadica

Se você tiver dica de plugins pro ATOM manda nos comentários ;)

[s]
Guto

Estarei no DevOpsDays 2016 em Porto Alegre

Galera fui convidado para apresentar alguns cases de automação de infraestrutura no DevOpsDays de Porto Alegre, será no dia 09 de julho de 2016. Ainda não sei o horário, mas fica a dica do evento.

Faça sua inscrição!

http://www.devopsdays.org/events/2016-portoalegre/welcome/

Vejo vocês lá!

[s]
Guto

Estarei no TDC SP 2016 :)

Fui convidado para ajudar a coordenar a trilha de “Infra Ágil” no “The Developers Conference São Paulo” que vai acontecer em Julho de 2016.

Devo apresentar uma palestra de nome homônimo no evento. A trilha deve acontecer no dia 08 de Julho, ainda não está definido o horário, aviso por aqui assim que souber.

A chamada de trabalhos ainda está aberta, mande sua proposta até o dia 4 de Junho.

http://www.thedevelopersconference.com.br/tdc/2016/saopaulo/call4papers

Vejo vocês lá!

[s]
Guto

Resultado do Meetup Puppet DF 20160518

O Meetup foi execelente, tivemos cerca de noventa inscritos, compareceram cerca de sessenta pessoas, se contarmos a turma da organização e os palestantres acho que tivemos umas setenta pessoas presentes.

Meus agradecimentos à faculdade evangélica, em especial do Prof. Maurício e ao Prof. Dirceu que cederam espaço e nos ajudaram na logística do encontro.

Não conseguimos apresentar do jeito que queríamos o último trabalho (Integração de GitLab com Puppet) devido ao tempo que ficou apertado, mas conseguimos avançar com conteúdo de Puppet para a comunidade local.

A experiência nos mostrou que é melhor reduzir os temas nos próximos encontros, portanto, o próximo meetup terá tema específico, seja desenvolvimento de módulos, seja testes, seja pcp, apenas um tema que iremos desenvolver do início ao fim.

Agradeço aos palestrantes Adriano, Taciano, Rafael e Dirceu pelo tempo que investiram no encontro e por terem compartilhado experiência e conhecimento conosco.

Estamos estudando fazero próximo agora em junho, aguardo sugestões de temas, ideias e quem sabe uma nova parceria para hospedar o Meetup.

Fotos

Acesse as fotos no link abaixo:

https://www.flickr.com/photos/puppet-br/albums/72157666275683673

Slides

Os slides estão no speakerdeck:

  1. https://speakerdeck.com/gutocarvalho/meetup-puppet-br-20160518-intro-puppet

  2. https://speakerdeck.com/gutocarvalho/meetup-puppet-br-20160518-integracao-entre-puppet-e-vagrant

  3. https://speakerdeck.com/gutocarvalho/meetup-puppet-br-20160518-projeto-pcp

  4. https://speakerdeck.com/gutocarvalho/meetup-puppet-br-20160518-desenvolvendo-modulos-e-fatos-puppet

  5. https://speakerdeck.com/gutocarvalho/meetup-puppet-br-20160518-testes-de-codigo-puppet

[s]
Guto

Foi liberado o PCP 1.0.2

O projeto PCP está em casa nova e com nova versão. Movemos o projeto para a organização Puppet-BR no github para facilitar a contribuição. Agora a documentação está toda em inglês o que facilita o uso para pessoas de qualquer parte do mundo.

Já fizemos a homologação das versões mais recentes do puppet nesta release:

  • Puppet Server 2.3.2
  • Puppet Agent 1.4.2
  • Mcollective 2.8.8
  • PuppetDB 4.0.2
  • PostgreSQL 9.4.6
  • Puppet Explorer 2.0.0
  • ActiveMQ 5.13.2

Agradeço por todas as ideias e por todas as contribuições recebidas no GitHub, agradeço pela turma que participou do Meetup PCP em Brasília e por todos que ajudaram a testar a nova versão. [s]
Guto